The host controller can halt the pipe for a number of reasons, for example: 

* the three-strikes rule (when it tries 3 times and sees no response), 
* babble errors (when the device sends too late in the microframe), 
* when the device sends a STALL, 

and so forth. You can look at the EHCI or XHCI specs and get a feel for when 
the host might halt a pipe. 

So the fact that you don't see a STALL with your protocol analyzer is not 
really diagnostic. It doesn't tell you that the device didn't do anything to 
provoke the endpoint halt, it only tells you that the endpoint halted for some 
other reason than STALL. 

Best regards,
--Terry

> -----Original Message-----
> From: usb-bounces+tmm=mcci....@lists.apple.com [mailto:usb-
> bounces+tmm=mcci....@lists.apple.com] On Behalf Of Siva Velusamy
> Sent: Wednesday, August 12, 2015 15:41
> To: Barry Twycross
> Cc: usb@lists.apple.com
> Subject: Re: Stall reported by ReadPipe, but no stall in USB Protocol
> Capture
> 
> On Wed, Aug 12, 2015 at 12:19 PM, Barry Twycross <ba...@nestlabs.com>
> wrote:
> >
> >> On Aug 12, 2015, at 11:53 AM, Siva Velusamy <siva.velus...@gmail.com>
> wrote:
> >>
> >> Hello!
> >>
> >> On OS X 10.10.4, we see that ReadPipe returns a stall, but when
> >> looking at the USB packets captured (via Total Phase Beagle), there
> >> are no stalls.
> >>
> >> Are there scenarios where this is possible? And is there any info on
> >> how to recover from such a stall?
> >>
> >> For reference, the code does something like this:
> >>
> >>    result = (*handle->interface)->ReadPipe(handle->interface,
> >> handle->bulkIn, buf, &numBytes);
> >>    if (kIOUSBPipeStalled == result) {
> >>        DBG(" Pipe stalled, clearing stall.\n");
> >>
> >> and that print statement is hit. More application specific
> >> information and the USB capture are attached to
> >> https://code.google.com/p/android/issues/detail?id=182151, comment #8
> >> if anyone is interested.
> >
> > What’s the actual error reported by USB?
> >
> > STALL has two meanings. One a pipe will STALL when any error happens
> involving it. This prevents any further transactions happening on the
> pipe, until the host driver has done something to recover from the error.
> The host driver needs to clear the STALL, then it can carry on.
> >
> > The other is the STALL PID handshake. When a STALL PID is retuned by a
> device it’s telling the host it doesn’t understand the command it was
> sent. A STALL PID also has the effect of the STALLIng the pipe so the
> host driver has to do something about it.
> >
> > You can have a pipe STALL without a STALL PID being involved. You need
> to see the exact error for some clue as to what’s going on. Installing
> the logging family (if available) and looking at the Prober log may also
> be illuminating (and/or confusing).
> 
> It looks like the logging family isn't available as yet. I'm still
> deciphering the prober log.
> 
> However, the confusing part here is that my USB Protocol Analyzer shows
> no stalls. It shows the correct data being returned from the device. So
> are these STALLs something happening at the host side (assuming that
> isn't shown by the protocol analyzer)? Maybe it is the "generic IOKit
> error" as you mention below.
> 
> >
> > Add: I see you did mention the exact error: kIOUSBPipeStalled
> >
> > As USB.h says:
> >
> > #define kIOUSBPipeStalled iokit_usb_err(0x4f) // 0xe000404f  Pipe has
> > stalled, error needs to be cleared
> >
> > The pipe previously STALLed and the host driver has not yet cleared
> the STALL. So this call isn’t the problem, a previous one is.
> >
> > USB.h also notes that a "generic IOKit error instead of a USB specific
> error” is returned for a STALL PID, but notes that kIOUSBPipeStalled is
> returned. So the error code is ambiguous.
> >
> 
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Usb mailing list      (Usb@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/usb/tmm%40mcci.com
> 
> This email sent to t...@mcci.com


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list      (Usb@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to