This double serial port card is installed into a Debian GNU/Linux box (kernel 2.6.17), along with the integrated serial port (ttyS0). This is the lspci output:
# lspci -vv -s 01:08
01:08.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) (prog-if 02 [16550])
Subsystem: Timedia Technology Co Ltd Unknown device 4037
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 177
Region 0: I/O ports at a800 [size=32]
The I/O port for the second serial interface is equal to base I/O + 8. Not tested, but it can be useful to activate the following kernel option: CONFIG_SERIAL_8250_SHARE_IRQ=y, this is because the two serial ports share the same IRQ line.
Someone had problems with this serial controller due the base baud rate. Normally this value is 115200, but with this serial controller it is 921600. If autodetect does not work, it is advisable to manually set this value:
setserial /dev/ttyS1 irq 177 port 0xa800 baud_base 921600 uart 16550A skip_test setserial /dev/ttyS2 irq 177 port 0xa808 baud_base 921600 uart 16550A skip_test
In a Debian box the setserial configuration is eventually stored into /var/lib/setserial/autoserial.conf (see dpkg-reconfigure setserial).
# cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:16550A port:000003F8 irq:4 tx:0 rx:1108 fe:90 brk:989 1: uart:16550A port:0000A800 irq:177 tx:630 rx:4668 2: uart:16550A port:0000A808 irq:177 tx:0 rx:0 3: uart:unknown port:000002E8 irq:3
Here's a problem with the old redirection operator (which doesn't happen if you use the newer -F option instead). Sometimes when trying to use stty, the command hangs and nothing happens (you don't get a prompt for a next command even after hitting <return>). This is likely due to the port being stuck because it's waiting for one of the modem control lines to be asserted. For example, unless you've set “clocal” to ignore modem control lines, then if no CD signal is asserted the port will not open and stty will not work for it (unless you use the newer -F option). A similar situation seems to exist for hardware flow control. If the cable for the port doesn't even have a conductor for the pin that needs to be asserted then there is no easy way to stop the hang.
stty --file=/dev/ttyS4 clocal 9600 stty --file=/dev/ttyS5 clocal 9600
In Ubuntu see this bug 490194: modemmanger is too aggressive with serial devices, it runs after /etc/rc.local, so the best bet is:
dpkg --purge modemmanager