Someting's busted with serial in 2.6.11 latest

Someting's busted with serial in 2.6.11 latest

[Stephen Hemminger]

Some checkin since 2.6.11 has caused the serial driver to
drop characters.  Console output is chopped and messages are garbled.
Even the shell prompt gets truncated.

Re: Someting's busted with serial in 2.6.11 latest

[Russell King]

On Wed, Mar 09, 2005 at 03:50:49PM -0800, Stephen Hemminger wrote:
> Some checkin since 2.6.11 has caused the serial driver to
> drop characters.  Console output is chopped and messages are garbled.
> Even the shell prompt gets truncated.

There was a problem with 2.6.11-bk1 which should now be resolved.

Is this still true of the latest bk kernel?  Also, seeing the kernel
messages may provide some hint.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Someting's busted with serial in 2.6.11 latest

[Steven Cole]

Russell King wrote:
> On Wed, Mar 09, 2005 at 03:50:49PM -0800, Stephen Hemminger wrote:
> 
>>Some checkin since 2.6.11 has caused the serial driver to
>>drop characters.  Console output is chopped and messages are garbled.
>>Even the shell prompt gets truncated.
> 
> 
> There was a problem with 2.6.11-bk1 which should now be resolved.
> 
> Is this still true of the latest bk kernel?  Also, seeing the kernel
> messages may provide some hint.
> 

Here is a post I made perhaps relevant to this.

http://marc.theaimsgroup.com/?l=linux-kernel&m=111042402103071&w=2

I'll test current bk tonight, but I don't see any recent fix to
drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.

Steven

Re: Someting's busted with serial in 2.6.11 latest

[Russell King]

On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
> Russell King wrote:
> > On Wed, Mar 09, 2005 at 03:50:49PM -0800, Stephen Hemminger wrote:
> > 
> >>Some checkin since 2.6.11 has caused the serial driver to
> >>drop characters.  Console output is chopped and messages are garbled.
> >>Even the shell prompt gets truncated.
> > 
> > 
> > There was a problem with 2.6.11-bk1 which should now be resolved.
> > 
> > Is this still true of the latest bk kernel?  Also, seeing the kernel
> > messages may provide some hint.
> > 
> 
> Here is a post I made perhaps relevant to this.
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111042402103071&w=2
> 
> I'll test current bk tonight, but I don't see any recent fix to
> drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.

There are only two recent revisions to 8250.c.  One adds slightly buggy
Xscale UART detection, the other fixes the buggyness.

What I don't know is whether either of these two changes are the cause
of your exact problems, because I don't actually know what you're
testing.  Since Stephen's bug is a lot more well defined than yours,
it makes sense to tackle Stephen's situation first.

The reason for this is taht pppd getting a SIGHUP doesn't actually tell
me anything at all.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Someting's busted with serial in 2.6.11 latest

[Russell King]

On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
> I'll test current bk tonight, but I don't see any recent fix to
> drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.

Ok, so Stephen's bug is already fixed.  After testing the latest bk, if
you find your bug isn't resolved, please try to isolate the change by
applying this patch.  If this doesn't resolve it, then your change of
behaviour hasn't been caused by changes to 8250.c, but must be down to
some other part of the kernel.

===== linux-2.6-rmk/drivers/serial/8250.c 1.97 vs 1.95 =====
--- 1.97/drivers/serial/8250.c	2005-03-08 10:04:55 +00:00
+++ 1.95/drivers/serial/8250.c	2005-02-28 16:05:18 +00:00
@@ -642,7 +642,6 @@
 static void autoconfig_16550a(struct uart_8250_port *up)
 {
 	unsigned char status1, status2;
-	unsigned int iersave;
 
 	up->port.type = PORT_16550A;
 	up->capabilities |= UART_CAP_FIFO;
@@ -729,7 +728,6 @@
 	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
 	status2 = serial_in(up, UART_IIR) >> 5;
 	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
-	serial_outp(up, UART_LCR, 0);
 
 	DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);
 
