Re: [linux-usb-devel] Re: USBDEVFS_RESET deadlocks USB bus.

[Zephaniah E. Hull]

On Fri, Jul 02, 2004 at 05:11:52PM -0400, Alan Stern wrote:
> On Fri, 2 Jul 2004, Zephaniah E. Hull wrote:
> 
> > On Tue, Jun 08, 2004 at 10:19:40PM +0200, Duncan Sands wrote:
> > > > Great, could you send me the patch? (So I have something usable until it
> > > > gets into mainline and a kernel is released with it.)
> > > 
> > > Sure - I just have to write it first!  It's a bit tricky to do right...
> > 
> > Has there been any progress on this?
> > 
> > I have been looking at the code in question and I am curious as to what
> > events we are attempting to protect against with the serialize spinlock?
> > 
> > Thanks.
> 
> There has been progress.  If you start with the latest 2.6.7 kernels 
> (vanilla or -mm) and apply these two patches:
> 
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108810394203966&q=raw
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108810535225278&q=raw
> 
> the deadlock problems should be solved.  Although those patches haven't 
> yet been merged, I'm pretty sure they will be.

Actually, there is still one remaining from looking at the patches I am
afraid.

Admittedly, it is due to the use of a somewhat, unelegant approach,
however it worked quite well (very nice speed bonuses) before the
locking patches.

Specificly, if you have a thread doing bulk reads on a USB device in a
loop, and the device stops talking to you (for instance, waiting for you
to reply), it becomes impossible to take any action on the device,
including aborting the read or issuing a write to the device to tell it
to keep talking until such a time as the read times out, the device
speaks to us, or the device is physically disconnected.

Using timeouts can mediate this, but at the cost of being far less
responsive unless you use a very short timeout.

I am unsure if the kernel provides the locking infrastructure to allow
us to keep us from reading/writing while doing the various events, while
also allowing us to read and write at the same time.

> To answer your other question...  The serialize semaphore (not spinlock) 
> prevents the system from trying to do several incompatible things to a USB 
> device at the same time.  For example, reset the device while a driver is 
> probing it.  Or reset it while it is being suspended.

Ah, my mistake.

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp@xxxxxxxxxxxxxxxx>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

> Is there an API or other means to determine what video
> card, namely the chipset, that the user has installed
> on his machine?

On a modern X86 machine use the PCI/AGP bus data. On a PS/2 use the MCA bus
data. On nubus use the nubus probe data. On old style ISA bus PCs done a large
pointy hat and spend several years reading arcane and forbidden scrolls

 -- Alan Cox

Attachment: signature.asc
Description: Digital signature