> 	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.

OK, after some further research, I have it working.

The OX16PCI952 and OXmPCI952 appear to be very different chips (oh, thank
you, Oxford Semiconductor).  What's worse, the "preliminary data sheet"
for the OXmPCI952 does not appear to actually match the shipping part.
(Oh, THANK YOU, Oxford Semiconductor.)

The OXmPCI952 can offer either a standard parallel port or an 8-bit local
expansion data port on function 1; this board appears to configure it for
non-parallel port mode.

I booted Mandrake linux to see if it could talk to the board; it did not
recognize it, but I was able to use 'lspci' to dump out the configuration
block for the UART function of the chip:

Serial Controller: Oxford Semiconductor Ltd EXSYS EX-41092 Dual 16950 Serial
	Adapter (prog-if 06 [16950])
Subsystem: Siig Inc: Unknown device 2031
plus a whole bunch of infomration about the PCI configuration registers.

Now here's the interesting thing.  When it dumps out the PCI
Configuration Space area, the bytes corresponding to the BARs doesn't
match the documentation.  The chip data sheet says BAR 0 through BAR 5
will contain 0x00000001, 0x00000001, (unused), (unused), 0x00000001,
and 0x00000000 after a reset.  BAR 0 should access UART 0 via IO, BAR
1 should access UART 1 via IO, BAR 4 should access the local control
registers via IO, and BAR 5 should be a memory-mapped region
containing both UARTs and the local control registers.

However, the dump indicates that BAR 0 through BAR 5 contain (under linux)
0x0000dec1, 0xfeaf7000, 0x0000dea1, 0xfeaf6000, 0x00000000, 0x00000000;
and the dump claims four regions are allocated:
Region 0: I/O Ports at dec0 [size=32]
Region 1: Memory at feaf7000 (32-bit, non-prefetchable) [size=4k]
Region 2: I/O Ports at dea0 [size=32]
Region 3: Memory at feaf6000 (32-bit, non-prefetchable) [size=4k]

That configuration doesn't match the documentation for the OXmPCI952.
However, it's similar to (if not quite the same as) the default configuration
for the OXmPCI954 chip, which has 4 UARTs and a local-bus/parallel-port
interface.  So, I tried changing the entry for the board to use BAR 0
for both UARTs (offset 0x08 for the second UART), and now it works (or it
probes, anyway; I don't have a spare serial device to actually confirm
that it is working).  It also doesn't hang the boot process, so I suspect
that something went wacky when trying to address non-existent registers
via BAR 1.

Now to figure out how to add 16C950 mode so I can take advantage of those
huge FIFOs.  (And to figure out why my gigabit PHY now fails to probe if
the ethernet is plugged in, but that isn't the fault of the serial card...)