@@ -738,40 +736,6 @@
 		up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
 		return;
 	}
-
-	/*
-	 * Try writing and reading the UART_IER_UUE bit (b6).
-	 * If it works, this is probably one of the Xscale platform's
-	 * internal UARTs.
-	 * We're going to explicitly set the UUE bit to 0 before
-	 * trying to write and read a 1 just to make sure it's not
-	 * already a 1 and maybe locked there before we even start start.
-	 */
-	iersave = serial_in(up, UART_IER);
-	serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
-	if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
-		/*
-		 * OK it's in a known zero state, try writing and reading
-		 * without disturbing the current state of the other bits.
-		 */
-		serial_outp(up, UART_IER, iersave | UART_IER_UUE);
-		if (serial_in(up, UART_IER) & UART_IER_UUE) {
-			/*
-			 * It's an Xscale.
-			 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
-			 */
-			DEBUG_AUTOCONF("Xscale ");
-			up->port.type = PORT_XSCALE;
-			return;
-		}
-	} else {
-		/*
-		 * If we got here we couldn't force the IER_UUE bit to 0.
-		 * Log it and continue.
-		 */
-		DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
-	}
-	serial_outp(up, UART_IER, iersave);
 }
 
 /*


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Someting's busted with serial in 2.6.11 latest

[Steven Cole]

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

On Thursday 10 March 2005 03:59 pm, Russell King wrote:
> On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
> > I'll test current bk tonight, but I don't see any recent fix to
> > drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
> 
> Ok, so Stephen's bug is already fixed.  After testing the latest bk, if
> you find your bug isn't resolved, please try to isolate the change by
> applying this patch.  If this doesn't resolve it, then your change of
> behaviour hasn't been caused by changes to 8250.c, but must be down to
> some other part of the kernel.
> 
> ===== linux-2.6-rmk/drivers/serial/8250.c 1.97 vs 1.95 =====
> --- 1.97/drivers/serial/8250.c	2005-03-08 10:04:55 +00:00
> +++ 1.95/drivers/serial/8250.c	2005-02-28 16:05:18 +00:00
> @@ -642,7 +642,6 @@
>  static void autoconfig_16550a(struct uart_8250_port *up)
>  {
>  	unsigned char status1, status2;
> -	unsigned int iersave;
>  
>  	up->port.type = PORT_16550A;
>  	up->capabilities |= UART_CAP_FIFO;
> @@ -729,7 +728,6 @@
>  	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
>  	status2 = serial_in(up, UART_IIR) >> 5;
>  	serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
> -	serial_outp(up, UART_LCR, 0);
>  
>  	DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);
>  
> @@ -738,40 +736,6 @@
>  		up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
>  		return;
>  	}
> -
> -	/*
> -	 * Try writing and reading the UART_IER_UUE bit (b6).
> -	 * If it works, this is probably one of the Xscale platform's
> -	 * internal UARTs.
> -	 * We're going to explicitly set the UUE bit to 0 before
> -	 * trying to write and read a 1 just to make sure it's not
> -	 * already a 1 and maybe locked there before we even start start.
> -	 */
> -	iersave = serial_in(up, UART_IER);
> -	serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
> -	if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
> -		/*
> -		 * OK it's in a known zero state, try writing and reading
> -		 * without disturbing the current state of the other bits.
> -		 */
> -		serial_outp(up, UART_IER, iersave | UART_IER_UUE);
> -		if (serial_in(up, UART_IER) & UART_IER_UUE) {
> -			/*
> -			 * It's an Xscale.
> -			 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
> -			 */
> -			DEBUG_AUTOCONF("Xscale ");
> -			up->port.type = PORT_XSCALE;
> -			return;
> -		}
> -	} else {
> -		/*
> -		 * If we got here we couldn't force the IER_UUE bit to 0.
> -		 * Log it and continue.
> -		 */
> -		DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
> -	}
> -	serial_outp(up, UART_IER, iersave);
>  }
>  
>  /*
> 
> 
I am currently doing a bk pull from linux.bkbits.net/linux-2.6, and can test the above 
patch if dialup via a serial modem breaks again, but I think I already know the answer.

I first noticed this _after_ the last one-line change to drivers/serial/8250.c.
Last night, after establishing that 2.6.11-bk1 was the earliest kernel to have the problem,
and reverting the Xscale patch fixed it, I tried with last night's bk-current.
It also failed as previously described, and worked with the Xscale patch reverted.

Here is a snippet from dmesg from my current kernel (with Xscale reverted) working
on dialup.via serial modem.

[   43.034336] serio: i8042 AUX port at 0x60,0x64 irq 12
[   43.034520] serio: i8042 KBD port at 0x60,0x64 irq 1
[   43.034616] Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
[   43.034924] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   43.038087] pnp: Device 00:01.00 activated.
[   43.038329] ttyS1 at I/O 0x2f8 (irq = 10) is a 16550A

For completeness, here is the patch I applied with patch -p1 -R:

Steven

[-- Attachment #2: revert-me.patch --]
[-- Type: text/x-diff, Size: 1583 bytes --]

diff -Nru a/drivers/serial/8250.c b/drivers/serial/8250.c
--- a/drivers/serial/8250.c	2005-02-28 08:05:18 -08:00
+++ b/drivers/serial/8250.c	2005-01-24 08:00:57 -08:00
@@ -642,6 +642,7 @@
 static void autoconfig_16550a(struct uart_8250_port *up)
 {
 	unsigned char status1, status2;
+	unsigned int iersave;
 
 	up->port.type = PORT_16550A;
 	up->capabilities |= UART_CAP_FIFO;
@@ -736,6 +737,40 @@
 		up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
 		return;
 	}
+
+	/*
+	 * Try writing and reading the UART_IER_UUE bit (b6).
+	 * If it works, this is probably one of the Xscale platform's
+	 * internal UARTs.
+	 * We're going to explicitly set the UUE bit to 0 before
+	 * trying to write and read a 1 just to make sure it's not
+	 * already a 1 and maybe locked there before we even start start.
+	 */
+	iersave = serial_in(up, UART_IER);
+	serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
+	if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
+		/*
+		 * OK it's in a known zero state, try writing and reading
+		 * without disturbing the current state of the other bits.
+		 */
+		serial_outp(up, UART_IER, iersave | UART_IER_UUE);
+		if (serial_in(up, UART_IER) & UART_IER_UUE) {
+			/*
+			 * It's an Xscale.
+			 * We'll leave the UART_IER_UUE bit set to 1 (enabled).
+			 */
+			DEBUG_AUTOCONF("Xscale ");
+			up->port.type = PORT_XSCALE;
+			return;
+		}
+	} else {
+		/*
+		 * If we got here we couldn't force the IER_UUE bit to 0.
+		 * Log it and continue.
+		 */
+		DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
+	}
+	serial_outp(up, UART_IER, iersave);
 }
 
 /*

Re: Someting's busted with serial in 2.6.11 latest

[Steven Cole]

On Thursday 10 March 2005 03:59 pm, Russell King wrote:
> On Thu, Mar 10, 2005 at 03:40:11PM -0700, Steven Cole wrote:
> > I'll test current bk tonight, but I don't see any recent fix to
> > drivers/serial/8250.c when browsing linux.bkbits.net/linux-2.6.
> 
> Ok, so Stephen's bug is already fixed.  After testing the latest bk, if
> you find your bug isn't resolved, please try to isolate the change by
> applying this patch.  If this doesn't resolve it, then your change of
> behaviour hasn't been caused by changes to 8250.c, but must be down to
> some other part of the kernel.

OK, latest 2.6.11-bk works just fine.  Although I thought I had a failure
with a fairly recent snapshot, I must have had a version before the fix.
Sorry for any confusion.

FWIW, the failing kernels reported: ttyS0 at I/O 0x3f8 (irq = 4) is a XScale

But now, all is fine.  Thanks.

Steven