John F. Woods wrote at 28 Dec 2004 00:25:41 -0500,

>I have a SIIG CyberPro PCI 2S (or "Dual 950 PCI", depending on which
>piece of marketing literature you read) card which is based on the
>OXmPCI952 chip from Oxford Semiconductor.  Unfortunately, SIIG either is
>using an early rev of the chip, or they are misprogramming the subtype,
>because it probes as 0x1415/0x950A (function 0) and 0x1415/0x9510
>(function 1), and thus is treated as an unknown card (function 0 does
>show up as a "communications" function, however).  Worse, when I simply
>added 0x950A to pucdata.c as a copy of the OXmPCI952 specification already
>in the file), it doesn't quite work:  com3 probes as a 16550 compatible,
>com4 probes as "ns8250 or ns16450, no fifo", and then the kernel hangs
>at "root file system type: ffs".  (Removing the card removes the hang, so
>it's probably not something unrelated that I biffed in my configuration.)
>
>So, my questions would be:  does anyone else have this card, and is it
>working for you?  (i.e. is my card just broken somehow?)  If there are
>other changes I should have made in addition to just adding an entry to
>pucdata.c, what should I have done?  Also, is there anything that needs
>to be done to enable 16650 compatability?  I see that com.c has an #ifdef
>COM16650, which would lead me to suspect that it's not normally supported.
>
>Also, is there a limit on the size of the dmesg buffer on the i386 port?
>(Since it looks like debugging is going to entail resetting after the
>hang and booting another kernel, which means I'll have to capture two
>boots' worth of message buffer...  I've got it cranked up to 32768, which
>seems to be working, but I'll need at least twice that...)
>

	I don't have that card, but I do have another card with an
Oxford OX16PCI952.  The second function is the parallel port, NOT the
second serial port.  And, yes the recognition is definitely flaky - I
see one or the other port report no FIFO about 10% of the time the machine
with it boots (only once of twice a month).  From that machine's most recent
dmesglog:

puc1 at pci0 dev 11 function 0: Oxford Semiconductor OX16PCI952 UARTs (com, com)
com10 at puc1 port 0: interrupting at irq 10
com10: st16650a, working fifo
com11 at puc1 port 1: interrupting at irq 10
com11: st16650a, working fifo
puc2 at pci0 dev 11 function 1: Oxford Semiconductor OX16PCI952 Parallel port (lpt)
atppc1 at puc2 port 0: AT Parallel Port
atppc1: interrupting at irq 10
atppc1: FIFO <depth,wthr,rthr>=<16,8,8>
atppc1: capabilities=3d<INTR,FIFO,PS2,ECP,EPP>
ppbus1 at atppc1
ppbus1: IEEE1284 negotiation: modes NIBBLE/ECP
ppbus1: IEEE1284 device found.
ppbus1: Probing for PnP devices.
ppbus1: <Hewlett-Packard HP LaserJet 6MP> PJL,MLC,PCLXL,PCL,POSTSCRIPT
lpt1 at ppbus1: port mode = 1<COMPATIBLE>

	As you can tell, this kernel is built with "options COM_16650",
which *definitely* seems to help (though there is no apparent reason why).
Also, the "atppc" driver is *very* different than the one in the tree (but
you didn't mention any parallel port problems). I use the serial ports on
the chip nearly every day (the devices plugged in them are `touched' by cron
jobs) but one port is running at only 4800 baud and the other at 57600.  I
also have code for ""options COM_16850" and "options COM_16950", which I'm
not using now (besides, the code is blatantly stolen from the Linux driver
and thus is GPL'd) because it had no performance gain and seemed to make
some of the '650s and '850s in that machine occasionally report the "no fifo"
message (and the real '650s didn't work when misrecognize-d - They're on an
old SIIG PS8000 card).  Also, since the parallel port shares the same interrupt
line as the serial ports, if it is recognized as an "lpt" or the normal "atppc",
you WILL hang at the first interrupt (one of the reasons I changed the atppc
driver).

	I suspect there are subtle timing issues with initializing the `950s
(and `850s also) - warm boots sometime show the problem, cold boots never do
(at least for me).  However, the card does works (even when the error "no fifo"
appears) just fine.

	You might want to look at the current Linux code for hints (I last
examined it almost two years ago);  Also, I think there might be some FreeBSD
code for the '[789]50 chips also.

	Finally, you might want to consider whether it is a PCI version
incompatibility - Most new machines are PCI 2.2, and the Oxford was either
PCI 2.0 or even 1.1 (very few things broke with the 2.1 changes, but more
broke with the 2.2 changes, and I haven't sat on any of the committees
since PCI 1.0):  The machine I have it in is PCI 2.1.

	Good luck,

	Paul Shupak
	track@plectere.com

P.S.  There is no apparent limit to the dmesg buffer size; On that machine I
have:
options MSGBUFSIZE="(16*NBPG)"  # 16 pages of messages - Lots of autoconf noise