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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
