Serial port numbering (ttyS..) wrong for 2.5.61+

Since I tried the 2.5 kernel versions somewhere in the 2.5.6x range, I see rather odd port naming for the extra 4 serial ports on a PCI-card.

The first two are numered as ttyS14, ttyS15 while the last two are ttyS2 and ttyS3 !
I tried to find where these numbers are coming from but couldn't really find an obvious place in the various drivers/char/* or drivers/serial/* files.

Note that the ttyS14 port actually works so this seems only a bug in the numbering.

Regards,
Ruud Linders

Kernel version 2.5.70
---------------------
dmesg:
======
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS14 at I/O 0xbc00 (irq = 21) is a 16550A <<<<<< 14 ????
ttyS15 at I/O 0xbc08 (irq = 21) is a 16550A <<<<<<
ttyS2 at I/O 0xbc10 (irq = 21) is a 16550A
ttyS3 at I/O 0xbc18 (irq = 21) is a 16550A

4-port PCI serial controller:
=============================

# lspci -d 10b5:1077 -v
02:0b.0 Serial controller: PLX Technology, Inc. VScom 400 4 port serial adaptor
(rev 02) (prog-if 00 [8250])
        Subsystem: PLX Technology, Inc. VScom 400 4 port serial adaptor
        Flags: medium devsel, IRQ 21
        Memory at de004000 (32-bit, non-prefetchable) [size=128]
        I/O ports at b800 [size=128]
        I/O ports at bc00 [size=32]
        I/O ports at c000 [size=8]
        Expansion ROM at <unassigned> [disabled] [size=2K]

Hello,

Which driver are you using ?

Numbering seems to be coming out of drivers/serial/core.c : uart_find_match_or_unused which is responsible for finding an unused state for the port.

However, the code there seems to be clean and I guess we should look where the state are initialized.

Paul

When we add a port to the system, we try to find in order:

- a port which matches the base address
- a port which is unallocated

Probably the easiest way to stop the "ttyS14" occuring would be to clear the port information at boot when we don't find a port.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Hello,

/*
* Probe one serial board. Unfortunately, there is no rhyme nor reason
* to the arrangement of serial ports on a PCI card.
*/

It seems that your board is reporting the parameters in such an order that when looking for a port based on the IRQ, I/O port, ... the matching one has id 14...

You could see this more clearly by setting SERIAL_DEBUG_PCI
at line 1549 to activate the code :
#ifdef SERIAL_DEBUG_PCI
printk("Setup PCI port: port %x, irq %d, type %d\n",
serial_req.port, serial_req.irq, serial_req.io_type);
#endif

that would report to you the order in which ports are found on your system.

Regards,
Paul

Paul,

Setting SERIAL_DEBUG_PCI gives me this:

Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Setup PCI port: port bc00, irq 21, type 0
ttyS14 at I/O 0xbc00 (irq = 21) is a 16550A
Setup PCI port: port bc08, irq 21, type 0
ttyS15 at I/O 0xbc08 (irq = 21) is a 16550A
Setup PCI port: port bc10, irq 21, type 0
ttyS2 at I/O 0xbc10 (irq = 21) is a 16550A
Setup PCI port: port bc18, irq 21, type 0
ttyS3 at I/O 0xbc18 (irq = 21) is a 16550A

Doesn't give us much more detail.

BTW, this is the entry in 8250_pci.c for the board in question:

        {       PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_1077,
                PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
                pbn_b2_4_921600 },

Note that the ttyS's _are_ numbered in sequence in 2.4.20