I have installed two 4-port serial cards (http://www.startech.com/ Product/ItemDetail.aspx?productid=PCI4S550&c=US) on a CentOS 4.4 system. The hardware appears to be recognized correctly, as kudzu added 2 entries to /etc/sysconfig/hwconf and lscpi shows both cards (output of lspci -vv for both cards included at the end of this email):
# lspci 00:00.0 Host bridge: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 945G/GZ/P/PL Express PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1) 02:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) 0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
However, only the 4 serial ports on one of the two cards are configured correctly:
# dmesg | fgrep ttyS ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS4 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS5 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS6 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS7 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS1 at I/O 0x5060 (irq = 193) is a 16450 ttyS2 at I/O 0x5068 (irq = 193) is a 16450 ttyS3 at I/O 0x5070 (irq = 193) is a 16450
I have no idea what ttyS1-3 are, but I've tested ttyS4-7 and they work fine. If I only install one card (in either PCI slot 1 or 2) I get the same 4 ports. If I install both cards, ttyS4-7 work on the card that is in PCI slot 2.
Any ideas how to get the 4 ports on the other card working?
Alfred
0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 5020 [size=32] Region 1: Memory at d2101000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5000 [size=32] Region 3: Memory at d2100000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0 +,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 B routed to IRQ 193 Region 0: I/O ports at 5060 [size=32] Region 1: Memory at d2103000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5040 [size=32] Region 3: Memory at d2102000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0 +,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 217 Region 0: I/O ports at 50a0 [size=32] Region 1: Memory at d2105000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5080 [size=32] Region 3: Memory at d2104000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0 +,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 B routed to IRQ 225 Region 0: I/O ports at 50e0 [size=32] Region 1: Memory at d2107000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 50c0 [size=32] Region 3: Memory at d2106000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0 +,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Alfred von Campe wrote:
I have installed two 4-port serial cards (http://www.startech.com/ Product/ItemDetail.aspx?productid=PCI4S550&c=US) on a CentOS 4.4 system. The hardware appears to be recognized correctly, as kudzu added 2 entries to /etc/sysconfig/hwconf and lscpi shows both cards (output of lspci -vv for both cards included at the end of this email):
# lspci 00:00.0 Host bridge: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 945G/GZ/P/PL Express PCI Express Root Port (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 TurboCache(TM)] (rev a1) 02:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) 0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
However, only the 4 serial ports on one of the two cards are configured correctly:
# dmesg | fgrep ttyS ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS4 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS5 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS6 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS7 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS1 at I/O 0x5060 (irq = 193) is a 16450 ttyS2 at I/O 0x5068 (irq = 193) is a 16450 ttyS3 at I/O 0x5070 (irq = 193) is a 16450
I have no idea what ttyS1-3 are, but I've tested ttyS4-7 and they work fine. If I only install one card (in either PCI slot 1 or 2) I get the same 4 ports. If I install both cards, ttyS4-7 work on the card that is in PCI slot 2.
Never used these cards, but the standard CentOS4 kernel has the following config settings:
CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_MANY_PORTS is not set
This might be your problem ...
James Pearson
On Mar 9, 2007, at 11:26, James Pearson wrote:
Never used these cards, but the standard CentOS4 kernel has the following config settings:
CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_MANY_PORTS is not set
This might be your problem ...
Hmm, this could definitely be it. I'll look into it further and report back. I'd rather not recompile the kernel, but if that is a way to get it to work, I'll certainly do it. Maybe the CentOS Plus kernel already has support for this enabled. I will check on that as well later today.
Alfred
Alfred von Campe wrote:
On Mar 9, 2007, at 11:26, James Pearson wrote:
Never used these cards, but the standard CentOS4 kernel has the following config settings:
CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_MANY_PORTS is not set
This might be your problem ...
Hmm, this could definitely be it. I'll look into it further and report back. I'd rather not recompile the kernel, but if that is a way to get it to work, I'll certainly do it. Maybe the CentOS Plus kernel already has support for this enabled. I will check on that as well later today.
this also explains why I could never get more than a couple ports working on a 8 port card I picked up to use as a unix server serial console controller.
and, yeah, if I can request CentOS Plus kernel consider supporting more serial ports, chalk me in!
On Mar 9, 2007, at 12:21, John R Pierce wrote:
this also explains why I could never get more than a couple ports working on a 8 port card I picked up to use as a unix server serial console controller.
Yup, and it also explains all the behavior I've seen.
and, yeah, if I can request CentOS Plus kernel consider supporting more serial ports, chalk me in!
Me too. I just checked, and it appears that the CentOS Plus kernel does not have the additional ports configured by default. So I bit the bullet and started to build my own kernel. I had the kernel- devel package installed for my current kernel. I did a "make xconfig" in /usr/src/kernels/2.6.9-42.0.10.EL-i686 (after doing a "yum install qt-devel") and changed two options under Device Drivers -
Character devices -> Serial drivers:
1. Changed "Maximum number of non-legacy 8259/16559 serial ports" from 4 to 12 2. Enabled "Support more than 4 legacy serial ports" under "Extend 8250/16550 serial driver options"
I saved the config, but when I do a make, I get the following error:
# make CHK include/linux/version.h SPLIT include/linux/autoconf.h -> include/config/* CHK include/asm-i386/asm_offsets.h HOSTCC scripts/genksyms/genksyms.o HOSTCC scripts/genksyms/lex.o HOSTCC scripts/genksyms/parse.o HOSTLD scripts/genksyms/genksyms CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTCC scripts/conmakehash make[1]: *** No rule to make target `init/main.o', needed by `init/ built-in.o'. Stop.
I even tried to re-install the kernel-devel RPM to no avail. Granted, I've never had to rebuild a CentOS kernel before, so maybe I'm missing some steps. But I thought all you needed to do was "make xconfig" (or "make menuconfig") followed by a make.
Alfred
James Pearson wrote:
Alfred von Campe wrote:
[snip]
0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) 0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
However, only the 4 serial ports on one of the two cards are configured correctly:
# dmesg | fgrep ttyS ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS4 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS5 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS6 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS7 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS1 at I/O 0x5060 (irq = 193) is a 16450 ttyS2 at I/O 0x5068 (irq = 193) is a 16450 ttyS3 at I/O 0x5070 (irq = 193) is a 16450
The OX16PCI954 chip from Oxford includes a PCI bridge (0a:0a.1 and 0a:0c.1 in your lspci list) that can be used to "glue" additional (non PCI-enabled) Quad-UARTs to the OX16CPI954.
The standard Linux serial driver always detects 4 phantom ports on this bridge; which explains why ttyS1-ttyS3 are detected as 16450 (Linux cannot detect what they are -- since they don't exist -- and defaults to 16450s).
When reconfiguring your kernel, you should take these 4 phantom ports (per card) into account (since they will consumed /dev/ttyS# device files). If you have two such cards, you should configure at lest 16 non-legacy ports.
Cheers -- Michael
On Mar 9, 2007, at 14:42, Michael D. Kralka wrote:
The OX16PCI954 chip from Oxford includes a PCI bridge (0a:0a.1 and 0a:0c.1 in your lspci list) that can be used to "glue" additional (non PCI-enabled) Quad-UARTs to the OX16CPI954.
The standard Linux serial driver always detects 4 phantom ports on this bridge; which explains why ttyS1-ttyS3 are detected as 16450 (Linux cannot detect what they are -- since they don't exist -- and defaults to 16450s).
When reconfiguring your kernel, you should take these 4 phantom ports (per card) into account (since they will consumed /dev/ttyS# device files). If you have two such cards, you should configure at lest 16 non-legacy ports.
This is very interesting. Thanks for posting that. I was wondering what those ports were and why there were only three. I think what's happening is that by default, only device nodes /dev/sttyS0-7 are created, and since there is one serial port on the motherboard (ttyS0), that only leaves room for 7 more: 3 phantom and 4 real (I'm just glad it's not the other way around).
Until I can get the kernel to rebuild (see my previous post), I can not test the theory that changing the kernel config file will make the other 4 ports available.
Alfred
On Fri, Mar 09, 2007 at 03:40:52PM -0500, Alfred von Campe enlightened us:
Until I can get the kernel to rebuild (see my previous post), I can not test the theory that changing the kernel config file will make the other 4 ports available.
Have you looked at http://wiki.centos.org/HowTos/Custom_Kernel?
Matt
On Mar 9, 2007, at 15:53, Matt Hyclak wrote:
Have you looked at http://wiki.centos.org/HowTos/Custom_Kernel?
Oops, no, but I will. Probably not until Monday, though. I have to leave work a little early today...
Alfred
On Mar 9, 2007, at 15:53, Matt Hyclak wrote:
Have you looked at http://wiki.centos.org/HowTos/Custom_Kernel?
OK, I've rebuilt the kernel according to the instructions on this page (I ran into some issues; see earlier post in another thread). I only changed two settings in the config file:
CONFIG_SERIAL_8250_MANY_PORTS=y [originally disabled] CONFIG_SERIAL_8250_NR_UARTS=20 [originally 4]
The good news is that the system now sees all eight serial ports (nine counting the one on the MB itself). But the naming convention for the serial ports leaves something to be desired:
# dmesg | fgrep tty ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS14 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS15 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS44 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS45 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS46 at I/O 0x5060 (irq = 193) is a 16450 ttyS47 at I/O 0x5068 (irq = 193) is a 16450 ttyS48 at I/O 0x5070 (irq = 193) is a 16450 ttyS49 at I/O 0x5078 (irq = 193) is a 16450 ttyS50 at I/O 0x50a0 (irq = 217) is a 16C950/954 ttyS51 at I/O 0x50a8 (irq = 217) is a 16C950/954 ttyS52 at I/O 0x50b0 (irq = 217) is a 16C950/954 ttyS53 at I/O 0x50b8 (irq = 217) is a 16C950/954 ttyS54 at I/O 0x50e0 (irq = 225) is a 16450 ttyS55 at I/O 0x50e8 (irq = 225) is a 16450 ttyS56 at I/O 0x50f0 (irq = 225) is a 16450 ttyS57 at I/O 0x50f8 (irq = 225) is a 16450
I haven't tested the ports yet, but it looks like they are now ttyS14, 15, 44, 45, 50, 51, 52, and 53.
Alfred
On 3/12/07, Alfred von Campe alfred@110.net wrote:
On Mar 9, 2007, at 15:53, Matt Hyclak wrote:
Have you looked at http://wiki.centos.org/HowTos/Custom_Kernel?
OK, I've rebuilt the kernel according to the instructions on this page (I ran into some issues; see earlier post in another thread). I only changed two settings in the config file:
CONFIG_SERIAL_8250_MANY_PORTS=y [originally disabled] CONFIG_SERIAL_8250_NR_UARTS=20 [originally 4]
As I understand it you can also set the kernel command line arg 8250.nr_uarts equal to some value like 8, 16, 32, etc, without having to rebuild your kernel (i.e. go into grub.conf and add to your kernel line " 8250.nr_uarts=32").
The good news is that the system now sees all eight serial ports (nine counting the one on the MB itself). But the naming convention for the serial ports leaves something to be desired:
# dmesg | fgrep tty ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS14 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS15 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS44 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS45 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS46 at I/O 0x5060 (irq = 193) is a 16450 ttyS47 at I/O 0x5068 (irq = 193) is a 16450 ttyS48 at I/O 0x5070 (irq = 193) is a 16450 ttyS49 at I/O 0x5078 (irq = 193) is a 16450 ttyS50 at I/O 0x50a0 (irq = 217) is a 16C950/954 ttyS51 at I/O 0x50a8 (irq = 217) is a 16C950/954 ttyS52 at I/O 0x50b0 (irq = 217) is a 16C950/954 ttyS53 at I/O 0x50b8 (irq = 217) is a 16C950/954 ttyS54 at I/O 0x50e0 (irq = 225) is a 16450 ttyS55 at I/O 0x50e8 (irq = 225) is a 16450 ttyS56 at I/O 0x50f0 (irq = 225) is a 16450 ttyS57 at I/O 0x50f8 (irq = 225) is a 16450
IIRC, what you have to do is create a udev rule so that you can cause your serial port naming to persist the way you want. I've never created one myself, but we have done that in my group where I work, so the problem is familiar to me.
Cheers...james
On Mar 12, 2007, at 13:15, James Olin Oden wrote:
As I understand it you can also set the kernel command line arg 8250.nr_uarts equal to some value like 8, 16, 32, etc, without having to rebuild your kernel (i.e. go into grub.conf and add to your kernel line " 8250.nr_uarts=32").
I tried this, but it didn't work. I probably also need the CONFIG_SERIAL_8250_MANY_PORTS option enabled, and that probably can't be set on the kernel command line.
IIRC, what you have to do is create a udev rule so that you can cause your serial port naming to persist the way you want. I've never created one myself, but we have done that in my group where I work, so the problem is familiar to me.
I wrote a udev rule once (it was for setting permissions on a device), so I am somewhat familiar with this. I'll see if I can write a rule that uses better names for the serial ports.
Alfred
On Fri, 9 Mar 2007, Alfred von Campe wrote:
I have installed two 4-port serial cards (http://www.startech.com/Product/ItemDetail.aspx?productid=PCI4S550&c=US) on a CentOS 4.4 system. The hardware appears to be recognized correctly, as kudzu added 2 entries to /etc/sysconfig/hwconf and lscpi shows both cards (output of lspci -vv for both cards included at the end of this email):
[....] 0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) 0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) 0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
However, only the 4 serial ports on one of the two cards are configured correctly:
# dmesg | fgrep ttyS ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS4 at I/O 0x5020 (irq = 177) is a 16C950/954 ttyS5 at I/O 0x5028 (irq = 177) is a 16C950/954 ttyS6 at I/O 0x5030 (irq = 177) is a 16C950/954 ttyS7 at I/O 0x5038 (irq = 177) is a 16C950/954 ttyS1 at I/O 0x5060 (irq = 193) is a 16450 ttyS2 at I/O 0x5068 (irq = 193) is a 16450 ttyS3 at I/O 0x5070 (irq = 193) is a 16450
I have no idea what ttyS1-3 are, but I've tested ttyS4-7 and they work fine. If I only install one card (in either PCI slot 1 or 2) I get the same 4 ports. If I install both cards, ttyS4-7 work on the card that is in PCI slot 2.
Any ideas how to get the 4 ports on the other card working?
I've got only one of these cards installed, and although it's less than a year old, it uses a completely different chipset than yours. Here's my dmesg:
$ dmesg | grep ttyS ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS4 at I/O 0xdf08 (irq = 209) is a 16550A ttyS5 at I/O 0xdf10 (irq = 209) is a 16550A ttyS6 at I/O 0xdf18 (irq = 209) is a 16550A ttyS7 at I/O 0xdf20 (irq = 209) is a 16550A ttyS1 at I/O 0xdf28 (irq = 209) is a 16450
I *think* the 16450 UART is there to generate interrupts and allow 16550-unaware software to work with the 16550s (or, in your case, the 16C950s) -- but corrections to my hypothesis are welcome!
Still, what leaps out at me in your verbose lspci listings (below) is that the card with PCI ID 0a:0a:[01] (IRQs 177/193) is showing up while card 0a:0c.[01] (IRQs 217/225) isn't showing up at all.
I don't understand why each card is getting two IRQs, but I'd expect to see something like
ttySX at I/O 0xXXXX (irq = 217) is a 16C950/954
show up in your dmesg. Instead, all the ttySX listings from your dmesg have IRQs from only one of the cards.
Have you verified that each card works properly if installed by itself, without the other?
0a:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 5020 [size=32] Region 1: Memory at d2101000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5000 [size=32] Region 3: Memory at d2100000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0a.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 B routed to IRQ 193 Region 0: I/O ports at 5060 [size=32] Region 1: Memory at d2103000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5040 [size=32] Region 3: Memory at d2102000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0c.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06 [16950]) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 217 Region 0: I/O ports at 50a0 [size=32] Region 1: Memory at d2105000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 5080 [size=32] Region 3: Memory at d2104000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0a:0c.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus) Subsystem: Oxford Semiconductor Ltd: Unknown device 0000 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 B routed to IRQ 225 Region 0: I/O ports at 50e0 [size=32] Region 1: Memory at d2107000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 50c0 [size=32] Region 3: Memory at d2106000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
On Mar 9, 2007, at 11:41, Paul Heinlein wrote:
Still, what leaps out at me in your verbose lspci listings (below) is that the card with PCI ID 0a:0a:[01] (IRQs 177/193) is showing up while card 0a:0c.[01] (IRQs 217/225) isn't showing up at all.
I don't understand why each card is getting two IRQs, but I'd expect to see something like
ttySX at I/O 0xXXXX (irq = 217) is a 16C950/954
show up in your dmesg. Instead, all the ttySX listings from your dmesg have IRQs from only one of the cards.
Yes, that is the problem. In another reply, someone mentioned a kernel configuration option that may be limiting the number of serial ports, which I'll be looking into.
Have you verified that each card works properly if installed by itself, without the other?
Yes, they both work fine in either PCI slot.
Alfred
-
Alfred von Campe -
James Olin Oden -
James Pearson -
John R Pierce -
Matt Hyclak -
Michael D. Kralka -
Paul Heinlein