On Thu, 3 Jun 2004 12:07:50 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Thu, Jun 03, 2004 at 02:05:42PM -0400, Alan Stern wrote: > > > > Greg, I'm afraid the patch from Vojtech has to be reverted. > > I agree. I've just done that, thanks.
I'm surprised that nobody noticed that the patch originates with Dell people hitting a problem with Red Hat (on 2.4), and we discussed it on the list. It is definitely needed for 2.4 in Red Hat, however I tried to turn it down for generic code even though it's not my area and Matt and Alan didn't have a problem with it. The problem comes about because Red Hat installer tries to optimize things and probes something in parallel, so when it runs updfstab it can overlap with normal accesses and devices choke. I assumed that SuSE was not affected, but apparently they were, or why else Vojtech became involved. I raised the question of applicability to 2.6 and the concensus was that control queueing in uhci-hcd takes care of it. Now it seems that it doesn't, is this accurate? Vojtech, did you actually see the failure on 2.6, or it's just speculation by Gary & Santosh @Dell? -- Pete P.S. Check this for the reference (unfortunately, limited to Dell Group): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120894 Synopsys: Bootup stalls indefinately with 2 empty USB cdroms attached Reporter: Gary Lerhaupt (gary_lerhaupt dell.com) --- Comment #4: It appears that two threads are accessing the device at the same time, and the following sequence occurs: READ_TOC CBW to bulk pipe GET_DESCRIPTOR to pipe 0 (from a different thread) attempt to read READ_TOC data from bulk pipe--stalls driver attempts to do CLEAR_FEATURE to clear stall, but submit_urb fails because there's already an URB going on pipe 0 (the GET_DESCRIPTOR) driver attempts to read CSW (never mind that it couldn't clear the stall)--gets NAK because pipe still stalled driver attempts to do CLEAR_FEATURE to clear stall, but submit_urb fails because there's already an URB going on pipe 0 (still the GET_DESCRIPTOR) i think the driver attempts to get the CSW again, fails in the same way continuous READ_TOC commands (all of which get NAKed) appear on USB bus, along with attempts to read the GET_DESCRIPTOR data (which are also NAKed) I'm not totally sure how this is supposed to work, but this is obviously wrong. One of the following things has to happen, I think: (1) the CLEAR_FEATURE has to be retried or queued until pipe 0 is free if usb_stor_Bulk_transport has to clear a stall (2) the usb driver shouldn't let any other thread put commands like GET_DESCRIPTOR on pipe zero from the time that usb-storage puts out a CBW until the time that the CSW is read (3) the CLEAR_FEATURE should go out on pipe 0 to replace the GET_DESCRIPTOR, and the GET_DESCRIPTOR should be retried later (this doeesn't sound like a good idea to me, though) Any thoughts? ---- End comment ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
