On Thu, 4 Apr 2013, Yegor Yefremov wrote: > I reworked my test script, so that I can tell timeout from wrong > string. I have two cases now. On my am335x based system I get timeout > with 3.2 kernel and errors like here > (http://www.newit.co.uk/forum/index.php?topic=313.0) for 3.8. > > On x86 I get fully wrong string. For example, I send "test string" and > get something like that 57 D6 2E 17 A4 2E 5D AE 5A EB F6 on the other > port. > > I've also update the sniffs. They contain 20 cycles each. Let's take > this sniff ftdi_sniff_hub.out > > As far as I understand it, it is normal case, where the data was > received correctly: > > f1172780 1591104533 S Bo:1:004:2 -115 11 = 74657374 20737472 696e67 > f1172780 1591104593 C Bo:1:004:2 0 11 > > f1172400 1591105218 C Bi:1:004:3 0 8 = b1607465 73742073 > f1172400 1591105223 S Bi:1:004:3 -115 512 < > f1172b00 1591105226 C Bi:1:004:1 0 2 = b100 > f1172b00 1591105227 S Bi:1:004:1 -115 512 < > f1172400 1591106217 C Bi:1:004:3 0 7 = b1607472 696e67 > > Here everything will be received, but byte per byte: > > f1172780 1591706391 S Bo:1:004:2 -115 11 = 74657374 20737472 696e67 > f1172780 1591706487 C Bo:1:004:2 0 11 > > f1172400 1591707111 C Bi:1:004:3 0 2 = b160 > f1172400 1591707115 S Bi:1:004:3 -115 512 < > f1172b00 1591707117 C Bi:1:004:1 0 2 = b100 > f1172b00 1591707118 S Bi:1:004:1 -115 512 < > f1172400 1591708112 C Bi:1:004:3 0 3 = b16074 > f1172400 1591708117 S Bi:1:004:3 -115 512 < > f1172b00 1591708120 C Bi:1:004:1 0 2 = b100 > f1172b00 1591708121 S Bi:1:004:1 -115 512 < > f1172400 1591709112 C Bi:1:004:3 0 3 = b16065 ... > And here the second port seems to receive junk: > > f1172780 1592210316 S Bo:1:004:2 -115 11 = 74657374 20737472 696e67 > f1172780 1592210379 C Bo:1:004:2 0 11 > > f1172400 1592210878 C Bi:1:004:3 0 6 = b16895cd d181 > f1172400 1592210883 S Bi:1:004:3 -115 512 < > f1172400 1592211128 C Bi:1:004:3 0 3 = b1609a > f1172400 1592211132 S Bi:1:004:3 -115 512 < > f1172b00 1592211134 C Bi:1:004:1 0 2 = b100 > f1172b00 1592211135 S Bi:1:004:1 -115 512 < > f1172400 1592212128 C Bi:1:004:3 0 8 = b160d1c9 a5b99dff > > I've also found a hub, that looks like 12M hub, but it produces the > same error pattern (wrong chars): > > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > |__ Port 1: Dev 6, If 0, Class=hub, Driver=hub/4p, 12M > |__ Port 1: Dev 7, If 0, Class=vend., Driver=ftdi_sio, 12M > |__ Port 1: Dev 7, If 1, Class=vend., Driver=ftdi_sio, 12M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M > > On USB3.0 host I get 9 chars instead of 11 and they are also wrong. > > Rx/Tx test: baudrate 115200 > Wrong string len: 11 > 95 CD D1 81 9A D1 C9 A5 B9 9D FF > Rx/Tx /dev/ttyUSB0 > /dev/ttyUSB1: FAILED > Rx/Tx test: baudrate 115200 > Rx/Tx /dev/ttyUSB1 > /dev/ttyUSB0: O.K. > Rx/Tx test: baudrate 9600 > Rx/Tx /dev/ttyUSB0 > /dev/ttyUSB1: O.K. > Rx/Tx test: baudrate 9600 > Rx/Tx /dev/ttyUSB1 > /dev/ttyUSB0: O.K. > > Should I make a sniff with them? Should I make a sniff with FT4232H? This is a tough problem, no doubt about it. If you can get hold of a USB bus analyzer to see the actual data as it goes through the cable, it might help to pin down where the problem is -- before the hub or after it. But I suspect that this really is a bug in the FTDI part. This doesn't answer the question of why it works better when attached directly to a USB-1.1 port on the computer. Could it be a matter of available power? Maybe the hubs don't supply enough current. (But then the USB-3 port should work...) Can you reproduce these results under a different operating system (such as Windows)? If you can, you might try asking for help directly from FTDI. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
