On Thu, 15 Jul 2004, Todd Fischer wrote: > Hi, > > Here is some debug output I captured showing a problem I am having with the > file backed storage driver. > > In English, what appears to be happening is the host sends the mode > select(6) command, which is not supported by file_storage.c. The response > causes the bulk-out ep to be stalled nd the fifos flushed. The error > response is sent and an empty buffer is queued to receive the next bulk-out > data.
... > The problem I am seeing is the next bulk-out data that is received is > responded to with a stall, because the file_storage.c driver didn't call the > UDC set_halt() function with a clear stall indication. > > Am I missing something or is one of the other UDC APIs (like flush or queue) > suppose to also clear the stall? > > Todd Fischer On Thu, 15 Jul 2004, David Brownell wrote: > The USB host is supposed to clear it. I think the current 2.6 > kernels behave right there, but I'm not sure about older > Linuxes or other operating systems. > > Out of curiosity, what UDC are you using? The ones I know > about so far don't have both ep1in and ep1out. > > - Dave On Thu, 15 Jul 2004, Todd Fischer wrote: > 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. > > I am developing a UDC for the TI DM270 which has a UDC tailored for a > digital camera use model. I had to create separate ep1in and ep1out > endpoint instead of a single bidi ep to make file_storage.c (and zero.c) > happy. > > 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. The sequence of events as described sounds correct and legal according to the specification. The upshot is that the host realizes from the CSW that the command has failed, but it doesn't know that the bulk-out endpoint is stalled since all the data was sent before the Halt feature got set. 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. So ultimately communication resumes, but the host has no idea what happened to the command and why it got an error. It will probably retry several times and then give up on the MODE SELECT. 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. 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
