[BUG] bcm2711: bad_chained_irq in brcmstb_l2_intc_irq_handle

Florian Fainelli f.fainelli at gmail.com
Thu Jan 20 11:48:30 PST 2022



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 at 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 at 7ef00100   0 Edge      vc4 hdmi cec tx
>   44:          0          0          0          0
> interrupt-controller at 7ef00100   1 Edge      vc4 hdmi cec rx
>   47:          4          0          0          0
> interrupt-controller at 7ef00100   4 Edge      vc4 hdmi hpd connected
>   48:          7          0          0          0
> interrupt-controller at 7ef00100   5 Edge      vc4 hdmi hpd disconnected
>   49:          0          0          0          0
> interrupt-controller at 7ef00100   8 Edge      vc4 hdmi cec tx
>   50:          0          0          0          0
> interrupt-controller at 7ef00100   7 Edge      vc4 hdmi cec rx
>   53:          0          0          0          0
> interrupt-controller at 7ef00100  10 Edge      vc4 hdmi hpd connected
>   54:          0          0          0          0
> interrupt-controller at 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 at 7ef00100   0 Edge      vc4 hdmi cec tx
>   44:          0          0          0          0
> interrupt-controller at 7ef00100   1 Edge      vc4 hdmi cec rx
>   47:          0          0          0          0
> interrupt-controller at 7ef00100   4 Edge      vc4 hdmi hpd connected
>   48:          0          0          0          0
> interrupt-controller at 7ef00100   5 Edge      vc4 hdmi hpd disconnected
>   49:          0          0          0          0
> interrupt-controller at 7ef00100   8 Edge      vc4 hdmi cec tx
>   50:          0          0          0          0
> interrupt-controller at 7ef00100   7 Edge      vc4 hdmi cec rx
>   53:          3          0          0          0
> interrupt-controller at 7ef00100  10 Edge      vc4 hdmi hpd connected
>   54:          7          0          0          0
> interrupt-controller at 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



More information about the linux-arm-kernel mailing list