Alan Stern wrote: > On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote: > >> >> Hello... >> >> I'm seeing a problem where I have an empty CD-ROM drive (or two) >> connected to the system, and, every now and then, I get hangs during >> boot (or issues with commands not completing once the system is up). >> >> I've tracked down the issue to a sequence of events similar to the >> following: >> >> --- >> Issue a READ_TOC CBW to bulk out pipe >> >> Issue a GET_DESCRIPTOR to pipe 0 (a different thread does this, >> presumably) >> >> Try to read data for READ_TOC from bulk in pipe -- pipe stalls >> because there's no CD in the drive and therefore no TOC data >> >> Try to issue a CLEAR_FEATURE to clear the stall to pipe 0 -- this >> fails because there's already an URB in progress to pipe 0 >> >> USB driver then tries to read the CSW (never mind that the stall >> wasn't cleared)--this also fails because pipe is stalled >> >> Try to issue a CLEAR_FEATURE again, with similar results >> >> USB bus then gets continuous READ_TOC commands on the USB bus, which >> all >> >> get NAKed (pipe still stalled) >> --- >> >> How should this get handled? > > Under Linux 2.4, one way to handle this is by preventing the other > thread from issuing the GET_DESCRIPTOR to pipe 0 while the CDROM > drive is busy. You could find out what that other thread is and > suspend or kill it. > > Under Linux 2.6 there shouldn't be any problem. > >> I would assume that the CLEAR_FEATURE should get retried after the >> GET_DESCRIPTOR happens, but this certainly isn't what's happening. > > The Host Controller drivers in 2.4 -- the UHCI drivers at least -- > can't handle multiple simultaneous requests to the same control > endpoint. That's not going to change; if you need that capability > then you have to use 2.6. > >> I'm working with RedHat kernel 2.4.21-11, but I've tried 2.4.26, >> which also fails at similar places doing similar things, though I >> saw kernel panics >> >> instead of hangs, so I'm not sure exactly what's happening in 2.4.26. >> >> Thanks! >> Stuart > > Alan Stern
I think one of the threads is updfstab, lsusb, or kudzu, which access the device's pipe 0 through the /proc directory, while the other thread is just cdrom.c trying to do some stuff with the drive. I'm not sure how one could keep these things from running simultaneously. But, once this problem happens, the USB driver can't even be unloaded--one must reboot the system to get the USB subsystem working again! I'm not looking to re-architect the drivers--I just want to do something to keep the system from failing when this happens. Perhaps I could keep the proc_ioctls from running until the device isn't being used by usb-storage, or maybe just make the transport layer of usb-storage retry the clear_feature command for a while if the pipe already has an URB going, instead of simply failing and moving on to the next step without clearing the stall...? Stuart ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id�66&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
