Re: dwc2: irq 66: nobody cared triggered on resume

[Lukas Wunner <lukas@wunner.de>]

On Sat, Jun 22, 2024 at 02:23:33PM +0200, Stefan Wahren wrote:
> i currently experiment with suspend to idle on the Raspberry Pi 3 A+.
> Supend & resume works expected as long as no USB device is connected to
> the board. If i connect a USB hub to the Pi, the resume phase is
> significantly delayed and the kernel disabled IRQ 66 which belongs to DWC2.
[...]
> [ 1131.109996] PM: noirq resume of devices complete after 1.273 msecs
> [ 1131.111208] PM: early resume of devices complete after 1.051 msecs
> [ 1131.230277] brcmfmac: brcmf_fw_alloc_request: using
> brcm/brcmfmac43455-sdio for chip BCM4345/6
> [ 1131.458687] irq 66: nobody cared (try booting with the "irqpoll" option)
> [ 1131.458714] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.10.0-rc3-g7fd4227d1bd5-dirty #49
> [ 1131.458734] Hardware name: BCM2835
> [ 1131.458744] Call trace:
[...]
> [ 1131.458877] note_interrupt from handle_irq_event+0x88/0x8c
> [ 1131.458900] handle_irq_event from handle_level_irq+0xb4/0x1ac
> [ 1131.458923] handle_level_irq from generic_handle_domain_irq+0x24/0x34
> [ 1131.458957] generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28
> [ 1131.458992] bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34
> [ 1131.459024] generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44
> [ 1131.459056] generic_handle_arch_irq from __irq_svc+0x88/0xb0
> [ 1131.459079] Exception stack(0xc1b01f20 to 0xc1b01f68)
> [ 1131.459142] __irq_svc from default_idle_call+0x1c/0xb0
> [ 1131.459167] default_idle_call from do_idle+0x21c/0x284
> [ 1131.459202] do_idle from cpu_startup_entry+0x28/0x2c
> [ 1131.459239] cpu_startup_entry from kernel_init+0x0/0x12c
> [ 1131.459271] handlers:
> [ 1131.459279] [<f539e0f4>] dwc2_handle_common_intr
> [ 1131.459308] [<75cd278b>] usb_hcd_irq
> [ 1131.459329] Disabling IRQ #66
[...]
> An ideas what causing this issue?

Interrupts are re-enabled after the resume_noirq phase.  Looks like
the chip signals an interrupt right afterwards but the two hardirq
handlers do not feel responsible.

The only option might be to add a few printk() in dwc2_handle_common_intr(),
usb_hcd_irq() and dwc2_handle_hcd_intr() (called from usb_hcd_irq())
to see why they're all returning IRQ_NONE without clearing the source
of the interrupt.  The chip just keeps signaling interrupts because
the driver doesn't handle them, hence the IRQ storm which the IRQ core
eventually stops by outright disabling the interrupt.

Thanks,

Lukas