#4322 NORM Never A: Kernel crash while suspending
Zarro Boogs per Child
bugtracker at laptop.org
Tue Oct 23 20:47:32 EDT 2007
#4322: Kernel crash while suspending
---------------------+------------------------------------------------------
Reporter: wad | Owner: dilinger
Type: defect | Status: new
Priority: normal | Milestone: Never Assigned
Component: distro | Version:
Resolution: | Keywords:
Verified: 0 |
---------------------+------------------------------------------------------
Comment(by dilinger):
The end_unlink_async is called during EHCI's unlink handshake. According
to the EHCI spec, we wait for the queue head (QH) to go inactive, remove
the QH from the async list, and then we must wait for the host controller
(HC) to stop using the QH before we can reclaim it. In
start_unlink_async, we set ehci->reclaim to the newly removed QH, set
ehci->reclaim_ready = 0, and set CMD_IAAD in USBCMD. The HC should raise
in interrupt when it is no longer referencing the QH, and it'll set
STS_IAA in USBSTS. In ehci_irq, if STS_IAA is set, we set
ehci->reclaim_ready=1, and call ehci_work(ehci) to do the actual removal.
If we never get the IAA interrupt, the watchdog timer would trigger and
spit out a "lost IAA" msg.
Current theory: we set ehci->reclaim prior to suspend, set CMD_IAAD, and
wait for the interrupt. Then we start to suspend. During the suspend, we
kill off the ehci->reclaim stuff, but for some reason USBINTR isn't
disabled (note in the backtrace above, we've already done the usb host
suspension when we get the oops). Then the hardware raises an interrupt,
the irq handler is called, we see that the HC has stopped using the QH, so
we attempt to unlink it... except the driver has already been suspended,
and ehci->reclaim is NULL.
Could still very well be due to the usb persistence stuff.. need to grok
the usb suspension stuff.
--
Ticket URL: <https://dev.laptop.org/ticket/4322#comment:7>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs
mailing list