On Fri, 25 Jun 2004, Tommy Faasen wrote:
> I increased the delay to 100 milliseconds but unfortunatly without any
> luck, the output again below
> If it's not to much trouble could you or anybody explain what goes wrong
> in the following excerpt
>
> uhci_hcd 0000:00:07.2: uhci_result_control: failed with status 440000
This line simply indicates a failure; the 440000 means "Stalled CRC/Timeo",
same as below.
> [e6aa8240] link (26aa81e2) element (26aa7040)
This lists the memory addresses of the transfer that failed; it's not very
important.
> 0: [e6aa7040] link (26aa7080) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0
> Dev=0, PID=2d(SETUP) (buf=2661c208)
This gives the memory address, settings, and status for the first packet
in the failed SET-ADDRESS transfer. Like all control messages,
SET-ADDRESS starts with a Setup packet (this one) and ends with a Status
packet (the next one). The entries listed here are normal for Setup
packets, except for "Stalled" (which really just means that an error
occurred) and "CRC/Timeo" (which indicates what sort of error).
There are several possible errors that will result in "CRC/Timeo": invalid
bitstuff sequences, CRC mismatch (both of which could result from
electrical noise in the cable), lack of response from the device, or (for
Setup packets only) any response other than ACK. In this case the error
probably comes from the device not sending a response, although I can't
be certain of that.
Now, as for _why_ your device isn't responding... Beats me.
> 1: [e6aa7080] link (00000001) e3 IOC Active Length=0 MaxLen=7ff DT1
> EndPt=0 Dev=0, PID=69(IN) (buf=00000000)
This is the Status packet. It's marked Active, which means that the
packet hasn't been sent yet. This makes sense, since there already was an
error with the Setup packet.
In the full log you see this error occur twice in a row, because Linux
tries to send the SET-ADDRESS message twice. Then it tries all over
again, doing the same thing with a different address. If that fails too,
Linux gives up entirely on the device.
Come to think of it, I told you to increase the time delay before the
usb_get_device_descriptor() call. But that comes _after_ the call to
hub_set_address(), which is the one that's failing. Maybe you should try
adding a line that says
msleep(100);
(or perhaps a longer delay -- you can try 1000 or even higher) immediately
before the call to hub_set_address().
Alan Stern
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
