On Mon, 8 Nov 2004, Patrick Agrain wrote: > Hi everybody, > > Inside a X306 IBM server, there are 2 UHCI-like and 1 EHCI USB controlers > encapsulated in the Intel's 6300ESB chipset. > An HID-like peripheral is connected during the boot-up of the system. > Kernel is 2.4.26. > > Behaviour : > When the peripheral is connected to the front connectors ( bus 2 ), > enumeration works fine and the peripheral is claimed by hiddev. > When connected to the rear connectors ( bus 1 ), the set_address process > fails, but only if the peripheral is already connected at boot time. If > connected after start-up of the system, again, everything works fine.
That is quite strange. If you can find the answer, I would very much like to hear it. > Tests : > I've put an USB bus analyzer and record the enumeration process. > The set_address has a setup and handshake transactions. > > When all works fine, you get : > - setup -> data0 -> ack for the setup transaction and > - in -> data1 -> ack for the handshake transaction. ( See set_address_ok.txt ) > > When not, you get : > - setup -> data0 for the setup transaction and... that's all folks ! ( See > set_address_ko.txt ) > > As Debug is "on", here is the output : > URB [df5b2710] urbp > [df8f71e0] > QH > [df9b11e0] > > td 0: > [df8f6180] > > 1f8f6154 e0 LS Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 > Dev=0, PID=2d(SETUP) > (buf=1f5fed40) > > td 1: > [df8f6150] > > 00000001 e3 LS IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=0, > PID=69(IN) (buf=00000000) > > ...endless looped. > > It seems that the endpoint never send the ack packet in the setup > transaction. That's probably why we get a STALL state. Due to the "e0", > this is looped. Is this correct ? That's about right. The "e0" means that the transfer has been tried 3 times and failed each time. "Stalled CRC/Timeo" is the way the controller reports a missing response to a SETUP packet. > USB spec. says that when the data is corrupted during the setup > transaction, the endpoint sends no handshake. Could it be the reason of > this behaviour ? It could be, although it's not clear why the data would be corrupted only on the rear ports and only at boot time. Furthermore, if your analyzer can receive and display the data then it can't be corrupted very much. > But why only at boot time and only on the rear connectors ? > Has anybody ever been faced with such a behaviour ? I've heard of people having problems with one connector but not another. It turned out to be because of the quality of the internal cabling. Is it possible that somehow the cables to the rear ports suffer from EMI but only when there's a lot of activity going on inside the case, like at boot time? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
