On Thu, Jun 03, 2004 at 12:45:40PM -0700, Pete Zaitcev wrote:
> 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? The patch came to suse from Dell as well, in a form of a 2.4 patch. Since there have been some probing failures which might have been caused by this patch (but now it seems they were more likely caused by a too big INQUIRY command sent by hwscand), I ported the patch to 2.6, and submitted it for discussion to Greg, Matthew, and the list. The logic behind the patch - that a USB-SCSI device might be sensitive to EP0 transfers, even when it's not using EP0 at the time seems correct, though. The deadlocks might actually be my fault, as I re-used the serialize semaphore, while the original 2.4 patch used it's own. The story is at: http://bugzilla.suse.de/show_bug.cgi?id=40827 > 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 > -- Vojtech Pavlik SuSE Labs, SuSE CR ------------------------------------------------------- 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
