On Fri, 16 Jul 2004, Todd Fischer wrote: > 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).
No, you're wrong there. The device does know how much data will be sent; it's the dCBWDataTransferLength field of the CBW. > 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. No, the host would never send associated data after it had cleared the stall. After all, since the host clears the stall it knows that the command has already failed. > 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). That would definitely be worth tracking down, and I would like to hear what you find. In my tests I haven't seen any such problems. > > 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. Well, I can can only fix hosts where I can write the driver! :-) More seriously, see my previous message about the stall=n option in the g_file_storage driver. Arguably that should be the default, rather than stall=y. Alan Stern ------------------------------------------------------- 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
