At 01:27 PM 7/16/02 -0700, Matthew Dharm wrote: >Well, the semantic meaning of STALL really varies among the DWGs. STALL in >usb-storage land is a pretty common occurance, actually. It's used to >indicate a problem in a single phase of the transaction (which is multiple >transfers) and keep synchronization between host and target. > >Matt
Hi Matt, Yes you are right. The USB class stuff seems to have been defined by the fastest=first!=best manufacturer of a device in each class. This results in some pretty awful class definitions (audio class defined by Philips, HID by Microsoft?? and storage by ???). Some classes even do SETUP commands as part of a data transfer protocol, pretty weird and restrictive of future combo devices. I would guess this is the case for storage and why STALL would be common. Regards, Steve >On Tue, Jul 16, 2002 at 11:45:28AM -0700, Steve Calfee wrote: > > At 10:33 AM 7/16/02 -0700, Matthew Dharm wrote: > > >That's what a clean unlink looks like under EHCI? Okay, then.... > > > > > >The only reason command_abort() gets called is that the command has been > > >out for over 20 seconds. For that to occur during the data phase (and > > >combined with the 'hang' at the CSW stage) means that the HCD thinks that > > >the device is NAKing. > > > > > >My -guess- is that the data toggle has been screwed up somewhere. If it's > > >not an EHCI problem, then the device is basically refusing to transfer > > >anything in. We should get status or data or _something_, but never > > >silence from the device. > > Actually in the USB spec, no response is a necessary state in the > protocol. > > ACK means that the receiver got the packet and it was ok. NAK means the > > receiver got the packet and it was ok, but the receiver is not ready and > > wishes to have this resent later (in this case only a device issues a NAK. > > A host cannot NAK - he just shouldn't ask if he is not ready for the > data). > > A STALL is an interesting response, it means good data got to the device, > > the device could accept the data, but the control/SETUP data made no > sense. > > It generally means the higher level driver is broken. A host cannot STALL. > > > > In the case of a real transmission error ie bad crc or bad PID or bad > > data0/1 state the proper response from the receiver is to not respond. > > There is a spec'd minimum number of usb bus clocks (3 or 4, I dont > > remember) that defines a timeout on the bus, so the sender knows that the > > transmission failed and needs to be retried. The problem is if the host > > screws up the data0/1 state the device will continue to no-response the > bad > > packet forever...until a higher level timeout occurs in the host and the > > higher level driver gets the state fixed. > > > > Regards, Steve. ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
