> -----Original Message----- > From: Alan Stern [mailto:[EMAIL PROTECTED] > Sent: Friday, July 16, 2004 2:13 PM
> > Dave, the host never sees the stall condition until after the > SCSI status is > > sent back. If I put in some debug statements, then the timing changes > > enough and the host does see and clear the stall okay. With > debug off, the > > host sends a new SCSI request without detecting the stall so > the packet > > containing the new SCSI command is stalled. > > > > > > Todd > > Todd, I think you've found a flaw in the Bulk-only protocol. This should > interest Pat LaVarre, one of the protocol's chief designers. Pat, as you > probably already realize, this falls under case (9) of your 13 cases. Alan, I have rewritten this email 3 times with an explanation of the root cause of the problem and a suggestion on how to fix it. However, each time I found my solution to not cover all the cases. I wonder if the mass storage bulk-only transport protocol has a design defect that occurs when a SCSI command which has data from the host (OUT) associated with the command can not be handled by the device. Since the device doesn't handle the command, the device has no way of knowing how much data will be sent (if any). Setting the stall and dumping the FIFOs (current file_storage.c behavior) will clean out the associated data, if it has been sent. As soon as the device sends the SCSI command response, the host is free to send another SCSI request. This implies that before the SCSI response is sent, the stall condition needs to be cleared or the following SCSI request will get stalled (current file_storage.c behavior). However, there is a window from the time the stall is cleared until the host processes the SCSI response where the host could be sending the associated data. I don't see a way around this problem except to use the USBC signature to realize the unexpected associated data to the unsupported SCSI command is not a new SCSI command. > The > next command (probably a REQUEST SENSE) will get an error because the CBW > transfer stalls. This leaves the host with no way to determine the sense > data. Although the protocol doesn't say what should happen next, it seems > that the host's only option is to issue a class-specific device reset > in response to the stall, and that will wipe out the sense information. Windows does a bus reset (which is causing another defect to show up which we think has to do with a race condition during reset, but we haven't tracked it down enough to discuss it yet). > I suppose an alternative would be for the host to automatically do a > clear-halt on the bulk-out pipe whenever a command doing an OUT transfer > gets bCSWStatus = x01 and the pipe didn't stall during the data phase. > The Linux usb-storage driver doesn't do this because the protocol doesn't > say it's necessary. It could be added easily enough. It would not solve the problem on non-Linux hosts. Todd ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
