On Tue, 8 Feb 2011, Arvid Brodin wrote: > Hi! > > I get weird problems when I use a null modem cable between the two ports > on a FT232BM (2-port FTDI USB-to-serial converter) with an isp1761 host > controller. The same thing does not happen with an EHCI host controller. > Lengthy details follows: Can't help much about isp1761, but EHCI is simple enough... > 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. > Anyway, since 3-1 is never read, no feedback loop is created by the two > echoing devices. > > > With the isp1761 host controller, driver from 2.6.35.7 backported to > 2.6.27.54 and modified for platform endianness: Maybe the backporting and modifications introduced some differences. Or maybe there are signficant differences in the TTY layer between 2.6.35 and 2.6.27. > ============================= > > [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 > # 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 > > This is isp1761 and something is wrong > > This is isp1761 and something is wrong > > This is isp1761 and something is wrong > > This is isp1761 and something is wrong > > and something is wrong > (blank line x7) > This is isp1761 and something is wrong > > ^C > # echo "This is isp1761 and something is wrong" > /dev/ttyUSB0 > # cat /dev/ttyUSB1 > is wrong > (blank line x30 ca) > TThis is isp1761 and something is wrong > > ^C > # > > The exact look of the error differs, but it is quite easy to trigger by > echoing text several times in a row; also breaking the "cat" execution, > echoing some more text, and then starting cat again seems to trigger the > error often. > > On the bus the traffic looks something like this: > > 7-2 OUT: "This is isp1761 and something is wrong" > 7-2 OUT: 0x0D > 7-2 OUT: 0x0A (NAK) # The CRNL pair is split here and the NL is not > directly accepted by the device > 7-2 OUT: 0x0A (NAK) > Following this is lots and lots of "0x0A NAKs" intermixed with traffic > that looks quite like the EHCI case except that much of the traffic has > to be re-sent lots of times before it is accepted. The 0x0A is finally > accepted after all text has been received by 8-1 and echoed from 8-2. > This exact pattern is repeated every time text is written to the serial > port. It might help a lot if you watch the kernel's view of the traffic using usbmon (Documentation/usb/usbmon.txt) as well as the bus-level view. 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
