Alan Stern wrote:
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.
Ok... so this is a bug then? The echo should really be 2x0A instead of
2x0D0A?
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.
Ok. I'll find a way to try this with 2.6.35 instead then.
=============================
[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.
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.
The whole usbmon log can be found at http://pastebin.com/m4LqnGaL (30
day limit).
I'll try this with 2.6.35 as well and report back to the list. But it'll
take a day or two, I think.
--
Arvid Brodin
Enea Services Stockholm AB
--
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
