Re: PCI serial card almost works

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Dec 24, 2008 at 09:33:14PM -0800, James Birdsall wrote:
> I needed some serial ports, so checked the list of supported PCI serial 
> cards and bought a SIIG CyberSerial 4S. It almost works. The kernel 
> finds it on startup and the devices are configured. Kermit can tell when 
> the port is and isn't connected to another device. However, no 
> characters are sent or received. Here's the dmesg for this card, and 
> even though it's sold by SIIG as a Cyber 4S, it isn't recognized as such:
> 
> puc1 at pci1 dev 4 function 0: Oxford Semiconductor OX16PCI954 UARTs 
> (com, com,com, com)
> com6 at puc1 port 0: interrupting at ivec 18
> com6: ns16550a, working fifo
> com7 at puc1 port 1: interrupting at ivec 18
> com7: ns16550a, working fifo
> com8 at puc1 port 2: interrupting at ivec 18
> com8: ns16550a, working fifo
> com9 at puc1 port 3: interrupting at ivec 18
> com9: ns16550a, working fifo
> Oxford Semiconductor product 0x9510 (miscellaneous bridge) at pci1 dev 4 
> function 1 not configured
> 
> My old SIIG Quartet, which is not on the supported list and was not sold 
> under the "Cyber 4S" name, is recognized as a "Cyber 4S" and does work:
> 
> puc0 at pci1 dev 3 function 0: SIIG Cyber 4S PCI 16C550 (20x family) 
> (com, com,com, com)
> com2 at puc0 port 0: interrupting at ivec 14
> com2: ns16550a, working fifo
> com3 at puc0 port 1: interrupting at ivec 14
> com3: ns16550a, working fifo
> com4 at puc0 port 2: interrupting at ivec 14
> com4: ns16550a, working fifo
> com5 at puc0 port 3: interrupting at ivec 14
> com5: ns16550a, working fifo
> 
> I keep thinking that it's some kind of flow-control issue, but I was 
> using the same device and the same cable for testing. Put it on a 
> Quartet port and it works. Put it on the other card and it didn't. 
> Turning off flow control in Kermit didn't help. Is there anything I can 
> do or is this card just SOL?

It could be a speed issue. These chips may be used with different crystals,
making it hard to know the scaling factor for software.
This can be worked around in useland by ajusting the serial port speed
to accout to the difference in crystals frequencies. For example, on a
similar PUC device (it's also identified as OX16PCI954 but it's acually
a 8-port serial adapter, with 2 OX16PCI954 in the same chip), I have to use
1200 to connect at 9600bps. Once you determine the correct factor you can
change pucdata.c (e.g. in my case I use COM_FREQ * 8 instead of COM_FREQ for
the OX16PCI954).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--