On Wednesday 20 February 2008, Alan Stern wrote: > On Wed, 20 Feb 2008, David Brownell wrote: > > > On Wednesday 20 February 2008, Alan Stern wrote: > > > > ehci_hcd 0000:00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021 > > > > > > lines in the log brings up some ideas that have been percolating in my > > > mind for a while. They have to do with the possibility of a race > > > between the watchdog routine and assertion of IAA. > > > > The curious bit IMO being STS_INT (0001), which should also have > > triggered an IRQ. Suggesting to me that the race might be lower > > level than that ... at the level of a conflict between the various > > mechanisms to ack irqs. > > Maybe it did trigger an IRQ. Inside the watchdog routine interrupts > are disabled. > > > > In fact, if the timing comes out just wrong then it's possible (on SMP > > > systems) for an IAA interrupt to arrive when the watchdog > > > routine has already started running. Then end_unlink_async() might get > > > called right at the start of a new IAA cycle, or when the reclaim list > > > is empty. > > > > The driver's spinlock should prevent that particular problem from > > appearing. > > I don't think so: > > CPU 0 CPU 1 > ----- ----- > Watchdog timer expires > Timer routine acquires spinlock > IAA IRQ arrives > ehci_irq tries to acquire > spinlock...
There's another condition here, and another action. The condition is that ehci->reclaim must first be set; the action is to clear STS_IAA (and, given the previous patch, maybe IAAD). And this "either" is more concisely written as "call end_unlink_async()" (point made just for clarity). > Timer routine either sets > ehci->reclaim to NULL > or else starts a new > IAA cycle > Timer routine releases spinlock > and returns > ehci_irq acquires spinlock > and sees IAA is set Can only happen if a new IAA cycle was started by CPU0, and the IAA condition triggered that quickly. > Call end_unlink_async()! > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html