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,
> 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.
Which driver are you using ?
> 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.
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
>>Hello,
>
>> 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.
>Which driver are you using ?
See attached CONFIG_SERIAL* from my config, this is the 'standard'
serial port driver.
>
>> 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.
>
>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
==============================================================
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_MULTIPORT=y
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
On Sun, Jun 01, 2003 at 02:48:14PM +0200, Paul Rolland wrote:
> 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.
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,
> 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.
>
>From 8250_pci.c, you have :
/*
* 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
On Mon, Jun 02, 2003 at 08:43:24PM +0200, Paul Rolland wrote:
> Hello,
>
>
> > 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.
> >
> >From 8250_pci.c, you have :
>
> /*
> * 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
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>