0

I've got this 2 port PCI serial card installed in an older Linux machine (it's offline, so updates are few and far between). The documentation for the card says that the installed kernel version on the machine is supported, and I can see that the card is working when I connect one port to the other.

The problem comes when I try to read a data stream coming from a serial network interface server (a Perle IOLAN to be specific). All I get is 0x80 and 0x00 coming out instead of ASCII text. I've verified that the major settings are the same (baud rate, 8 bits/char, 1 stop bit, no parity, no flow control) between the two ends, and have tried various baud rates as well. The same thing happens when I connect a Windows machine to it in order to test (the Windows machine reads from the IOLAN just fine as well).

The previous serial card (I think it's this one, but if not, it's something close) works fine, but it also has a different UART in it (a 16550 vs. a 16950 in this new card).

Here is the output I'm getting for one of the ports from stty:

speed 115200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit =  ; erase = <undef>; kill = s; eof = <undef>; eol = a;
eol2 = <undef>; swtch = r; start = ^Q; stop = ^S; susp = <undef>;
rprnt = <undef>; werase = <undef>; lnext =  ; flush = l; min = 0; time = 1;
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

and from setserial:

/dev/ttyS2, Line 2, UART: 16950/954, Port: 0x1078, IRQ: 74
    Baud_base: 115200, close_delay: 50, divisor: 0
    closing_wait: 3000
    Flags: spd_normal skip_test auto_irq

I can tell that my major settings are correct, and comparing against another Linux machine that's working, I don't see anything too out of place. So why can't this card talk to other machines like it should?

EDIT: As per @sawdust, my kernel version is 2.6.18, according to uname:

Linux serverName 2.6.18-92.el5 #1 SMP Tue Jun 10 18:49:47 EDT 2008 i686 i686 i386 GNU/Linux

The card also looks to be recognized on boot, although perhaps not entirely properly:

serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
0000:00:03.3: ttyS1 at I/O 0x4470 (irq = 177) is a 16550A
ttyS2: detected caps 00000700 should be 00000100
0000:07:00.0: ttyS2 at I/O 0x1078 (irq = 74) is a 16C950/954
ttyS3: detected caps 00000700 should be 00000100
0000:07:00.0: ttyS3 at I/O 0x1070 (irq = 74) is a 16C950/954
ttyS2: detected caps 00000700 should be 00000100

(ttyS0 and ttyS1 have headers on the motherboard, but no physical DB-9 port.)

/proc/tty/dirvers/ contains a single file, named serial.

Improve this question
13
  • Possible reasons I can think of: bad hardware (i.e. bad connection somewhere), driver screwup, missing level conversion (esp. newer cards often use 5V or even 3.3V TTL levels even on RS-232, as opposed to the original 12V).
    – dirkt
    Dec 9, 2016 at 15:11
  • I don't think it's a bad connection, since I'm using the same cable to connect the card to itself as I am to connect the card to the Windows machine. The fact that it can talk to itself also seems to indicate that the driver is probably fine. As for the voltage, that is possible, although that would really only explain not being able to write; I should still be able to read if the voltage for the card is too low.
    – MBraedley
    Dec 9, 2016 at 15:16
  • I didn't mean bad connection in the cable, but on the board: bad solderpoint etc. If it can talk to itself, the driver may be used differently compared to if just one channel is used. I'm not claiming one of these is actually the reason, but these are possible reasons I'd check for as far as practical: Inspect the card visually close up, wiggle connections and see if the problem persists, measure voltages etc. The point is that there's lots of possible reasons, and you have to start narrowing it down somehow. Nobody will be able to give the exact reason from the information in your question.
    – dirkt
    Dec 9, 2016 at 17:20
  • Nothing you've just said makes a lot of sense, other than to measure the voltages. It's safe to assume that the card is physically fine, since it can talk to itself. It's safe to assume that the driver doesn't work differently when both ports are in use because why would it? If you're going to make out there suggestions, you've got to back them up.
    – MBraedley
    Dec 9, 2016 at 17:49
  • 1
    Took a quick look at Linux kernel 4.4 drivers, and there is support for StarTech boards and Oxford Semi UARTs in 8250_port.c. There's also a disturbing comment about a workaround for a version of Oxford UART that miscalculates the baudrate. An inaccurate baudrate on your board would produce the exact symptom you see: the two ports can work together, but not with other ports. Try connecting an oscilloscope, and measure the actual bitrate on the wire.
    – sawdust
    Dec 12, 2016 at 23:30

1 Answer 1

Reset to default
1

The signal clock for this card is running 8 times faster than it should. This means if you expect a baud rate of 9600, you can set the card to 1200 and have it function properly. Unfortunately, for some higher baud rates, this might not be an option. The best solution is probably to forget about this card and buy something that works.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .