On Tue, 8 Feb 2011, Arvid Brodin wrote: > >> With the EHCI host controller: > >> ============================= > >> > >> [Terminal 1] > >> $ cat /dev/ttyUSB1 > >> > >> [Terminal 2] > >> $ echo "Something seems wrong here" > /dev/ttyUSB0 > >> $ echo "Something seems wrong here" > /dev/ttyUSB0 > >> > >> [Terminal 1] > >> Something seems wrong here > >> > >> Something seems wrong here > >> > >> ^C > >> $ > >> > >> Observe the extra new line after the strings. I'm not sure if this is a > >> bug in the ftdi driver, some other part of the serial subsystem, or if > >> it is the result of some terminal setting; with a USB analyzer I observe > >> the following sequence of packets (#-# == device-endpoint): > >> > >> 3-2 OUT: "Something seems wrong here" > >> 3-2 OUT: 0x0D 0x0A > >> 4-1 IN: 0x01 0x60 'S' > >> 4-1 IN: 0x01 0x60 'o' > >> ... > >> 4-1 IN: 0x01 0x60 0x0D > >> 4-1 IN: 0x01 0x60 0x0A > >> 4-2 OUT: 'S' # The echo from the reading side starts here > >> 4-2 OUT: 'o' > >> ... > >> 4-2 OUT: 0x0D 0x0A > >> 4-2 OUT: 0x0D 0x0A # The newline pair is echoed twice - perhaps both > >> 'CR' and 'NL' are converted to "CRNL" in the echo? > > > > Not exactly -- CR is changed to NL upon input. That's what "icrnl" > > means in your stty output. > > Ok... so this is a bug then? The echo should really be 2x0A instead of > 2x0D0A? No, it's not a bug. The echo should be 0x0D 0x0A 0x0D 0x0A, which is what it is. Upon output, each NL is converted to CR NL; that's what "onlcr" means in the stty output. > Ok, I made another run, this time saving the usbmon output as well: > > [Terminal 1] > # cat /dev/ttyUSB1 > > [Terminal 2] > # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0 > # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0 > # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0 > # > > [Terminal 1] > This is isp1761 and something is wrong > > 761 and something is wrong > > > > > > > > 7This is isp1761 and something is wrong > > 61 and soThis is isp1761 and something is wrong > > > > > > > > 7This is isp1761 and something is T > ^C > # > > The usbmon dump shows this (ttyUSB0 is dev 4, ttyUSB1 is dev 5; endpoint > 1 is the input stream and endpoint 2 is the output stream for each > serial port): > > 1) The string is output on ttyUSB0: > 93a7b100 426649297 S Bo:1:004:2 -115 38 = 54686973 20697320 69737031 etc... > 93a7b100 426652018 S Bo:1:004:2 -115 1 = 0d > 93a7b100 426652343 C Bo:1:004:2 0 1 > > 93a7b100 426652576 S Bo:1:004:2 -115 1 = 0a > (lots of NAKs on the bus here, and no callback just yet) > > 2) The string is received by 5-1 in three bulk IN transfers and echoed > one char at a time on 5-2. The CRNL pair is doubled. > > 3) Then, just after the setup packets to 4-0 for the next 'echo', > something interesting happens: > 93971d00 427486550 S Bi:1:004:1 -115 512 < > 93971d00 427487171 C Bi:1:004:1 0 32 = 01603736 3120616e 6420736f > 6d657468 696e6720 69732077 726f6e67 0d0a0d0a > > Note that this is the "761 and something is wrong" and multiple CRNL > from the 'cat' above. This is then echoed from 4-2 and again every CRNL > pair gets doubled to CRNLCRNL. So your loopback setup is causing the echo from the second port to be re-echoed by the first port. Maybe it would help if you disabled echoing on the first port: stty -F /dev/ttyUSB0 -echo. As far as I can see, the only question is why you did get the echoing under one kernel and didn't get it under the other. 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
