[Bugme-new] [Bug 19992] New: b44 + CONFIG_DEBUG_SHIRQ (=y on fedora) fails to resume
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Sun Oct 10 09:57:11 PDT 2010
https://bugzilla.kernel.org/show_bug.cgi?id=19992
Summary: b44 + CONFIG_DEBUG_SHIRQ (=y on fedora) fails to
resume
Product: Drivers
Version: 2.5
Kernel Version: 2.6.36-rc7
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Network
AssignedTo: drivers_network at kernel-bugs.osdl.org
ReportedBy: james at albanarts.com
Regression: Yes
b44 network driver causes system to hang on resume when CONFIG_DEBUG_SHIRQ=y.
I've done some TRACE_RESUME'ing and the following happens:
* b44_resume() (drivers/net/b44.c) calls request_irq with IRQF_SHARED (after
freeing it in the suspend function)
* request_irq() (kernel/irq/manage.c) calls the interrupt handler directly if
IRQF_SHARED and CONFIG_DEBUG_SHIRQ=y. It says "It's a shared IRQ -- the driver
ought to be prepared for it to happen immediately, so let's make sure...."
* b44_interrupt() gets as far as the first br32 and no further:
istat = br32(bp, B44_ISTAT);
I presume it hasn't yet woken the device up so reading a register somehow fails
and hangs the system.
If I comment out the code in request_irq() to test the shared irq handler all
works fine.
I'm guessing either the b44 driver shouldn't be freeing/requesting irqs in
suspend/resume functions, or should be resetting the hardware first so that the
test handler call doesn't fail, but I don't know enough about why it is freeing
the irq across suspend to be confident fixing it.
This has been like this for a while (2.6.34 at least). Suspend used to work on
fedora with this hardware so I think this is a regression. I'm happy to test
any patches.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Bugme-new
mailing list