On Fri, 18 Feb 2005 11:59:41 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> On Friday 18 February 2005 3:03 am, Thibaut VARENE wrote:
> > On rare occasions, error -71 (-EPROTO) shows up for the same endpoint
> > (ie: the only thing that changes in the logmessage is the error
> > value), which seems coherent with the timeout issue ("-EPROTO:
> > bitstuff error during the transfer or No response packet was received
> > in time by the hardware").
>
> If you're using OHCI, you know that EPROTO reflects a real protocol
> error from the device -- never a timeout.
Ah ok. The LDD description was a bit confusing to me ("No response
packet was received in time by the hardware"). All I know about OHCI
comes from LDD actually :-P
> > What are the likely causes of such a behaviour?
>
> OHCI returns that error on a bitstuffing error, or when the wrong
> PID comes back. So basically the signal written by the BT adapter
> looked bogus when it arrived at the USB host.
OK. But since the BT adapter works fine on i386, and another BT
adapter would behave exactly the same, I guess the adapter is not at
fault here. Besides, the EPROTO happened only less that 1% of the
time. 99% of the errors are ETIMEDOUT ones.
Does that make any difference in your reasoning?
> > Is it possible that this symptom is the consequence of a bug in the
> > HCI USB layer, and not an actual OHCI bug?
>
> I could imagine that. You might be able to recover by having
> some task issue a CLEAR_HALT request to that endpoint (using
> the standard USB API) and continuing.
>
> > Could it be a hardware bug?
>
> Yes.
OK. This sounds bad. All I'm left with is:
- Either there's a corner case bug in OHCI or HCI drivers that
triggers only on ARM with my specific controller (and I can't figure
out yet which of these two is the culprit),
- Or the hardware is buggy and doesn't behave well, though it's deemed
OHCI-compliant.
Do you know if there's anything particular to BT devices that would
make only them trigger that bug (aside the fact that they use HCI
USB)? Because USB mass storage works fine.
Or put in another way, would there be some kind of USB device I could
test that wouldn't use the HCI driver but be likely to reproduce that
bug if it's either hardware or OHCI at fault?
That way I'd be able to isolate the root of the problem and then
eventually try to fix it (if it's software, of course). Any other
suggestion is welcome, of course.
Thanks a lot for the answer anyway
--
Thibaut VARENE
http://www.parisc-linux.org/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
