On Wed, Apr 3, 2013 at 12:16 PM, Yegor Yefremov <yegorsli...@googlemail.com> wrote: > On Wed, Apr 3, 2013 at 9:12 AM, Yegor Yefremov > <yegorsli...@googlemail.com> wrote: >> On Tue, Apr 2, 2013 at 4:36 PM, Alan Stern <st...@rowland.harvard.edu> wrote: >>> On Tue, 2 Apr 2013, Yegor Yefremov wrote: >>> >>>> On Tue, Apr 2, 2013 at 4:14 PM, Alan Stern <st...@rowland.harvard.edu> >>>> wrote: >>>> > On Tue, 2 Apr 2013, Yegor Yefremov wrote: >>>> > >>>> >> I'm making a burn-in test (see serialtest.py >>>> >> http://pastebin.com/pz47gaar) for our devices, that have built-in FTDI >>>> >> chips. If FT2232C is attached directly to the USB host controller >>>> >> port, the tests run properly. If I connect the chip to a USB-hub some >>>> >> of the tests show timeout errors (read() routine). On the newer host >>>> >> with USB3.0 this issue occurs on all USB ports where I attach FT2232C. >>>> >> I tried kernels 3.2, 3.5 and 3.8. >>>> >> >>>> >> The test procedure opens two ports, exchanges data and closes ports. >>>> >> If I don't open/close ports I don't encounter this issue. >>>> >> >>>> >> The FT4232H has no problems whether I attach it to USB HC or via HUB. >>>> >> Any idea how to workaround the problem? >>>> > >>>> > If you use a different type of hub, does the test work? >>>> >>>> So far I tested with 3 different hub chips SMSC, GL (USB2.0) and one >>>> USB3.0 hub - no difference. >>> >>> In that case, try collecting two usbmon traces showing what happens >>> during the test. In one trace, connect the FT2232C directly to the >>> computer port; in the other, go through the GL hub. See >>> Documentation/usb/usbmon.txt for instructions. >> >> Will do. > > The proper script with cycles support '-n' > http://dl.dropbox.com/u/6486923/serialtest.py > raw text HCD: http://dl.dropbox.com/u/6486923/ftdi_sniff_hcd.out > tcpdump HCD: http://dl.dropbox.com/u/6486923/ftdi_sniff_hcd.pcap > > HCD sniffs show 2 cycles > > raw text HUB: http://dl.dropbox.com/u/6486923/ftdi_sniff_hub.out > tcpdump HUB: http://dl.dropbox.com/u/6486923/ftdi_sniff_hub.pcap > > HUB sniffs have different number of cycles regarding when the test failed. > > Let me know if you need more info or sniffs.
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 f1172400 1591709116 S Bi:1:004:3 -115 512 < f1172b00 1591709118 C Bi:1:004:1 0 2 = b100 f1172b00 1591709119 S Bi:1:004:1 -115 512 < f1172400 1591710111 C Bi:1:004:3 0 3 = b16073 f1172400 1591710116 S Bi:1:004:3 -115 512 < f1172b00 1591710118 C Bi:1:004:1 0 2 = b100 f1172b00 1591710119 S Bi:1:004:1 -115 512 < f1172400 1591711112 C Bi:1:004:3 0 3 = b16074 f1172400 1591711116 S Bi:1:004:3 -115 512 < f1172b00 1591711118 C Bi:1:004:1 0 2 = b100 f1172b00 1591711119 S Bi:1:004:1 -115 512 < f1172400 1591712113 C Bi:1:004:3 0 3 = b16020 f1172400 1591712117 S Bi:1:004:3 -115 512 < f1172b00 1591712119 C Bi:1:004:1 0 2 = b100 f1172b00 1591712120 S Bi:1:004:1 -115 512 < f1172400 1591713112 C Bi:1:004:3 0 3 = b16073 f1172400 1591713116 S Bi:1:004:3 -115 512 < f1172b00 1591713119 C Bi:1:004:1 0 2 = b100 f1172b00 1591713120 S Bi:1:004:1 -115 512 < f1172400 1591714112 C Bi:1:004:3 0 3 = b16074 f1172400 1591714117 S Bi:1:004:3 -115 512 < f1172b00 1591714119 C Bi:1:004:1 0 2 = b100 f1172b00 1591714120 S Bi:1:004:1 -115 512 < f1172400 1591715111 C Bi:1:004:3 0 3 = b16072 f1172400 1591715116 S Bi:1:004:3 -115 512 < f1172b00 1591715118 C Bi:1:004:1 0 2 = b100 f1172b00 1591715119 S Bi:1:004:1 -115 512 < f1172400 1591716115 C Bi:1:004:3 0 2 = b160 f1172400 1591716118 S Bi:1:004:3 -115 512 < f1172b00 1591716121 C Bi:1:004:1 0 2 = b160 f1172b00 1591716122 S Bi:1:004:1 -115 512 < f1172400 1591717111 C Bi:1:004:3 0 3 = b16069 f1172400 1591717116 S Bi:1:004:3 -115 512 < f1172b00 1591717118 C Bi:1:004:1 0 2 = b160 f1172b00 1591717119 S Bi:1:004:1 -115 512 < f1172400 1591718112 C Bi:1:004:3 0 3 = b1606e f1172400 1591718116 S Bi:1:004:3 -115 512 < f1172b00 1591718118 C Bi:1:004:1 0 2 = b160 f1172b00 1591718119 S Bi:1:004:1 -115 512 < f1172400 1591719112 C Bi:1:004:3 0 3 = b16067 f1172400 1591719116 S Bi:1:004:3 -115 512 < 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? Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
