Still some serial console corruption on sunsab

Still some serial console corruption on sunsab

[Meelis Roos]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 799 bytes --]

This U5 booting with serial console @ 9600,8,n,1

su0 at 0x000001fff13062f8 (irq = 4,7ea) is a 16550A
su1 at 0x000001fff13083f8 (irq = 9,7e9) is a 16550A
Console: ttyS0 (SAB82532)
ttyS0 at MMIO 0x1fff1400000 (irq = 7309792) is a SAB82532 V3.2
ttyS1 at MMIO 0x1fff1400040 (irq = 7309792) is a SAB82532 V3.2
[...]
Failed to mount /selinux/: No such file or directory
..É.¥œ..2.86 booting
Starting the hotplug events dispatcher: udevd.

No more corruption on startup. But there is more on shart of shutdown 
(the first line is the end of startup):

Starting K Display Manager: kdm.
M.¥Ñ.¡¥...to runlevel: 6
..¥...processes the TERM signal

Is this known to corrupt sometimes or is it thought to be fixed?
I'm running todays 2.6.14-rc4-gda64c6ee.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[Marc Zyngier]

>>>>> "Meelis" = Meelis Roos <mroos@linux.ee> writes:

Meelis> ..É.¥½..2.86 booting
Meelis> Starting the hotplug events dispatcher: udevd.

Meelis> M.¥Ñ.¡¥...to runlevel: 6
Meelis> ..¥...processes the TERM signal

Meelis> Is this known to corrupt sometimes or is it thought to be fixed?
Meelis> I'm running todays 2.6.14-rc4-gda64c6ee.

I've seen this kind of things for ages with sunsab. Looks like init
messes with the tty settings, and maybe it confuses the chip for a
while... 

	M.
-- 
And if you don't know where you're going, any road will take you there...

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 12 Oct 2005 12:28:17 +0300 (EEST)

> Is this known to corrupt sometimes or is it thought to be fixed?
> I'm running todays 2.6.14-rc4-gda64c6ee.

It's known, and unfortunate.

I tried everything to correct this problem, but to no avail.  The
current 2.6.x sunsab driver even defers all parameter changing in the
chip until the transmitter is %100 idle.  That still doesn't help,
as your trace shows.

I'll have to dig into init and see what kind of terminal setting
calls it does.

Thanks for the reminder about this problem.

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 12 Oct 2005 12:28:17 +0300 (EEST)

> Is this known to corrupt sometimes or is it thought to be fixed?

Can you say whether this same corruption occurs with
2.4.x kernels as well?

I just got back from a 2 week vacation and I plan on getting
back to this bug soon.

Re: Still some serial console corruption on sunsab

[Meelis Roos]

> Can you say whether this same corruption occurs with
> 2.4.x kernels as well?

Tried 2.4.27 from Debian, it occurs there too.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Sat, 5 Nov 2005 11:42:13 +0200 (EET)

> > Can you say whether this same corruption occurs with
> > 2.4.x kernels as well?
> 
> Tried 2.4.27 from Debian, it occurs there too.

So at least it's not a 2.4.x --> 2.6.x regression :-)

Re: Still some serial console corruption on sunsab

[Meelis Roos]

> So at least it's not a 2.4.x --> 2.6.x regression :-)

One thing I have noticed that may or may not be known is that it looks 
like it's changing between "online" and "offline" mode as seen from 
remote minicom when the garbage happens. It's normally offline during 
work and when I start reboot, it switches online and garbles first 
line or two.

There seem to be only a couple of terminal setting touchings in init but 
they tell nothing to me.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[Meelis Roos]

Additional data point: Debian package linux-image-2.6.14-2-sparc64 
2.6.14-3 corrupts more than standard kernel - there are several strings 
corrupted.

Hmm, it might be because of CONFIG_PROM_CONSOLE=y.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Fri, 18 Nov 2005 10:45:44 +0200 (EET)

> Additional data point: Debian package linux-image-2.6.14-2-sparc64 
> 2.6.14-3 corrupts more than standard kernel - there are several strings 
> corrupted.
> 
> Hmm, it might be because of CONFIG_PROM_CONSOLE=y.

Possibly.

