Hi,
I attached a null modem cable to my notebook and I'm seeing garbage as
soon as the serial driver is loaded. I tried booting with init=/bin/bash
to be sure that it's not some rc script doing strange things to the
serial port, but this didn't solve the problem.
This is the relevant part of .config:
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_CS is not set
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
I also tried with ACPI discovery (just in case) without success:
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
CONFIG_SERIAL_8250_DETECT_IRQ=y
# CONFIG_SERIAL_8250_MULTIPORT is not set
# CONFIG_SERIAL_8250_RSA is not set
This is kernel command line:
Kernel command line: BOOT_IMAGE=linux-2.6.12rc1 ro root=305 video=sisfb:mode:1024x768x16 console=tty0 console=ttyS0,38400n8 init=/bin/bash
And this is where garbage appears:
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
[garbage]
Once I get the shell using 'clear' cures the problem. The log (from
dmesg) should be:
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
This is the first time that I use serial console with the notebook, but
I've done this before with other machines and never saw this problem.
Googling aroung I found another user with the same problem:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0442.html
but no answer :(
Any suggestion?
Luca
--
Home: http://kronoz.cjb.net
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!
On Fri, Mar 25, 2005 at 09:24:15PM +0100, Luca wrote:
> I attached a null modem cable to my notebook and I'm seeing garbage as
> soon as the serial driver is loaded. I tried booting with init=/bin/bash
> to be sure that it's not some rc script doing strange things to the
> serial port, but this didn't solve the problem.
I'm uncertain how this problem can occur, unless you have one of:
* serial debugging enabled (which isn't compatible with serial console)
* a NS16550A, in which case dwmw2 needs to rework his autodetect code to
adjust the baud rate appropriately.
I suspect your case is the latter.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Il Fri, Mar 25, 2005 at 08:38:53PM +0000, Russell King ha scritto:
> On Fri, Mar 25, 2005 at 09:24:15PM +0100, Luca wrote:
> > I attached a null modem cable to my notebook and I'm seeing garbage as
> > soon as the serial driver is loaded. I tried booting with init=/bin/bash
> > to be sure that it's not some rc script doing strange things to the
> > serial port, but this didn't solve the problem.
>
> I'm uncertain how this problem can occur, unless you have one of:
>
> * serial debugging enabled (which isn't compatible with serial console)
Do you mean #define DEBUG in serial_core.c? No.
> * a NS16550A, in which case dwmw2 needs to rework his autodetect code to
> adjust the baud rate appropriately.
Well, serial_core seems to think so:
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
Luca
--
Home: http://kronoz.cjb.net
La mia opinione puo` essere cambiata, ma non il fatto che ho ragione.
>Well, serial_core seems to think so:
>
>Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
>ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
>ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
>ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
Does it work if you set the baud rate manually, as a bootloader option?
Jan Engelhardt
--
No TOFU for me, please.
Il Sat, Mar 26, 2005 at 11:16:09AM +0100, Jan Engelhardt ha scritto:
> >Well, serial_core seems to think so:
> >
> >Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
> >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
> >ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
> >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
>
> Does it work if you set the baud rate manually, as a bootloader option?
I'm using console=ttyS0,38400n8. But it also happens with 9600, 57600
and 115200.
Luca
--
Home: http://kronoz.cjb.net
Mi piace avere amici rispettabili;
Mi piace essere il peggiore della compagnia.
On Sat, Mar 26, 2005 at 11:16:09AM +0100, Jan Engelhardt wrote:
> >Well, serial_core seems to think so:
> >
> >Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
> >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
> >ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
> >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
>
> Does it work if you set the baud rate manually, as a bootloader option?
Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
ago) changes the prescaler setting for this device so we can use the
higher speed baud rates. This means any programmed divisor (programmed
at early serial console initialisation time) suddenly becomes wrong as
soon as we fiddle with the prescaler during normal UART initialisation
time.
I think the argument for not initialising serial console _until_ after
UART initialisation time is gaining more technical merit:
1. spinlock initialisation issues (see other threads)
2. prescaler/divisor interaction issues (this thread)
even though it isn't _that_ desirable.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> ago) changes the prescaler setting for this device so we can use the
> higher speed baud rates. This means any programmed divisor (programmed
> at early serial console initialisation time) suddenly becomes wrong as
> soon as we fiddle with the prescaler during normal UART initialisation
> time.
FWIW, I see the same thing here on some Dell Poweredge boxes:
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<garbage>
But intererstingly, on identical boxes, the garbage only appears on
those hooked up to a PortMaster device - those using a Cyclades never
display this problem. (???)
Phil
On Sat, Mar 26, 2005 at 07:55:49AM -0800, Phil Oester wrote:
> On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
> > Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> > ago) changes the prescaler setting for this device so we can use the
> > higher speed baud rates. This means any programmed divisor (programmed
> > at early serial console initialisation time) suddenly becomes wrong as
> > soon as we fiddle with the prescaler during normal UART initialisation
> > time.
>
> FWIW, I see the same thing here on some Dell Poweredge boxes:
>
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> <garbage>
>
> But intererstingly, on identical boxes, the garbage only appears on
> those hooked up to a PortMaster device - those using a Cyclades never
> display this problem. (???)
Sorry, I don't understand your scenarios. Can you explain the
circumstances under which you see corruption?
>From the kernel messages you've quoted above, I can only think that
you're not using ttyS0 as the serial console - if you were, my
understanding of this issue would indicate that you should get the
garbage immediately after the line starting "Serial:"
Either my understanding of the cause of this problem is wrong, or
I'm not understanding your setup.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sat, Mar 26, 2005 at 04:37:29PM +0000, Russell King wrote:
> > But intererstingly, on identical boxes, the garbage only appears on
> > those hooked up to a PortMaster device - those using a Cyclades never
> > display this problem. (???)
>
> Sorry, I don't understand your scenarios. Can you explain the
> circumstances under which you see corruption?
>
> From the kernel messages you've quoted above, I can only think that
> you're not using ttyS0 as the serial console - if you were, my
> understanding of this issue would indicate that you should get the
> garbage immediately after the line starting "Serial:"
>
> Either my understanding of the cause of this problem is wrong, or
> I'm not understanding your setup.
I have a number of PowerEdge 2550 servers. All are setup with serial
console on ttyS0 @ 9600. One group uses a (old) Portmaster device for console
access, the other group uses a Cyclades device. Only those servers
using the Portmaster device exhibit the garbage problem. The Cyclades
group never displays garbage on boot.
Phil
On Sat, Mar 26, 2005 at 04:37:29PM +0000, Russell King wrote:
> > serio: i8042 AUX port at 0x60,0x64 irq 12
> > serio: i8042 KBD port at 0x60,0x64 irq 1
> > Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
Garbage here
Sorry -- I was relying upon my (flawed) memory of the bootup sequence,
but sending you the contents from /var/log/dmesg.
Phil
Hi,
I have come across a 16550A myself (in VMware) and so, tested it.
Linux reports it as a "16550A" while OpenBSD says it's a "NS16550A" --
output to this serial console (vmware: file) works fine, though.
My real box's serial is also a 16550A but havenot tested that- got no cable.
Jan Engelhardt
--
No TOFU for me, please.
On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> ago) changes the prescaler setting for this device so we can use the
> higher speed baud rates. This means any programmed divisor (programmed
> at early serial console initialisation time) suddenly becomes wrong as
> soon as we fiddle with the prescaler during normal UART initialisation
> time.
Seems like you are correct, given the below patch fixes the garbage
output for me.
Phil
On Mon, Mar 28, 2005 at 09:36:52AM -0800, Phil Oester wrote:
> On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
> > Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> > ago) changes the prescaler setting for this device so we can use the
> > higher speed baud rates. This means any programmed divisor (programmed
> > at early serial console initialisation time) suddenly becomes wrong as
> > soon as we fiddle with the prescaler during normal UART initialisation
> > time.
>
> Seems like you are correct, given the below patch fixes the garbage
> output for me.
David,
Is this patch ok for you?
--- linux-standard/drivers/serial/8250.c 2005-03-02 02:37:47.000000000 -0500
+++ linux-dellfw/drivers/serial/8250.c 2005-03-28 12:28:34.560032856 -0500
@@ -698,7 +698,7 @@
serial_outp(up, UART_MCR, status1);
if ((status2 ^ status1) & UART_MCR_LOOP) {
-#ifndef CONFIG_PPC
+#if 0
serial_outp(up, UART_LCR, 0xE0);
status1 = serial_in(up, 0x04); /* EXCR1 */
status1 &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
> >
> > Seems like you are correct, given the below patch fixes the garbage
> > output for me.
>
> David,
>
> Is this patch ok for you?
Just an aside, I've had this patch in my own internal tree for over a
year I never thought it would be kernel acceptable... but I noticed
this problem a long time ago and thought it was an issue with my
internal hardware as I never saw it on a normal board...
Dave.
Phil Oester <[email protected]> wrote:
>On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
>> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
>> ago) changes the prescaler setting for this device so we can use the
>> higher speed baud rates. This means any programmed divisor (programmed
>> at early serial console initialisation time) suddenly becomes wrong as
>> soon as we fiddle with the prescaler during normal UART initialisation
>> time.
>
>FWIW, I see the same thing here on some Dell Poweredge boxes:
>
>serio: i8042 AUX port at 0x60,0x64 irq 12
>serio: i8042 KBD port at 0x60,0x64 irq 1
>Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
>ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
><garbage>
>
>But intererstingly, on identical boxes, the garbage only appears on
>those hooked up to a PortMaster device - those using a Cyclades never
>display this problem. (???)
We have a variety of Dell rackmount systems, also on Cyclades, and see
this mess everywhere.
I had reported this problem a little while ago, see
http://marc.theaimsgroup.com/?l=linux-kernel&m=111036598927105&w=2
but unfortunately didn't get any response at that time.
Paul Slootman
On Wed, Apr 13, 2005 at 12:45:51PM +0000, Paul Slootman wrote:
> We have a variety of Dell rackmount systems, also on Cyclades, and see
> this mess everywhere.
>
> I had reported this problem a little while ago, see
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111036598927105&w=2
> but unfortunately didn't get any response at that time.
Read the remainder of the thread for a workaround.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.3/1061.html
Phil
On Wed, 2005-04-13 at 12:45 +0000, Paul Slootman wrote:
> Phil Oester <[email protected]> wrote:
> >On Sat, Mar 26, 2005 at 03:10:05PM +0000, Russell King wrote:
> >> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> >> ago) changes the prescaler setting for this device so we can use the
> >> higher speed baud rates. This means any programmed divisor (programmed
> >> at early serial console initialisation time) suddenly becomes wrong as
> >> soon as we fiddle with the prescaler during normal UART initialisation
> >> time.
Hmm. Why aren't we recalculating the divisor when we change the
prescaler? This used to work for serial consoles at the time -- even for
serial consoles about 115200 baud, IIRC.
--
dwmw2
On Mon, 2005-03-28 at 20:02 +0100, Russell King wrote:
> Is this patch ok for you?
Not really; it's just a quick hack applied without any real
consideration of the problem. If we're messing up the baud rate when we
change the master clock, then just make it change the divisor
accordingly at the same time. We don't seem to store the active
parameters of the serial console anywhere useful; we can do it just by
reading back the divisor and multiplying by eight though...
Tom, does this also mean you don't need the 'ifndef ppc'?
--- linux/drivers/serial/8250.c~ 2004-10-18 22:53:08.000000000 +0100
+++ linux/drivers/serial/8250.c 2005-05-03 13:54:39.394011032 +0100
@@ -567,13 +567,25 @@ static void autoconfig_16550a(struct uar
if ((status2 ^ status1) & UART_MCR_LOOP) {
#ifndef CONFIG_PPC
+ unsigned short quot;
+
serial_outp(up, UART_LCR, 0xE0);
status1 = serial_in(up, 0x04); /* EXCR1 */
status1 &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */
status1 |= 0x10; /* 1.625 divisor for baud_base --> 921600 */
serial_outp(up, 0x04, status1);
- serial_outp(up, UART_LCR, 0);
up->port.uartclk = 921600*16;
+
+ /* Adjust the baud rate to match, in case we're
+ already using the port */
+ quot = serial_inp(up, UART_DLM) << 8;
+ quot += serial_inp(up, UART_DLL);
+ quot <<= 3;
+ serial_outp(up, UART_DLL, quot & 0xff);
+ serial_outp(up, UART_DLM, quot >> 8);
+
+ serial_outp(up, UART_LCR, 0);
+
#endif
up->port.type = PORT_NS16550A;
--
dwmw2
On Tue, May 03, 2005 at 03:17:12PM +0100, David Woodhouse wrote:
> Not really; it's just a quick hack applied without any real
> consideration of the problem. If we're messing up the baud rate when we
> change the master clock, then just make it change the divisor
> accordingly at the same time. We don't seem to store the active
> parameters of the serial console anywhere useful; we can do it just by
> reading back the divisor and multiplying by eight though...
FYI, just tested this patch, and it does solve the garbage problem for me.
Thanks,
Phil
On Tue, May 03, 2005 at 03:17:12PM +0100, David Woodhouse wrote:
> On Mon, 2005-03-28 at 20:02 +0100, Russell King wrote:
> > Is this patch ok for you?
>
> Not really; it's just a quick hack applied without any real
> consideration of the problem. If we're messing up the baud rate when we
> change the master clock, then just make it change the divisor
> accordingly at the same time. We don't seem to store the active
> parameters of the serial console anywhere useful; we can do it just by
> reading back the divisor and multiplying by eight though...
>
> Tom, does this also mean you don't need the 'ifndef ppc'?
I don't recall the problem well enough right now, but I'll go toss this
into a current git tree and let you know.
--
Tom Rini
http://gate.crashing.org/~trini/
On Tue, 2005-05-03 at 08:11 -0700, Tom Rini wrote:
> I don't recall the problem well enough right now, but I'll go toss this
> into a current git tree and let you know.
With what hardware are you testing? Was this really a NatSemi SuperIO
chip, or was it a false positive in the detection?
--
dwmw2
On Tue, May 03, 2005 at 04:23:40PM +0100, David Woodhouse wrote:
> On Tue, 2005-05-03 at 08:11 -0700, Tom Rini wrote:
> > I don't recall the problem well enough right now, but I'll go toss this
> > into a current git tree and let you know.
>
> With what hardware are you testing? Was this really a NatSemi SuperIO
> chip, or was it a false positive in the detection?
This was on, I believe, the Motorola Sandpoint, which really does have a
NatSemi SuperIO.
--
Tom Rini
http://gate.crashing.org/~trini/
On Tue, May 03, 2005 at 08:11:59AM -0700, Tom Rini wrote:
> On Tue, May 03, 2005 at 03:17:12PM +0100, David Woodhouse wrote:
> > On Mon, 2005-03-28 at 20:02 +0100, Russell King wrote:
> > > Is this patch ok for you?
> >
> > Not really; it's just a quick hack applied without any real
> > consideration of the problem. If we're messing up the baud rate when we
> > change the master clock, then just make it change the divisor
> > accordingly at the same time. We don't seem to store the active
> > parameters of the serial console anywhere useful; we can do it just by
> > reading back the divisor and multiplying by eight though...
> >
> > Tom, does this also mean you don't need the 'ifndef ppc'?
>
> I don't recall the problem well enough right now, but I'll go toss this
> into a current git tree and let you know.
Dropping the 'ifndef ppc' is fine on my Motorola Sandpoint which I do
believe exhibited the problem previously. I've cc'd Kumar Gala since I see
on IRC that 85xx boards might also have had a problem here.
--
Tom Rini
http://gate.crashing.org/~trini/