Bug 89168

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: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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/