|Summary:||Kernel 2.4.18-27.7 correctly autoconfigures SIIG 4-port RS-232 PCI SuperSerial card (PCI Class 0700: 131f:2052) with 4 16850 UARTS, but card only operates if setserial uart 16550 used; same card worked fine with kernel 7.0 (2.2.16-22).|
|Product:||[Retired] Red Hat Linux||Reporter:||Jason Vas Dias <jvasdias>|
|Component:||kernel||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-09-30 15:40:49 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jason Vas Dias 2003-04-18 23:46:25 UTC
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 \ skip_test spd_normal ... /dev/ttyS5 uart 16850 port 0xfc88 irq 11 baud_base 115200 \ skip_test spd_normal 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 /usr/share/doc/setserial*/rc.serial (/etc/rc.d/init.d/serial) 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 \ skip_test spd_normal ... 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): 2.4.18-27.7 How reproducible: 100% 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 Actual results: NO DATA TRANSFER OCCURS. Expected results: Data transfer with round-trip time < 18ms, mdev < 0.01ms Additional info: 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.
Comment 1 Jason Vas Dias 2003-04-19 01:03:34 UTC
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.
Comment 2 Bugzilla owner 2004-09-30 15:40:49 UTC
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 persists. 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/