Bogus serial port ttyS02

Bogus serial port ttyS02

[Geert Uytterhoeven]

Linux always finds 3 serial ports instead of 2:

| ttyS00 at 0x03f8 (irq = 4) is a 16550A
| ttyS01 at 0x02f8 (irq = 3) is a 16550A
| ttyS02 at 0x03e8 (irq = 4) is a 16450

The last one is bogus.

This is not exactly a new problem, and it happens with (and is not limited to)
both 2.4.21 and 2.6.0-test3. System is a PPC box (CHRP LongTrail) with a
National Semiconductor PC78308VUL SuperI/O, which has 2 internal 16550As.

Anyone with a clue? I know nothing about serial chip probing.


Ah, I still have some old dmesg outputs for that machine in my local CVS repo:

2.2.7: OK
2.3.18: OK
2.3.22: OK
2.3.42: not OK
2.3.47: not OK
2.3.48: not OK
2.3.50: not OK
2.3.51: not OK
2.3.99-pre3: not OK
2.4.0-test1: not OK
2.4.0-test1-ac7: OK
2.4.0-test1-ac10: OK
2.4.0-test11: not OK
2.4.0-test13-pre3: not OK
2.4.0-prerelease-ac5: not OK
2.4.0: not OK
2.4.1-pre2: not OK
2.4.1-pre10: not OK
2.4.1: not OK

So the problem was introduced between 2.3.22 and 2.3.42, and temporarily solved
in 2.4.0-test1-ac7 and 2.4.0-test1-ac10.

2.4.0-test1 has serial driver version 4.93 (2000-03-20)
2.4.0-test1-ac7 and 2.4.0-test1-ac10 have version 5.01 (2000-05-29)
2.4.0-test11 has version 5.02 (2000-08-09)

All are with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled. Looking at the diffs
between 2.4.0-test1 and 2.4.0-test1-ac7, and 2.4.0-test1-ac7 and 2.4.0-test11
I couldn't find anything suspicious.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Bogus serial port ttyS02

[Richard B. Johnson]

On Wed, 13 Aug 2003, Geert Uytterhoeven wrote:

>
> Linux always finds 3 serial ports instead of 2:
>
> | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> | ttyS02 at 0x03e8 (irq = 4) is a 16450
>
> The last one is bogus.

First, this looks like ix86 stuff, not m68k. Drivers for ix86
machines probe the de facto addresses for up to a maximum of
4 8250-type UARTS. Those addresses are:

(0)	0x3f8
(1)	0x2f8
(2)	0x3e8
(3)	0x328

(from the Phoenix SYSTEM BIOS book)

Usually, there are several bits that are permanently 0 in
some of the registers. This is used to "positively" identify
the chip. Note that many IR devices are also connected
to 8250-type UARTS.

I would guess that you have two serial ports, plus another
UART that's used for IR (maybe a IR keyboard???).

You can do `od /dev/ttyS2` from the root account and see
what happends.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Bogus serial port ttyS02

[Geert Uytterhoeven]

On Wed, 13 Aug 2003, Richard B. Johnson wrote:
> On Wed, 13 Aug 2003, Geert Uytterhoeven wrote:
> > Linux always finds 3 serial ports instead of 2:
> >
> > | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> > | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> > | ttyS02 at 0x03e8 (irq = 4) is a 16450
> >
> > The last one is bogus.
> 
> First, this looks like ix86 stuff, not m68k. Drivers for ix86

It's PPC, not m68k. Both PReP and CHRP have PC-style serial ports.

> machines probe the de facto addresses for up to a maximum of
> 4 8250-type UARTS. Those addresses are:
> 
> (0)	0x3f8
> (1)	0x2f8
> (2)	0x3e8
> (3)	0x328
> 
> (from the Phoenix SYSTEM BIOS book)
> 
> Usually, there are several bits that are permanently 0 in
> some of the registers. This is used to "positively" identify
> the chip. Note that many IR devices are also connected
> to 8250-type UARTS.
> 
> I would guess that you have two serial ports, plus another
> UART that's used for IR (maybe a IR keyboard???).

