[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0802201725070.24070-100000@iolanthe.rowland.org>
Date: Wed, 20 Feb 2008 17:33:04 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: David Brownell <david-b@...bell.net>
cc: Andre Tomt <andre@...t.net>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>
Subject: Re: USB OOPS 2.6.25-rc2-git1
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists