Hello Lukas,
Am 22.06.24 um 20:47 schrieb Lukas Wunner:
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 for your suggestion. Unfortunately placing printk in those busy
interrupt handler is futile, so i switched to debugfs. This issue would
be much easier in case the interrupt wouldn't be shared. But first let
me share some outputs before i start to extend debugfs further:
1. No hub connected to Rpi 3 A+
root@raspberrypi:/sys/kernel/debug/usb/3f980000.usb# cat state
DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007ff02
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf3000806, GINTSTS=0x04000023
DAINTMSK=0x00000000, DAINT=0x00000000
GNPTXSTS=0x00080100, GRXSTSR=3f83bbfe
2. Hub connected before suspend / irq issue
DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007a202
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf300080e, GINTSTS=0x04000023
DAINTMSK=0x00000000, DAINT=0x00000000
GNPTXSTS=0x08080100, GRXSTSR=789a460a
3. Hub connected after suspend / irq issue
DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007ff02
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf1000806, GINTSTS=0x0500002b
DAINTMSK=0x000000ff, DAINT=0x00000000
GNPTXSTS=0x29080100, GRXSTSR=befdf595
Based on my limited knowledge and observations the issue seems related
to GINTMSK/GINTSTS and a outstanding GINTSTS_PRTINT.
Regards
