Some time ago I reported that serial ports numbering on 2.5.x/2.6.x
was rather weird when used with a 4-serial port PCI card and 2
standard onboard serial ports.
I got devices ttyS0/1/14/15/2/3 or something.
Now checking this on 2.6.5 it got more confusing, I now have with
total of 6 serial ports a device number ttyS45 !?
The way this device numbering seems to work is that many device names
are reserved in include/asm/serial.h for devices like fourport/boca/hub6.
Anything else (=all PCI cards?) gets a number still unassigned.
Note that eg. the SCSI disk equivalent of this strategy would be to
reserver eg. sda-sde for IBM disks and other brands start
numbering at sdf !
Attached patch 'fixes' this for me, been using it for past
6 months or so.
Regards,
Ruud Linders
__
Dmesg from 2.6.5
================
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, 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 0xb800 (irq = 21) is a 16550A
ttyS15 at I/O 0xb808 (irq = 21) is a 16550A
ttyS44 at I/O 0xb810 (irq = 21) is a 16550A
ttyS45 at I/O 0xb818 (irq = 21) is a 16550A
Applied this patch on stock 2.6.5
=================================
--- serial_core.c.ORIG 2004-03-19 18:29:20.000000000 +0100
+++ serial_core.c 2004-04-05 12:32:33.000000000 +0200
@@ -2306,17 +2306,6 @@
return &drv->state[i];
/*
- * We didn't find a matching entry, so look for the first
- * free entry. We look for one which hasn't been previously
- * used (indicated by zero iobase).
- */
- for (i = 0; i < drv->nr; i++)
- if (drv->state[i].port->type == PORT_UNKNOWN &&
- drv->state[i].port->iobase == 0 &&
- drv->state[i].count == 0)
- return &drv->state[i];
-
- /*
* That also failed. Last resort is to find any currently
* entry which doesn't have a real port associated with it.
*/
And now I get this more logical numbering
=========================================
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS2 at I/O 0xb800 (irq = 21) is a 16550A
ttyS3 at I/O 0xb808 (irq = 21) is a 16550A
ttyS4 at I/O 0xb810 (irq = 21) is a 16550A
ttyS5 at I/O 0xb818 (irq = 21) is a 16550A
On Mon, Apr 05, 2004 at 12:35:39PM +0200, Ruud Linders wrote:
> Now checking this on 2.6.5 it got more confusing, I now have with
> total of 6 serial ports a device number ttyS45 !?
And what happens if you detect a PCI modem at IO address 0x2e8 after
you've detected your PCI card and assigned it ttyS4?
Don't you think that would complain that their modem should be assigned
ttyS4 rather than their PCI multiport card getting it?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
I realise that my 'patch' isn't the perfect solution.
But how much sense makes adding a 4-port card and getting
ttyS14/15/44/45 for these 4-ports ?
As the first 4 serial ports, on x86 at least, are more or less
on standard 3f8/2f8/3e8/2e8 IO-ports an argument could be made to
reserve ttyS0/1/2/3 for these.
Reserving ttyS0-S43 (with ttyS14-15 as spare) doesn't make sense
to me.
And what if my next mobo doesn't have serial ports anymore and I
plugin a PCI card, I would expect them to start at ttyS0.
Anyway, I just wanted to point out that
a)these are strange numbers from user point of view
b)over kernel versions my ports keep moving to different names
and I'm NOT plugging in different hardware.
I guess I'll just do "cd /dev;ln -nfs ttyS14 ttyS2" and be done
with it or use udev (good time as ever to give that a try) or
keep patching my kernel or ...
_
Ruud
Now my PCI ports are moving between kernel versions
Russell King wrote:
> On Mon, Apr 05, 2004 at 12:35:39PM +0200, Ruud Linders wrote:
>
>>Now checking this on 2.6.5 it got more confusing, I now have with
>>total of 6 serial ports a device number ttyS45 !?
>
>
> And what happens if you detect a PCI modem at IO address 0x2e8 after
> you've detected your PCI card and assigned it ttyS4?
>
> Don't you think that would complain that their modem should be assigned
> ttyS4 rather than their PCI multiport card getting it?
>
On Mon, 2004-04-05 at 16:08, Ruud Linders wrote:
> I realise that my 'patch' isn't the perfect solution.
> But how much sense makes adding a 4-port card and getting
> ttyS14/15/44/45 for these 4-ports ?
does it matter really ????
(and if it does, why aren't you using udev ;)
> The way this device numbering seems to work is that many device names
> are reserved in include/asm/serial.h for devices like fourport/boca/hub6.
> Anything else (=all PCI cards?) gets a number still unassigned.
Right. Names for everything in SERIAL_PORT_DFNS get reserved. For
boxes with ACPI, we don't need SERIAL_PORT_DFNS at all (assuming you
build with CONFIG_SERIAL_8250_ACPI). ia64, for example, doesn't
define SERIAL_PORT_DFNS, so ports just get named sequentially in the
order they're discovered.
The following (untested) patch should give you the same behavior
when you supply the "noisaserial" argument. Note that this probably
won't work if you're using a serial console, because early serial
registration will fill in the ISA ports before "noisaserial" gets
parsed.
===== Documentation/kernel-parameters.txt 1.44 vs edited =====
--- 1.44/Documentation/kernel-parameters.txt Mon Mar 22 14:03:22 2004
+++ edited/Documentation/kernel-parameters.txt Tue Apr 6 09:39:07 2004
@@ -714,6 +714,8 @@
noisapnp [ISAPNP] Disables ISA PnP code.
+ noisaserial [SERIAL] Disables probing for legacy ISA serial ports.
+
noinitrd [RAM] Tells the kernel not to load any configured
initial RAM disk.
===== drivers/serial/8250.c 1.48 vs edited =====
--- 1.48/drivers/serial/8250.c Mon Mar 15 15:16:26 2004
+++ edited/drivers/serial/8250.c Tue Apr 6 09:41:16 2004
@@ -117,6 +117,15 @@
#define UART_NR (ARRAY_SIZE(old_serial_port) + CONFIG_SERIAL_8250_NR_UARTS)
+static int __init serial_probe_isa = 1;
+
+static int __init noisaserial(char *str)
+{
+ serial_probe_isa = 0;
+ return 1;
+}
+__setup("noisaserial", noisaserial);
+
#if defined(CONFIG_SERIAL_8250_RSA) && defined(MODULE)
#define PORT_RSA_MAX 4
@@ -1836,7 +1845,7 @@
static int first = 1;
int i;
- if (!first)
+ if (!first || !serial_probe_isa)
return;
first = 0;
On Tuesday 06 April 2004 10:37 am, Bjorn Helgaas wrote:
> > The way this device numbering seems to work is that many device names
> > are reserved in include/asm/serial.h for devices like fourport/boca/hub6.
> > Anything else (=all PCI cards?) gets a number still unassigned.
I forgot to mention another patch along these lines:
http://www.ussg.iu.edu/hypermail/linux/kernel/0402.1/0904.html
This gives you output like this:
ttyS0 at MMIO 0xf8030000 (HCDP PCI 0000:e0:01.1, irq = 49) is a 16550A
ttyS1 at MMIO 0xf8031000 (PCI 0000:e0:01.0, irq = 49) is a 16550A
ttyS2 at MMIO 0xf8030010 (PCI 0000:e0:01.1, irq = 49) is a 16550A
ttyS3 at MMIO 0xf8030038 (PCI 0000:e0:01.1, irq = 49) is a 16550A
ttyS4 at MMIO 0xff5e0000 (ACPI SER0, irq = 67) is a 16550A
so you have a clue about what ports are on what cards. There wasn't
any interest at the time, though.