No, the Super I/O has only two serial ports, of which one can be used for IRDA.

> You can do `od /dev/ttyS2` from the root account and see
> what happends.

Nothing, it just waits for data. The same for `echo hello > /dev/ttyS2'. So the
serial driver things it has to wait to accept/send data.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Bogus serial port ttyS02

[Russell King]

On Wed, Aug 13, 2003 at 05:40:23PM +0200, Geert Uytterhoeven wrote:
> Linux always finds 3 serial ports instead of 2:
> 
> | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> | ttyS02 at 0x03e8 (irq = 4) is a 16450
> 
> The last one is bogus.

Do you know that it absolutely does not exist?  Can it exist on any
PPC box?  If the answer to both those questions is no, I suggest
you don't probe for it in the first place.

You could enable DEBUG_AUTOCONF in 8250.c in 2.6.0-test3 and give
further probing information. 8)

Looking at PPC's pc_serial.h, it seems that you've told it to probe
there using ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ.

ASYNC_SKIP_TEST means that we use a reduced test to probe for a port -
we just check that we can read back a value written to 0x3e9.  If this
suceeds, we decide that there is a port present, and go on to try and
derive its type.

If you want to enable the more rigorous tests, remove ASYNC_SKIP_TEST
from the port flags.  This will make us check that the device behaves
like a UART before deciding that it is one.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Bogus serial port ttyS02

[Geert Uytterhoeven]

On Wed, 13 Aug 2003, Russell King wrote:
> On Wed, Aug 13, 2003 at 05:40:23PM +0200, Geert Uytterhoeven wrote:
> > Linux always finds 3 serial ports instead of 2:
> > 
> > | ttyS00 at 0x03f8 (irq = 4) is a 16550A
> > | ttyS01 at 0x02f8 (irq = 3) is a 16550A
> > | ttyS02 at 0x03e8 (irq = 4) is a 16450
> > 
> > The last one is bogus.
> 
> Do you know that it absolutely does not exist?  Can it exist on any
> PPC box?  If the answer to both those questions is no, I suggest
> you don't probe for it in the first place.

Not on my box. But since it has an ISA slot, you can add legacy serial ports.

> You could enable DEBUG_AUTOCONF in 8250.c in 2.6.0-test3 and give
> further probing information. 8)

Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0: autoconf (0x03f8, 00000000): iir=3 iir1=6 iir2=6 type=16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1: autoconf (0x02f8, 00000000): iir=3 iir1=6 iir2=6 type=16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS2: autoconf (0x03e8, 00000000): iir=0 type=16450
ttyS2 at I/O 0x3e8 (irq = 4) is a 16450
ttyS3: autoconf (0x02e8, 00000000): LOOP test failed (10) type=unknown

> Looking at PPC's pc_serial.h, it seems that you've told it to probe
> there using ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ.
> 
> ASYNC_SKIP_TEST means that we use a reduced test to probe for a port -
> we just check that we can read back a value written to 0x3e9.  If this
> suceeds, we decide that there is a port present, and go on to try and
> derive its type.
> 
> If you want to enable the more rigorous tests, remove ASYNC_SKIP_TEST
> from the port flags.  This will make us check that the device behaves
> like a UART before deciding that it is one.

If I remove the ASYNC_SKIP_TEST flag, I get

ttyS2: autoconf (0x03e8, 00000000): LOOP test failed (10) type=unknown

and only the 2 existing ports are detected! Thanks!

Why is the ASYNC_SKIP_TEST flag needed? Would it be safe to remove it for PPC,
or are there possible side effects?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Bogus serial port ttyS02

[Geert Uytterhoeven]

On Wed, 13 Aug 2003, Geert Uytterhoeven wrote:
> On Wed, 13 Aug 2003, Russell King wrote:
> > You could enable DEBUG_AUTOCONF in 8250.c in 2.6.0-test3 and give
> > further probing information. 8)

This patch kills a warning if DEBUG_AUTOCONF is enabled:

--- linux-ppc-2.6.0-test3/drivers/serial/8250.c	Mon Aug 11 02:20:41 2003
+++ linux-longtrail-2.6.0-test3/drivers/serial/8250.c	Wed Aug 13 22:31:07 2003
@@ -557,7 +557,7 @@
 	if (!up->port.iobase && !up->port.mapbase && !up->port.membase)
 		return;
 
-	DEBUG_AUTOCONF("ttyS%d: autoconf (0x%04x, 0x%08lx): ",
+	DEBUG_AUTOCONF("ttyS%d: autoconf (0x%04x, %p): ",
 			up->port.line, up->port.iobase, up->port.membase);
 
 	/*
> > Looking at PPC's pc_serial.h, it seems that you've told it to probe
> > there using ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ.
> > 
> > ASYNC_SKIP_TEST means that we use a reduced test to probe for a port -
> > we just check that we can read back a value written to 0x3e9.  If this
> > suceeds, we decide that there is a port present, and go on to try and
> > derive its type.
> > 
> > If you want to enable the more rigorous tests, remove ASYNC_SKIP_TEST
> > from the port flags.  This will make us check that the device behaves
> > like a UART before deciding that it is one.
> 
> If I remove the ASYNC_SKIP_TEST flag, I get
> 
> ttyS2: autoconf (0x03e8, 00000000): LOOP test failed (10) type=unknown
> 
> and only the 2 existing ports are detected! Thanks!
> 
> Why is the ASYNC_SKIP_TEST flag needed? Would it be safe to remove it for PPC,
> or are there possible side effects?

This patch removes the ASYNC_SKIP_TEST flag on PPC:

--- linux-ppc-2.6.0-test3/include/asm-ppc/pc_serial.h	Mon Aug 11 02:21:00 2003
+++ linux-longtrail-2.6.0-test3/include/asm-ppc/pc_serial.h	Wed Aug 13 23:01:50 2003
@@ -28,10 +28,10 @@
 
 /* Standard COM flags (except for COM4, because of the 8514 problem) */
 #ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
 #define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
 #else
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF)
 #define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
 #endif
 
OK to apply?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Bogus serial port ttyS02

[Russell King]

On Sat, Aug 16, 2003 at 05:23:20PM +0200, Geert Uytterhoeven wrote:
> This patch kills a warning if DEBUG_AUTOCONF is enabled:
> 
> --- linux-ppc-2.6.0-test3/drivers/serial/8250.c	Mon Aug 11 02:20:41 2003
> +++ linux-longtrail-2.6.0-test3/drivers/serial/8250.c	Wed Aug 13 22:31:07 2003
> @@ -557,7 +557,7 @@
>  	if (!up->port.iobase && !up->port.mapbase && !up->port.membase)
>  		return;
>  
> -	DEBUG_AUTOCONF("ttyS%d: autoconf (0x%04x, 0x%08lx): ",
> +	DEBUG_AUTOCONF("ttyS%d: autoconf (0x%04x, %p): ",
>  			up->port.line, up->port.iobase, up->port.membase);
>  
>  	/*
> This patch removes the ASYNC_SKIP_TEST flag on PPC:
> 
> --- linux-ppc-2.6.0-test3/include/asm-ppc/pc_serial.h	Mon Aug 11 02:21:00 2003
> +++ linux-longtrail-2.6.0-test3/include/asm-ppc/pc_serial.h	Wed Aug 13 23:01:50 2003
> @@ -28,10 +28,10 @@
>  
>  /* Standard COM flags (except for COM4, because of the 8514 problem) */
>  #ifdef CONFIG_SERIAL_DETECT_IRQ
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
> +#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
>  #define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
>  #else
> -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
> +#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF)
>  #define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
>  #endif
>  
> OK to apply?

Both look fine to me.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html