> From: Siva Velusamy [mailto:[email protected]] > Sent: Wednesday, August 12, 2015 20:45 > To: Terry Moore > Cc: Barry Twycross; [email protected] > Subject: Re: Stall reported by ReadPipe, but no stall in USB Protocol > Capture > > On Wed, Aug 12, 2015 at 4:34 PM, Terry Moore <[email protected]> wrote: > > 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. > > > Thanks Terry. That is good to know. > > Barry helped diagnose this further off thread, and with the help of > another trace, diagnosed that something was clearing the host endpoint > but not telling the device between two sessions. > > I haven't seen the issue so far after adding a ClearPipeStallBothEnds > right after opening the device.
That's usually a great idea. That problem has come up often, and not just on Apple systems. It's sort of a gap in the spec. Best regards, --Terry > >> -----Original Message----- > >> From: [email protected] [mailto:usb- > >> [email protected]] On Behalf Of Siva Velusamy > >> Sent: Wednesday, August 12, 2015 15:41 > >> To: Barry Twycross > >> Cc: [email protected] > >> Subject: Re: Stall reported by ReadPipe, but no stall in USB Protocol > >> Capture > >> > >> On Wed, Aug 12, 2015 at 12:19 PM, Barry Twycross <[email protected]> > >> wrote: > >> > > >> >> On Aug 12, 2015, at 11:53 AM, Siva Velusamy > >> >> <[email protected]> > >> 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 ([email protected]) > >> Help/Unsubscribe/Update your Subscription: > >> https://lists.apple.com/mailman/options/usb/tmm%40mcci.com > >> > >> This email sent to [email protected] > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
