On Friday 25 May 2007, Alan Stern wrote:
> On Fri, 25 May 2007, Yum Rayan wrote:
> > > > ohci_hcd 0000:00:04.0: urb c3a33e00 path 1 ep1in 6d160000 cc 6 -->
> > > > status -71
> > > > ohci_hcd 0000:00:04.0: urb c7881cc0 path 2 ep1in 6d160000 cc 6 -->
> > > > status -71
You might consider preventing that diagnostic when "cc == TD_PIDCHECKFAIL"
and an ISP1563 quirk applies ... of course it's only seen if you manually
enable verbose diagnostics.
> > We checked the USB cable and protocol on the wire and everything looks
> > good. The USB device that is connected to the hosts looks fine well.
> >
> > Finally we see this in the NXP ISP1563_Errata_070417:
> >
> > "Afer receiving a continous series of NAKs, ranging from 150 ms to 500
> > ms, the ISP1563 will retun a condition code 06h (PID failure) in the
> > general Transfer Descriptor (TD). This error causes the software to
> > stall the endpoint"
They must be thinking of MS-Windows or something ... this isn't
a TD_CC_STALL, so Linux would never report a stall!!
> > "The workaround is to provide a software patch.
> > The HCD can be modified so that whenever a PID check failure occurs,
> > the HCD will not inform the client driver. Instead it just resubmits
> > the TD on its own and the transaction continues".
> >
> > Is there exisiting code that demonstrates how to resubmit a TD? The
> > suggested workaround does not seem good design. Any ideas?
>
> There is no demonstration code for resubmitting a TD, as far as I know.
> You'll have to try writing your own.
It's probably made easier by the fact that, unless they managed
to *really* break OHCI, the TD queue on the relevant endpoint is
something like
ED->HEAD ------------------------+
v
TD0 .. TD1 .. (TD2/PIDCHECK) .. TD3 .. TD4 .... dummy
^
ED->TAIL -----------------------------------------+
So all you "should" need to do is re-activate the TD and patch
the ED.
> You're right that the workaround doesn't seem like a good design. What
> would happen when a real PID error occurs? Admittedly this is highly
> unlikely.
Both "unexpected PID" and "PID check failure" are reported as EPROTO,
FWIW. It's kind of surprising they shipped the hardware with this
kind of erratum. Long sequences of NAKs are pretty routine...
There's already logic in usbnet to back off given the EPROTO errors,
then restart ... you should have gotten 'rx throttle' message, at
least if you enabled link diagnostics with ethtool.
So I'd find out first why things seemed to "lock up" rather than
continue functioning. Sure the misbehavior is triggered by that
hardware bug, which as Alan noted would normally be rare. Once
that's resolved, you can consider whether it's worthwhile adding
a nasty workaround, to avoid triggering the throttle/reactivate
logic. I suspect it shouldn't be worthwhile...
- Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
