* [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
@ 2022-01-16 17:26 Stefan Wahren
2022-01-16 20:15 ` Florian Fainelli
2022-01-20 15:39 ` Maxime Ripard
0 siblings, 2 replies; 10+ messages in thread
From: Stefan Wahren @ 2022-01-16 17:26 UTC (permalink / raw)
To: Maxime Ripard, Florian Fainelli
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
Hi,
recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
Aarch64 with Arch Linux. I'm able to reproduce this issue on my
Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
the connected HDMI monitor off and on again.
Kernel output is the following:
[15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
unhandled: 0
[15053.295440] ->handle_irq(): 00000000b28cf1d1,
brcmstb_l2_intc_irq_handle+0x0/0x1e0
[15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
[15053.315233] ->action(): 00000000236e815e
[15053.322022] ->action->handler(): 0000000013023289,
bad_chained_irq+0x0/0x50
[15053.331909] IRQ_LEVEL set
[15053.337822] IRQ_NOPROBE set
[15053.343715] IRQ_NOREQUEST set
[15053.349585] IRQ_NOTHREAD set
Content of /proc/interrupts after the issue occured:
CPU0 CPU1 CPU2 CPU3
9: 0 0 0 0 GICv2 25 Level
vgic
10: 1 0 0 0 GICv2 128 Level
(null)
12: 130322 26028 27670 135225 GICv2 30 Level
arch_timer
13: 0 0 0 0 GICv2 27 Level
kvm guest vtimer
19: 0 0 0 0 GICv2 107 Level
fe004000.txp
20: 7450 0 0 0 GICv2 65 Level
fe00b880.mailbox
25: 6525 0 0 0 GICv2 153 Level
uart-pl011
26: 0 0 0 0 GICv2 149 Level
fe205000.i2c, fe804000.i2c
27: 9 0 0 0 GICv2 125 Level
ttyS1
28: 36999 0 0 0 GICv2 158 Level
mmc0, mmc1
29: 1 0 0 0 GICv2 129 Level
vc4 hvs
30: 0 0 0 0 GICv2 105 Level
fe980000.usb, fe980000.usb
31: 0 0 0 0 GICv2 112 Level
DMA IRQ
33: 0 0 0 0 GICv2 114 Level
DMA IRQ
40: 0 0 0 0 GICv2 141 Level
vc4 crtc
41: 0 0 0 0 GICv2 142 Level
vc4 crtc, vc4 crtc
42: 10 0 0 0 GICv2 133 Level
vc4 crtc
43: 1 0 0 0
interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
44: 0 0 0 0
interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
47: 0 0 0 0
interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
48: 1 0 0 0
interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
49: 0 0 0 0
interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
50: 0 0 0 0
interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
53: 0 0 0 0
interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
54: 0 0 0 0
interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
55: 7 0 0 0 GICv2 66 Level
VCHIQ doorbell
56: 0 0 0 0 GICv2 48 Level
arm-pmu
57: 0 0 0 0 GICv2 49 Level
arm-pmu
58: 0 0 0 0 GICv2 50 Level
arm-pmu
59: 0 0 0 0 GICv2 51 Level
arm-pmu
62: 47599 0 0 0 GICv2 189 Level
eth0
63: 4681 0 0 0 GICv2 190 Level
eth0
64: 0 0 0 0 GICv2 175 Level
PCIe PME, aerdrv
65: 326 0 0 0 BRCM STB PCIe MSI
524288 Edge xhci_hcd
IPI0: 2442 5185 7195 18290 Rescheduling
interrupts
IPI1: 481 383 518 533 Function call
interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for
crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast
interrupts
IPI5: 1 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up
interrupts
Err: 1
Comparing the vendor & mainline DTS, i noticed differences at hdmi0/1.
The vendor DTS has an additional register to access the same space as
aon_intr (interrupt parent), which looks ugly [2].
Additionally i noted that bcm2711.dtsi uses the compatible
"brcm,bcm2711-l2-intc" with a level high interrupt, but according to
irq-brcmstb-l2.c [3] the compatible is not defined and would fallback to
"brcm,l2-intc" with brcmstb_l2_edge_intc_of_init. This looks fishy.
I didn't try to reproduce this with Raspberry Pi OS & mainline kernel,
but i hope these are enough information so far.
[1] - https://archlinuxarm.org/forum/viewtopic.php?f=65&t=15791
[2] -
https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/bcm2711.dtsi#L339
[3] -
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/irqchip/irq-brcmstb-l2.c?h=v5.15.15#n278
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-16 17:26 [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle Stefan Wahren
@ 2022-01-16 20:15 ` Florian Fainelli
2022-01-17 4:59 ` Florian Fainelli
2022-01-20 15:39 ` Maxime Ripard
1 sibling, 1 reply; 10+ messages in thread
From: Florian Fainelli @ 2022-01-16 20:15 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
Hi Stefan,
On 1/16/2022 9:26 AM, Stefan Wahren wrote:
> Hi,
>
> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
> the connected HDMI monitor off and on again.
>
> Kernel output is the following:
>
> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
> unhandled: 0
> [15053.295440] ->handle_irq(): 00000000b28cf1d1,
> brcmstb_l2_intc_irq_handle+0x0/0x1e0
> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
> [15053.315233] ->action(): 00000000236e815e
> [15053.322022] ->action->handler(): 0000000013023289,
> bad_chained_irq+0x0/0x50
> [15053.331909] IRQ_LEVEL set
> [15053.337822] IRQ_NOPROBE set
> [15053.343715] IRQ_NOREQUEST set
> [15053.349585] IRQ_NOTHREAD set
OK, so those should have been cleared during the call to
irq_alloc_domain_generic_chips(), any clues why they are set here?
>
> Content of /proc/interrupts after the issue occured:
>
> CPU0 CPU1 CPU2 CPU3
> 9: 0 0 0 0 GICv2 25 Level
> vgic
> 10: 1 0 0 0 GICv2 128 Level
> (null)
This is suspicious, we should not have an interrupt registered here at
all since we call irq_set_chained_handler_and_data, this is a L2
interrupt controller, not a leaf interrupt with a descriptor. On all
Broadcom STB systems where this interrupt controller is used, I
definitively don't see any entries for the L2 output to the GIC in
/proc/interrupts because no interrupt descriptor is allocated.
This makes me wonder where this is coming from but the message about irq
10 being bad would make sense then.
> 12: 130322 26028 27670 135225 GICv2 30 Level
> arch_timer
> 13: 0 0 0 0 GICv2 27 Level
> kvm guest vtimer
> 19: 0 0 0 0 GICv2 107 Level
> fe004000.txp
> 20: 7450 0 0 0 GICv2 65 Level
> fe00b880.mailbox
> 25: 6525 0 0 0 GICv2 153 Level
> uart-pl011
> 26: 0 0 0 0 GICv2 149 Level
> fe205000.i2c, fe804000.i2c
> 27: 9 0 0 0 GICv2 125 Level
> ttyS1
> 28: 36999 0 0 0 GICv2 158 Level
> mmc0, mmc1
> 29: 1 0 0 0 GICv2 129 Level
> vc4 hvs
> 30: 0 0 0 0 GICv2 105 Level
> fe980000.usb, fe980000.usb
> 31: 0 0 0 0 GICv2 112 Level
> DMA IRQ
> 33: 0 0 0 0 GICv2 114 Level
> DMA IRQ
> 40: 0 0 0 0 GICv2 141 Level
> vc4 crtc
> 41: 0 0 0 0 GICv2 142 Level
> vc4 crtc, vc4 crtc
> 42: 10 0 0 0 GICv2 133 Level
> vc4 crtc
> 43: 1 0 0 0
> interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
> 44: 0 0 0 0
> interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
> 47: 0 0 0 0
> interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
> 48: 1 0 0 0
> interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
> 49: 0 0 0 0
> interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
> 50: 0 0 0 0
> interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
> 53: 0 0 0 0
> interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
> 54: 0 0 0 0
> interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
> 55: 7 0 0 0 GICv2 66 Level
> VCHIQ doorbell
> 56: 0 0 0 0 GICv2 48 Level
> arm-pmu
> 57: 0 0 0 0 GICv2 49 Level
> arm-pmu
> 58: 0 0 0 0 GICv2 50 Level
> arm-pmu
> 59: 0 0 0 0 GICv2 51 Level
> arm-pmu
> 62: 47599 0 0 0 GICv2 189 Level
> eth0
> 63: 4681 0 0 0 GICv2 190 Level
> eth0
> 64: 0 0 0 0 GICv2 175 Level
> PCIe PME, aerdrv
> 65: 326 0 0 0 BRCM STB PCIe MSI
> 524288 Edge xhci_hcd
> IPI0: 2442 5185 7195 18290 Rescheduling
> interrupts
> IPI1: 481 383 518 533 Function call
> interrupts
> IPI2: 0 0 0 0 CPU stop interrupts
> IPI3: 0 0 0 0 CPU stop (for
> crash dump) interrupts
> IPI4: 0 0 0 0 Timer broadcast
> interrupts
> IPI5: 1 0 0 0 IRQ work interrupts
> IPI6: 0 0 0 0 CPU wake-up
> interrupts
> Err: 1
>
> Comparing the vendor & mainline DTS, i noticed differences at hdmi0/1.
> The vendor DTS has an additional register to access the same space as
> aon_intr (interrupt parent), which looks ugly [2].
OK, so while I do see how we set external_irq_controller to let the
interrupt be managed externally from vc4_hdmi.c else do it internally, I
don't see the code that tries to map the "intr2" register space, let
alone fetch its resource, do you know where that is?
>
> Additionally i noted that bcm2711.dtsi uses the compatible
> "brcm,bcm2711-l2-intc" with a level high interrupt, but according to
> irq-brcmstb-l2.c [3] the compatible is not defined and would fallback to
> "brcm,l2-intc" with brcmstb_l2_edge_intc_of_init. This looks fishy.
The hardware level 2 controller at 0x7ef00100 is definitively the same
kind that supports edge interrupt flows since it has the CPU_STATUS,
CPU_CLEAR, CPU_MASK_STATUS, CPU_MASK_SET and CPU_MASK_CLEAR registers,
so it seems to me like declaring the interrupt controller of the kind
"brcm,l2-intc" and using the edge interrupt handling is not necessarily
a problem.
>
> I didn't try to reproduce this with Raspberry Pi OS & mainline kernel,
> but i hope these are enough information so far.
>
> [1] - https://archlinuxarm.org/forum/viewtopic.php?f=65&t=15791
>
> [2] -
> https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/bcm2711.dtsi#L339
>
> [3] -
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/irqchip/irq-brcmstb-l2.c?h=v5.15.15#n278
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-16 20:15 ` Florian Fainelli
@ 2022-01-17 4:59 ` Florian Fainelli
2022-01-20 15:54 ` Maxime Ripard
0 siblings, 1 reply; 10+ messages in thread
From: Florian Fainelli @ 2022-01-17 4:59 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
On 1/16/2022 12:15 PM, Florian Fainelli wrote:
> Hi Stefan,
>
> On 1/16/2022 9:26 AM, Stefan Wahren wrote:
>> Hi,
>>
>> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
>> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
>> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
>> the connected HDMI monitor off and on again.
>>
>> Kernel output is the following:
>>
>> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
>> unhandled: 0
>> [15053.295440] ->handle_irq(): 00000000b28cf1d1,
>> brcmstb_l2_intc_irq_handle+0x0/0x1e0
>> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
>> [15053.315233] ->action(): 00000000236e815e
>> [15053.322022] ->action->handler(): 0000000013023289,
>> bad_chained_irq+0x0/0x50
>> [15053.331909] IRQ_LEVEL set
>> [15053.337822] IRQ_NOPROBE set
>> [15053.343715] IRQ_NOREQUEST set
>> [15053.349585] IRQ_NOTHREAD set
>
> OK, so those should have been cleared during the call to
> irq_alloc_domain_generic_chips(), any clues why they are set here?
>
>>
>> Content of /proc/interrupts after the issue occured:
>>
>> CPU0 CPU1 CPU2 CPU3
>> 9: 0 0 0 0 GICv2 25 Level
>> vgic
>> 10: 1 0 0 0 GICv2 128 Level
>> (null)
>
> This is suspicious, we should not have an interrupt registered here at
> all since we call irq_set_chained_handler_and_data, this is a L2
> interrupt controller, not a leaf interrupt with a descriptor. On all
> Broadcom STB systems where this interrupt controller is used, I
> definitively don't see any entries for the L2 output to the GIC in
> /proc/interrupts because no interrupt descriptor is allocated.
>
> This makes me wonder where this is coming from but the message about irq
> 10 being bad would make sense then.
>
>> 12: 130322 26028 27670 135225 GICv2 30 Level
>> arch_timer
>> 13: 0 0 0 0 GICv2 27 Level
>> kvm guest vtimer
>> 19: 0 0 0 0 GICv2 107 Level
>> fe004000.txp
>> 20: 7450 0 0 0 GICv2 65 Level
>> fe00b880.mailbox
>> 25: 6525 0 0 0 GICv2 153 Level
>> uart-pl011
>> 26: 0 0 0 0 GICv2 149 Level
>> fe205000.i2c, fe804000.i2c
>> 27: 9 0 0 0 GICv2 125 Level
>> ttyS1
>> 28: 36999 0 0 0 GICv2 158 Level
>> mmc0, mmc1
>> 29: 1 0 0 0 GICv2 129 Level
>> vc4 hvs
>> 30: 0 0 0 0 GICv2 105 Level
>> fe980000.usb, fe980000.usb
>> 31: 0 0 0 0 GICv2 112 Level
>> DMA IRQ
>> 33: 0 0 0 0 GICv2 114 Level
>> DMA IRQ
>> 40: 0 0 0 0 GICv2 141 Level
>> vc4 crtc
>> 41: 0 0 0 0 GICv2 142 Level
>> vc4 crtc, vc4 crtc
>> 42: 10 0 0 0 GICv2 133 Level
>> vc4 crtc
>> 43: 1 0 0 0
>> interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
>> 44: 0 0 0 0
>> interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
>> 47: 0 0 0 0
>> interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
>> 48: 1 0 0 0
>> interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
>> 49: 0 0 0 0
>> interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
>> 50: 0 0 0 0
>> interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
>> 53: 0 0 0 0
>> interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
>> 54: 0 0 0 0
>> interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
>> 55: 7 0 0 0 GICv2 66 Level
>> VCHIQ doorbell
>> 56: 0 0 0 0 GICv2 48 Level
>> arm-pmu
>> 57: 0 0 0 0 GICv2 49 Level
>> arm-pmu
>> 58: 0 0 0 0 GICv2 50 Level
>> arm-pmu
>> 59: 0 0 0 0 GICv2 51 Level
>> arm-pmu
>> 62: 47599 0 0 0 GICv2 189 Level
>> eth0
>> 63: 4681 0 0 0 GICv2 190 Level
>> eth0
>> 64: 0 0 0 0 GICv2 175 Level
>> PCIe PME, aerdrv
>> 65: 326 0 0 0 BRCM STB PCIe MSI
>> 524288 Edge xhci_hcd
>> IPI0: 2442 5185 7195 18290 Rescheduling
>> interrupts
>> IPI1: 481 383 518 533 Function call
>> interrupts
>> IPI2: 0 0 0 0 CPU stop
>> interrupts
>> IPI3: 0 0 0 0 CPU stop (for
>> crash dump) interrupts
>> IPI4: 0 0 0 0 Timer broadcast
>> interrupts
>> IPI5: 1 0 0 0 IRQ work
>> interrupts
>> IPI6: 0 0 0 0 CPU wake-up
>> interrupts
>> Err: 1
>>
>> Comparing the vendor & mainline DTS, i noticed differences at hdmi0/1.
>> The vendor DTS has an additional register to access the same space as
>> aon_intr (interrupt parent), which looks ugly [2].
>
> OK, so while I do see how we set external_irq_controller to let the
> interrupt be managed externally from vc4_hdmi.c else do it internally, I
> don't see the code that tries to map the "intr2" register space, let
> alone fetch its resource, do you know where that is?
Downstream appears to be setting the 'aon_intr' Device Tree node with a
status = disabled property, still leaves me wondering whether the
"intr2" register space is used.
I think it would be prudent to change the hpd_con, hpd_rm variables in
vc4_hdmi.c to be signed integers instead of unsigned integers, if
nothing else such that -EPROBE_DEFER might be returned.
Also, in 5.16, we can finally build irq-brcmstb-l2 as a module, so
dealing with -EPROBE_DEFER might be necessary.
I am still lost as to why GIC_SPI 96 was allowed to show up as leaf
interrupt, unless there is something modification of the Device Tree
being used by the VPU firmware?
>
>>
>> Additionally i noted that bcm2711.dtsi uses the compatible
>> "brcm,bcm2711-l2-intc" with a level high interrupt, but according to
>> irq-brcmstb-l2.c [3] the compatible is not defined and would fallback to
>> "brcm,l2-intc" with brcmstb_l2_edge_intc_of_init. This looks fishy.
>
> The hardware level 2 controller at 0x7ef00100 is definitively the same
> kind that supports edge interrupt flows since it has the CPU_STATUS,
> CPU_CLEAR, CPU_MASK_STATUS, CPU_MASK_SET and CPU_MASK_CLEAR registers,
> so it seems to me like declaring the interrupt controller of the kind
> "brcm,l2-intc" and using the edge interrupt handling is not necessarily
> a problem.
>
>>
>> I didn't try to reproduce this with Raspberry Pi OS & mainline kernel,
>> but i hope these are enough information so far.
>>
>> [1] - https://archlinuxarm.org/forum/viewtopic.php?f=65&t=15791
>>
>> [2] -
>> https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/bcm2711.dtsi#L339
>>
>>
>> [3] -
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/irqchip/irq-brcmstb-l2.c?h=v5.15.15#n278
>>
>>
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-16 17:26 [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle Stefan Wahren
2022-01-16 20:15 ` Florian Fainelli
@ 2022-01-20 15:39 ` Maxime Ripard
2022-01-20 18:10 ` Stefan Wahren
1 sibling, 1 reply; 10+ messages in thread
From: Maxime Ripard @ 2022-01-20 15:39 UTC (permalink / raw)
To: Stefan Wahren
Cc: Florian Fainelli, Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
[-- Attachment #1.1: Type: text/plain, Size: 6702 bytes --]
Hi Stefan,
On Sun, Jan 16, 2022 at 06:26:58PM +0100, Stefan Wahren wrote:
> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
> the connected HDMI monitor off and on again.
By turning the monitor on and off, you mean that you used the power
button on it? Not something like disabling the output in sysfs, right?
> Kernel output is the following:
>
> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
> unhandled: 0
> [15053.295440] ->handle_irq(): 00000000b28cf1d1,
> brcmstb_l2_intc_irq_handle+0x0/0x1e0
> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
> [15053.315233] ->action(): 00000000236e815e
> [15053.322022] ->action->handler(): 0000000013023289,
> bad_chained_irq+0x0/0x50
> [15053.331909] IRQ_LEVEL set
> [15053.337822] IRQ_NOPROBE set
> [15053.343715] IRQ_NOREQUEST set
> [15053.349585] IRQ_NOTHREAD set
IRQ10 is the interrupt that a monitor has been connected on HDMI1, which
makes sense if you were using HDMI1. Usually, when a display is turned
on, it will issue a pulse on the HPD line so we would have a
disconnection interrupt followed by a connection interrupt.
This is weird though, since we have an interrupt handler on that
interrupt (hpd-connected in the DT binding):
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L1578
> Content of /proc/interrupts after the issue occured:
>
> CPU0 CPU1 CPU2 CPU3
> 9: 0 0 0 0 GICv2 25 Level
> vgic
> 10: 1 0 0 0 GICv2 128 Level
> (null)
> 12: 130322 26028 27670 135225 GICv2 30 Level
> arch_timer
> 13: 0 0 0 0 GICv2 27 Level
> kvm guest vtimer
> 19: 0 0 0 0 GICv2 107 Level
> fe004000.txp
> 20: 7450 0 0 0 GICv2 65 Level
> fe00b880.mailbox
> 25: 6525 0 0 0 GICv2 153 Level
> uart-pl011
> 26: 0 0 0 0 GICv2 149 Level
> fe205000.i2c, fe804000.i2c
> 27: 9 0 0 0 GICv2 125 Level
> ttyS1
> 28: 36999 0 0 0 GICv2 158 Level
> mmc0, mmc1
> 29: 1 0 0 0 GICv2 129 Level
> vc4 hvs
> 30: 0 0 0 0 GICv2 105 Level
> fe980000.usb, fe980000.usb
> 31: 0 0 0 0 GICv2 112 Level
> DMA IRQ
> 33: 0 0 0 0 GICv2 114 Level
> DMA IRQ
> 40: 0 0 0 0 GICv2 141 Level
> vc4 crtc
> 41: 0 0 0 0 GICv2 142 Level
> vc4 crtc, vc4 crtc
> 42: 10 0 0 0 GICv2 133 Level
> vc4 crtc
> 43: 1 0 0 0
> interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
> 44: 0 0 0 0
> interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
> 47: 0 0 0 0
> interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
> 48: 1 0 0 0
> interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
> 49: 0 0 0 0
> interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
> 50: 0 0 0 0
> interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
> 53: 0 0 0 0
> interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
> 54: 0 0 0 0
And it's there as well.
> interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
> 55: 7 0 0 0 GICv2 66 Level
> VCHIQ doorbell
> 56: 0 0 0 0 GICv2 48 Level
> arm-pmu
> 57: 0 0 0 0 GICv2 49 Level
> arm-pmu
> 58: 0 0 0 0 GICv2 50 Level
> arm-pmu
> 59: 0 0 0 0 GICv2 51 Level
> arm-pmu
> 62: 47599 0 0 0 GICv2 189 Level
> eth0
> 63: 4681 0 0 0 GICv2 190 Level
> eth0
> 64: 0 0 0 0 GICv2 175 Level
> PCIe PME, aerdrv
> 65: 326 0 0 0 BRCM STB PCIe MSI
> 524288 Edge xhci_hcd
> IPI0: 2442 5185 7195 18290 Rescheduling
> interrupts
> IPI1: 481 383 518 533 Function call
> interrupts
> IPI2: 0 0 0 0 CPU stop interrupts
> IPI3: 0 0 0 0 CPU stop (for
> crash dump) interrupts
> IPI4: 0 0 0 0 Timer broadcast
> interrupts
> IPI5: 1 0 0 0 IRQ work interrupts
> IPI6: 0 0 0 0 CPU wake-up
> interrupts
> Err: 1
>
> Comparing the vendor & mainline DTS, i noticed differences at hdmi0/1.
> The vendor DTS has an additional register to access the same space as
> aon_intr (interrupt parent), which looks ugly [2].
This is an artifact from the past. We used to use that register directly
in our driver before we went to upstream the CEC support, but we don't
anymore. The DT patch must have been carried around since then, but
nothing should be using it.
> Additionally i noted that bcm2711.dtsi uses the compatible
> "brcm,bcm2711-l2-intc" with a level high interrupt, but according to
> irq-brcmstb-l2.c [3] the compatible is not defined and would fallback to
> "brcm,l2-intc" with brcmstb_l2_edge_intc_of_init. This looks fishy.
>
> I didn't try to reproduce this with Raspberry Pi OS & mainline kernel,
> but i hope these are enough information so far.
I don't remember anyone reporting this before, and I have tested the
disconnection / connection interrupts myself a number of times without
ever seeing this. The level vs edge stuff might be a good explanation
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-17 4:59 ` Florian Fainelli
@ 2022-01-20 15:54 ` Maxime Ripard
0 siblings, 0 replies; 10+ messages in thread
From: Maxime Ripard @ 2022-01-20 15:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren, Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
[-- Attachment #1.1: Type: text/plain, Size: 5191 bytes --]
Hi Florian,
On Sun, Jan 16, 2022 at 08:59:15PM -0800, Florian Fainelli wrote:
> > > 12: 130322 26028 27670 135225 GICv2 30 Level
> > > arch_timer
> > > 13: 0 0 0 0 GICv2 27 Level
> > > kvm guest vtimer
> > > 19: 0 0 0 0 GICv2 107 Level
> > > fe004000.txp
> > > 20: 7450 0 0 0 GICv2 65 Level
> > > fe00b880.mailbox
> > > 25: 6525 0 0 0 GICv2 153 Level
> > > uart-pl011
> > > 26: 0 0 0 0 GICv2 149 Level
> > > fe205000.i2c, fe804000.i2c
> > > 27: 9 0 0 0 GICv2 125 Level
> > > ttyS1
> > > 28: 36999 0 0 0 GICv2 158 Level
> > > mmc0, mmc1
> > > 29: 1 0 0 0 GICv2 129 Level
> > > vc4 hvs
> > > 30: 0 0 0 0 GICv2 105 Level
> > > fe980000.usb, fe980000.usb
> > > 31: 0 0 0 0 GICv2 112 Level
> > > DMA IRQ
> > > 33: 0 0 0 0 GICv2 114 Level
> > > DMA IRQ
> > > 40: 0 0 0 0 GICv2 141 Level
> > > vc4 crtc
> > > 41: 0 0 0 0 GICv2 142 Level
> > > vc4 crtc, vc4 crtc
> > > 42: 10 0 0 0 GICv2 133 Level
> > > vc4 crtc
> > > 43: 1 0 0 0
> > > interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
> > > 44: 0 0 0 0
> > > interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
> > > 47: 0 0 0 0
> > > interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
> > > 48: 1 0 0 0
> > > interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
> > > 49: 0 0 0 0
> > > interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
> > > 50: 0 0 0 0
> > > interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
> > > 53: 0 0 0 0
> > > interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
> > > 54: 0 0 0 0
> > > interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
> > > 55: 7 0 0 0 GICv2 66 Level
> > > VCHIQ doorbell
> > > 56: 0 0 0 0 GICv2 48 Level
> > > arm-pmu
> > > 57: 0 0 0 0 GICv2 49 Level
> > > arm-pmu
> > > 58: 0 0 0 0 GICv2 50 Level
> > > arm-pmu
> > > 59: 0 0 0 0 GICv2 51 Level
> > > arm-pmu
> > > 62: 47599 0 0 0 GICv2 189 Level
> > > eth0
> > > 63: 4681 0 0 0 GICv2 190 Level
> > > eth0
> > > 64: 0 0 0 0 GICv2 175 Level
> > > PCIe PME, aerdrv
> > > 65: 326 0 0 0 BRCM STB PCIe MSI
> > > 524288 Edge xhci_hcd
> > > IPI0: 2442 5185 7195 18290 Rescheduling
> > > interrupts
> > > IPI1: 481 383 518 533 Function call
> > > interrupts
> > > IPI2: 0 0 0 0 CPU stop
> > > interrupts
> > > IPI3: 0 0 0 0 CPU stop (for
> > > crash dump) interrupts
> > > IPI4: 0 0 0 0 Timer broadcast
> > > interrupts
> > > IPI5: 1 0 0 0 IRQ work
> > > interrupts
> > > IPI6: 0 0 0 0 CPU wake-up
> > > interrupts
> > > Err: 1
> > >
> > > Comparing the vendor & mainline DTS, i noticed differences at hdmi0/1.
> > > The vendor DTS has an additional register to access the same space as
> > > aon_intr (interrupt parent), which looks ugly [2].
> >
> > OK, so while I do see how we set external_irq_controller to let the
> > interrupt be managed externally from vc4_hdmi.c else do it internally, I
> > don't see the code that tries to map the "intr2" register space, let
> > alone fetch its resource, do you know where that is?
>
> Downstream appears to be setting the 'aon_intr' Device Tree node with a
> status = disabled property, still leaves me wondering whether the "intr2"
> register space is used.
It's not used, its last (and only) user was reverted in:
https://github.com/raspberrypi/linux/commit/07170fdd6daffb3fb276a9dc814d6d02d82b055f
> I think it would be prudent to change the hpd_con, hpd_rm variables in
> vc4_hdmi.c to be signed integers instead of unsigned integers, if nothing
> else such that -EPROBE_DEFER might be returned.
Yeah, that would make sense.
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-20 15:39 ` Maxime Ripard
@ 2022-01-20 18:10 ` Stefan Wahren
2022-01-20 19:48 ` Florian Fainelli
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Wahren @ 2022-01-20 18:10 UTC (permalink / raw)
To: Maxime Ripard
Cc: Florian Fainelli, Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
Hi Maxime,
Am 20.01.22 um 16:39 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Sun, Jan 16, 2022 at 06:26:58PM +0100, Stefan Wahren wrote:
>> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
>> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
>> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
>> the connected HDMI monitor off and on again.
> By turning the monitor on and off, you mean that you used the power
> button on it?
yes, correct
> Not something like disabling the output in sysfs, right?
>
>> Kernel output is the following:
>>
>> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
>> unhandled: 0
>> [15053.295440] ->handle_irq(): 00000000b28cf1d1,
>> brcmstb_l2_intc_irq_handle+0x0/0x1e0
>> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
>> [15053.315233] ->action(): 00000000236e815e
>> [15053.322022] ->action->handler(): 0000000013023289,
>> bad_chained_irq+0x0/0x50
>> [15053.331909] IRQ_LEVEL set
>> [15053.337822] IRQ_NOPROBE set
>> [15053.343715] IRQ_NOREQUEST set
>> [15053.349585] IRQ_NOTHREAD set
> IRQ10 is the interrupt that a monitor has been connected on HDMI1, which
> makes sense if you were using HDMI1.
The irq number in this output is always 10 regardless of the used HDMI
connector (0 or 1). So maybe it's the hardware interrupt? Also in the
interrupts list there is a interrupt with number 10 in the first column,
which has the name (null) and it's count is identical to the occured
warnings.
[ 0.000000] irq_brcmstb_l2: registered L2 intc
(/soc/interrupt-controller@7ef00100, parent irq: 10)
> Usually, when a display is turned
> on, it will issue a pulse on the HPD line so we would have a
> disconnection interrupt followed by a connection interrupt.
>
> This is weird though, since we have an interrupt handler on that
> interrupt (hpd-connected in the DT binding):
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L1578
I played a little bit with turn on/off and it seems the connect
interrupts get lost sometimes (see below). I mean the warning doesn't
occur always, it happens most of the time.
reduced /proc/interrupts for HDMI 0 case:
10: 5 0 0 0 GICv2 128 Level
(null)
...
43: 1 0 0 0
interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
44: 0 0 0 0
interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
47: 4 0 0 0
interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
48: 7 0 0 0
interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
49: 0 0 0 0
interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
50: 0 0 0 0
interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
53: 0 0 0 0
interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
54: 0 0 0 0
interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
...
Err: 5
/proc/interrupts for HDMI 1 case:
10: 6 0 0 0 GICv2 128 Level
(null)
...
43: 0 0 0 0
interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
44: 0 0 0 0
interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
47: 0 0 0 0
interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
48: 0 0 0 0
interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
49: 0 0 0 0
interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
50: 0 0 0 0
interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
53: 3 0 0 0
interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
54: 7 0 0 0
interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
...
Err: 6
I could send a diff of the config against arm64/defconfig? Contrary to
the Raspberry Pi OS, Arch Linux uses U-Boot not sure this is related.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-20 18:10 ` Stefan Wahren
@ 2022-01-20 19:48 ` Florian Fainelli
2022-01-20 21:23 ` Stefan Wahren
0 siblings, 1 reply; 10+ messages in thread
From: Florian Fainelli @ 2022-01-20 19:48 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
On 1/20/2022 10:10 AM, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 20.01.22 um 16:39 schrieb Maxime Ripard:
>> Hi Stefan,
>>
>> On Sun, Jan 16, 2022 at 06:26:58PM +0100, Stefan Wahren wrote:
>>> recently i saw a report [1] about bad chained IRQ with Linux 5.15.13
>>> Aarch64 with Arch Linux. I'm able to reproduce this issue on my
>>> Raspberry Pi 4 B (8 GB RAM, Firmware: 2022-01-06T15:39:30) by turning
>>> the connected HDMI monitor off and on again.
>> By turning the monitor on and off, you mean that you used the power
>> button on it?
> yes, correct
>> Not something like disabling the output in sysfs, right?
>>
>>> Kernel output is the following:
>>>
>>> [15053.285438] irq 10, desc: 00000000acc41fca, depth: 0, count: 0,
>>> unhandled: 0
>>> [15053.295440] ->handle_irq(): 00000000b28cf1d1,
>>> brcmstb_l2_intc_irq_handle+0x0/0x1e0
>>> [15053.306049] ->irq_data.chip(): 000000005f172760, gic_data+0x0/0x768
>>> [15053.315233] ->action(): 00000000236e815e
>>> [15053.322022] ->action->handler(): 0000000013023289,
>>> bad_chained_irq+0x0/0x50
>>> [15053.331909] IRQ_LEVEL set
>>> [15053.337822] IRQ_NOPROBE set
>>> [15053.343715] IRQ_NOREQUEST set
>>> [15053.349585] IRQ_NOTHREAD set
>> IRQ10 is the interrupt that a monitor has been connected on HDMI1, which
>> makes sense if you were using HDMI1.
>
> The irq number in this output is always 10 regardless of the used HDMI
> connector (0 or 1). So maybe it's the hardware interrupt? Also in the
> interrupts list there is a interrupt with number 10 in the first column,
> which has the name (null) and it's count is identical to the occured
> warnings.
10 is the virtual interrupt number of the interrupt descriptor
allocated, the hardware interrupt is 128 (32 for the SPI offset and 96
for the actual number within the SPI).
>
> [ 0.000000] irq_brcmstb_l2: registered L2 intc
> (/soc/interrupt-controller@7ef00100, parent irq: 10)
>
>> Usually, when a display is turned
>> on, it will issue a pulse on the HPD line so we would have a
>> disconnection interrupt followed by a connection interrupt.
>>
>> This is weird though, since we have an interrupt handler on that
>> interrupt (hpd-connected in the DT binding):
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L1578
>
> I played a little bit with turn on/off and it seems the connect
> interrupts get lost sometimes (see below). I mean the warning doesn't
> occur always, it happens most of the time.
The fact that you are losing interrupts makes sense because we have a
level handler registered for HW interrupt 128 which "steals" the
interrupt events from the L2 interrupt controller handler that would
process them as edge, if used. The complains from the kernel is because
on one hand the interrupt descriptor wants a certain set of properties
(level triggered in particular), but the flow that is installed by
irq-brcmstb-l2 is of edge type, mayhem ensues.
>
> reduced /proc/interrupts for HDMI 0 case:
>
> 10: 5 0 0 0 GICv2 128 Level
> (null)
> ...
>
> 43: 1 0 0 0
> interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
> 44: 0 0 0 0
> interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
> 47: 4 0 0 0
> interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
> 48: 7 0 0 0
> interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
> 49: 0 0 0 0
> interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
> 50: 0 0 0 0
> interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
> 53: 0 0 0 0
> interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
> 54: 0 0 0 0
> interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
>
> ...
>
> Err: 5
>
> /proc/interrupts for HDMI 1 case:
>
> 10: 6 0 0 0 GICv2 128 Level
> (null)
> ...
> 43: 0 0 0 0
> interrupt-controller@7ef00100 0 Edge vc4 hdmi cec tx
> 44: 0 0 0 0
> interrupt-controller@7ef00100 1 Edge vc4 hdmi cec rx
> 47: 0 0 0 0
> interrupt-controller@7ef00100 4 Edge vc4 hdmi hpd connected
> 48: 0 0 0 0
> interrupt-controller@7ef00100 5 Edge vc4 hdmi hpd disconnected
> 49: 0 0 0 0
> interrupt-controller@7ef00100 8 Edge vc4 hdmi cec tx
> 50: 0 0 0 0
> interrupt-controller@7ef00100 7 Edge vc4 hdmi cec rx
> 53: 3 0 0 0
> interrupt-controller@7ef00100 10 Edge vc4 hdmi hpd connected
> 54: 7 0 0 0
> interrupt-controller@7ef00100 11 Edge vc4 hdmi hpd disconnected
>
> ...
>
> Err: 6
>
> I could send a diff of the config against arm64/defconfig? Contrary to
> the Raspberry Pi OS, Arch Linux uses U-Boot not sure this is related.
Can we get the full dump of the Device Tree that you are running with?
Something like:
dtc -I fs /proc/device-tree -O dts > live.dts
would be helpful to figure out what is going on here.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-20 19:48 ` Florian Fainelli
@ 2022-01-20 21:23 ` Stefan Wahren
2022-01-20 21:38 ` Florian Fainelli
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Wahren @ 2022-01-20 21:23 UTC (permalink / raw)
To: Florian Fainelli, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
Hi,
Am 20.01.22 um 20:48 schrieb Florian Fainelli:
>
> Can we get the full dump of the Device Tree that you are running with?
> Something like:
>
> dtc -I fs /proc/device-tree -O dts > live.dts
>
> would be helpful to figure out what is going on here.
sorry guys, i assumed that the Arch people know what they do. I figured
out that they mixed the vendor DTB with the mainline kernel.
Thanks a lot
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-20 21:23 ` Stefan Wahren
@ 2022-01-20 21:38 ` Florian Fainelli
2022-01-21 3:51 ` Florian Fainelli
0 siblings, 1 reply; 10+ messages in thread
From: Florian Fainelli @ 2022-01-20 21:38 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
On 1/20/2022 1:23 PM, Stefan Wahren wrote:
> Hi,
>
> Am 20.01.22 um 20:48 schrieb Florian Fainelli:
>>
>> Can we get the full dump of the Device Tree that you are running with?
>> Something like:
>>
>> dtc -I fs /proc/device-tree -O dts > live.dts
>>
>> would be helpful to figure out what is going on here.
>
> sorry guys, i assumed that the Arch people know what they do. I figured
> out that they mixed the vendor DTB with the mainline kernel.
No worries, it's always good to be thrown debugging exercises :), glad
you figured it out.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle
2022-01-20 21:38 ` Florian Fainelli
@ 2022-01-21 3:51 ` Florian Fainelli
0 siblings, 0 replies; 10+ messages in thread
From: Florian Fainelli @ 2022-01-21 3:51 UTC (permalink / raw)
To: Stefan Wahren, Maxime Ripard
Cc: Phil Elwell, Dave Stevenson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Nicolas Saenz Julienne
On 1/20/2022 1:38 PM, Florian Fainelli wrote:
>
>
> On 1/20/2022 1:23 PM, Stefan Wahren wrote:
>> Hi,
>>
>> Am 20.01.22 um 20:48 schrieb Florian Fainelli:
>>>
>>> Can we get the full dump of the Device Tree that you are running with?
>>> Something like:
>>>
>>> dtc -I fs /proc/device-tree -O dts > live.dts
>>>
>>> would be helpful to figure out what is going on here.
>>
>> sorry guys, i assumed that the Arch people know what they do. I figured
>> out that they mixed the vendor DTB with the mainline kernel.
>
> No worries, it's always good to be thrown debugging exercises :), glad
> you figured it out.
The kernel could have been a bit more verbose about that error case, let
me try to reproduce this locally with a maliciously crafted DTB and see
if we can detect an attempt to register a flow handler on an existing
interrupt descriptor, and vice versa.
Thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-01-21 3:53 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-16 17:26 [BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle Stefan Wahren
2022-01-16 20:15 ` Florian Fainelli
2022-01-17 4:59 ` Florian Fainelli
2022-01-20 15:54 ` Maxime Ripard
2022-01-20 15:39 ` Maxime Ripard
2022-01-20 18:10 ` Stefan Wahren
2022-01-20 19:48 ` Florian Fainelli
2022-01-20 21:23 ` Stefan Wahren
2022-01-20 21:38 ` Florian Fainelli
2022-01-21 3:51 ` Florian Fainelli
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.