Description of problem:
My company requires multiple RS-232 ports to connect devices using SLIP at
115200bps with very low latency and low transmission time variability, and has
been testing the SIIG `Quartet Serial 850 PCI' cards, (PCI Class 0700, Subs
131f:2052 ) which have 4 16850 UARTs with 128 byte FIFOs.
With Linux 7.0, kernel 2.2.16-22, on DELL 1400SC and 1600SC systems, we got
very good performance results with manual configuration of /etc/serial.conf, eg.
/dev/ttyS2 uart 16850 port 0xfcb8 irq 11 baud_base 115200 \
/dev/ttyS5 uart 16850 port 0xfc88 irq 11 baud_base 115200 \
We typically got a round trip ping time for a 256 byte packet of @15ms, with
< 0.01ms variation (mdev).
The Linux 7.0 kernel did not autoconfigure the card,
so we had to use the setserial commands above at boot via
to configure them.
Now due to customer requirements, we must upgrade our server product
to running under Linux 7.3 - we are using kernel 2.4.18-27.7.x , the latest
available from RedHat at time of writing - all packages have been upgraded
as of 04/18/03 and `RedHat Update Agent' reports no packages to upgrade.
Now the Linux 7.3 kernel is autoconfiguring the card,
and at boot-up the /proc/tty/driver/serial file says:
2: uart:XR16850 port:FCB8 irq::11 ...
3: uart:XR16850 port:FCA8 irq::11 ...
4: uart:XR16850 port:FC98 irq::11 ...
5: uart:XR16850 port:FC88 irq::11 ...
We were pleased that the kernel seemed to autoconfigure them
at first, but testing soon revealed that in this configuration
no port can pass more than 160 byte SLIP packets; with a normal
ping of 56(84) bytes, the round-trip time was 16.9ms and did
not deviate by more than 0.185ms (we were getting less than 0.01ms
deviation with Linux 7.0). Then when we pinged with 120(148) byte
packets the round trip time went up to 27.9 ms; when we pinged
with 132(160) byte packets, the round-trip time skyrocketed
to 230ms, deviation 0.8ms, but when we pinged with 133(161) bytes,
NO DATA WAS TRANSFERRED AT ALL !!! We put logic analyzers
on the output pins and saw that the outgoing packets were truncated
to 160 bytes.
So we tried using the same setserial commands as used in Linux 7.0,
and this time no data of any size was transferred.
We finally found the only one serial.conf configuration which worked:
/dev/ttyS2 uart 16550 port 0xfcb8 irq 11 baud_base 921600 \
So we have to operate the 16850's as 16550's under linux 7.3,
which makes paying extra for 16850's rather pointless, and we'd
really like to get back to the performance we experienced with 7.0.
Does anyone know of any serial.c patches / issues that might cause
this problem ?
My next step is to try hacking into serial.c to try to get it to work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Let kernel 2.4.18-27.7 (kudzu-0.99.52-1) configure the SIIG PCI card
(0700 131f:2052) with 4 16850 uarts
2. Connect SLIP devices:
slattach -p slip /dev/ttyS2 -s 115200 -L &
ifconfig sl0 172.16.23.200 pointopoint 172.16.23.201 up
3. Ping SLIP device with > 160 bytes:
ping -n 172.16.23.201 -s 133
NO DATA TRANSFER OCCURS.
Data transfer with round-trip time < 18ms, mdev < 0.01ms
Worked fine with Linux 7.0 (kernel 2.2.16-22), with manual configuration.
Now we can't manually configure the ports as 16850's - only 16550s will
work, and performance is lost.
I've now reproduced this problem with 2 boards, which both have the
same PCI ID: Class 0700 131f:2052 :
1. The older SIIG board, the `SuperSerial PCI 850' which actually has
4 real XR16C850's on it,
2 on-board DB9 connectors, and 2 extended DB9 connectors
( SIIG model #IO1866, SN #J6P010000400 )
2. The replacement board, the `Quartet Serial 850 PCI', which has
1 on-board DB-25 connector and a 4-DB9 octopus (quadrapus? :-)
cable that connects to it.
( SIIG model #IO873 SN #J6N020001839 )
Linux reports both boards as being the `Siig Inc CyberSerial (4-port) 16850'
Neither board can transfer packets larger than 160 bytes through a port on
Linux 7.3 when the ports are configured as 16850's, but can when configured
as 16550's; on Linux 7.0, both boards transfer large packets (eg 1500 bytes)
with better performance than on Linux 7.3.
Linux actually put the ports on TTY lines ttyS4, ttyS5, ttyS6 and ttyS7 above.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/