I haven't had any chance to look into this one, and because
it's not even a regression from 2.4.x's behavior it's of
even lower priority.  Sorry :-/

Re: Still some serial console corruption on sunsab

[David S. Miller]

I wonder if we're setting the CEC and TEC timeouts too short.

Can you give this patch a spin?  There are some other things
we can try if this still doesn't fix things.

Thanks.

diff --git a/drivers/serial/sunsab.c b/drivers/serial/sunsab.c
index ba9381f..7665a9d 100644
--- a/drivers/serial/sunsab.c
+++ b/drivers/serial/sunsab.c
@@ -93,7 +93,7 @@ static char *sab82532_version[16] = {
 
 static __inline__ void sunsab_tec_wait(struct uart_sunsab_port *up)
 {
-	int timeout = up->tec_timeout;
+	int timeout = SAB82532_MAX_TEC_TIMEOUT;
 
 	while ((readb(&up->regs->r.star) & SAB82532_STAR_TEC) && --timeout)
 		udelay(1);
@@ -101,7 +101,7 @@ static __inline__ void sunsab_tec_wait(s
 
 static __inline__ void sunsab_cec_wait(struct uart_sunsab_port *up)
 {
-	int timeout = up->cec_timeout;
+	int timeout = SAB82532_MAX_CEC_TIMEOUT;
 
 	while ((readb(&up->regs->r.star) & SAB82532_STAR_CEC) && --timeout)
 		udelay(1);

Re: Still some serial console corruption on sunsab

[Meelis Roos]

> I wonder if we're setting the CEC and TEC timeouts too short.
>
> Can you give this patch a spin?  There are some other things
> we can try if this still doesn't fix things.

Unfortunately it does not fix the corruption.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 23 Nov 2005 09:12:23 +0200 (EET)

> > I wonder if we're setting the CEC and TEC timeouts too short.
> >
> > Can you give this patch a spin?  There are some other things
> > we can try if this still doesn't fix things.
> 
> Unfortunately it does not fix the corruption.

Thanks for testing...

Give this one a spin.

diff --git a/drivers/serial/sunsab.c b/drivers/serial/sunsab.c
index ba9381f..eae54a7 100644
--- a/drivers/serial/sunsab.c
+++ b/drivers/serial/sunsab.c
@@ -461,6 +461,9 @@ static void sunsab_tx_idle(struct uart_s
 	if (test_bit(SAB82532_REGS_PENDING, &up->irqflags)) {
 		u8 tmp;
 
+		sunsab_tec_wait(up);
+		sunsab_cec_wait(up);
+
 		clear_bit(SAB82532_REGS_PENDING, &up->irqflags);
 		writeb(up->cached_mode, &up->regs->rw.mode);
 		writeb(up->cached_pvr, &up->regs->rw.pvr);

Re: Still some serial console corruption on sunsab

[Meelis Roos]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 512 bytes --]

> Give this one a spin.

It's still corrupting the same way it has been done before.

BUT now I noticed that the previous patch garbled it differently.
Ususally I see things like that:
..É.¥œ..2.86 booting
(instead of init version 2.86 booting)

and I still see it with this patch. But with previous patch I saw
  version 2.86 booting
and perhaps some more dropped characters here and there. Entering 
runlevel 2 message was still garbage with previous patch too.

-- 
Meelis Roos (mroos@linux.ee)

Re: Still some serial console corruption on sunsab

[David S. Miller]

From: Meelis Roos <mroos@linux.ee>
Date: Wed, 23 Nov 2005 10:26:12 +0200 (EET)

> BUT now I noticed that the previous patch garbled it differently.
> Ususally I see things like that:
> ..É.¥½..2.86 booting
> (instead of init version 2.86 booting)
> 
> and I still see it with this patch. But with previous patch I saw
>   version 2.86 booting
> and perhaps some more dropped characters here and there. Entering 
> runlevel 2 message was still garbage with previous patch too.

Ok, thanks for the info, I'll go back to studying the SAB programmer's
manual (available at:
	http://www.commtech-fastcom.com/data_sheets/sab82532.pdf
as well as other places, just give "SAB82532 manual" to any search
engine) and the driver to try and get some more ideas.