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...
        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
                                        Call end_unlink_async()!

> ========= CUT HERE
> Modify EHCI irq handling on the theory that at least some of the
> "lost" IRQs are caused by goofage between multiple lowlevel IRQ
> acking mechanisms:  try rescanning before we exit the handler, in
> case the EHCI-internal ack (by clearing the irq status) doesn't
> always suffice for IRQs triggered nearly back-to-back.

This might help, but it won't fix the race outlined above.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to