----- Original Message -----
From: Georg Acher <[EMAIL PROTECTED]>
To: USB Developer List <[EMAIL PROTECTED]>
Sent: Thursday, June 01, 2000 5:38 PM
Subject: Re: [linux-usb] usb-uhci errors, someone please translate?
> On Thu, Jun 01, 2000 at 04:22:11AM +0000, Matthew Dharm wrote:
> > [...]
> > However, the usb-uhci driver does spew some error message that might be
> > informative. Could someone please explain to me what these mean?
> >
> > [...]
> >
> usb-uhci-debug.h: TD @ cdf6b0c0/0DF6B0C0, MaxLen=07 DT0 EP=0 Dev=3
> > PID=(SETUP) buf=0df07360
> > usb-uhci-debug.h: Len=07 e0 Stalled CRC/Timeo
> > usb-uhci-debug.h: Link points to TD @ 0df6b1c0, Breadth first
> > usb-uhci.c: interrupt, status 2, frame# 1983
> > usb-uhci-debug.h: TD @ cded7fa0/0DED7FA0, MaxLen=07 DT0 EP=0 Dev=3
> > PID=(SETUP) buf=0df07360
> > usb-uhci-debug.h: Len=07 e0 Stalled CRC/Timeo
> > usb-uhci-debug.h: Link points to TD @ 0df6b2c0, Breadth first
> >
> > Can someone explain to me what the HCD is trying to tell me?
>
> That you have encountered one of the ugliest errors on USB... The device
is
> simply not responding anymore (even no NAK). The "CRC/Timeout" should be
> formatted as "crc/!!!TIMEOUT!!!".
How do you conclude it is NOT a CRC error?
I have a device exhibiting similar behaviour.
Assuming it is a TIMEOUT: How long is the timeout? Does the USB spec define
this value?
> I assume that the device's firmware gets so confused about the first bulk
> message and the clear_halt, that it crashes. I know a similar behavior
from
> an Atmel hub, that crashes after a while when asked for string descriptors
> it doesn't have. The CATC shows no unusual behavior from the HCD side.
My device spits out numerous debugging messages on its slow RS232 interface.
It does so during enumeration as well. This even prevented enumeration on
a Windows 2000 host (UHCI), worked all right on Win 98 (UHCI).
I will try to switch off all remaining debugging and see if the HCD
"crc/!!!TIMEOUT!!!"
goes away.
Can the HCD distinguish between CRC and timeout errors?
If so, we should introduce separate error codes.
Stefan.
SpheronVR AG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
