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

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.

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

G:   Baaap booop BAHHHP.
Mir: 9600 Baud?
Mik: No, no!  9600 goes baap booop, not booop bahhhp!
                                        -- Greg, Miranda and Mike
User Friendly, 12/31/1998

Attachment: msg07799/pgp00000.pgp
Description: PGP signature

Reply via email to