Serial port text corruption

Serial port text corruption

[Joakim Tjernlund]

Details:
Sometimes when connecting the RS323 port between a laptop on our custom board
to login into a bash shell it looks like this:

Press return to get a login prompt, type username(root), hit return. Now
I expect to see the "Password: " prompt, but instead I see
random crap chars. Wait until the login timeouts, about 60 seconds, the timeout message
is also crap chars, but the following login prompt displays OK and now
I can login without any crap chars.

This is very confusing and I would fix it but I don't know where to start.
Any guesses as to where the problem is? Kernel serial layer, the 8xx uart.c driver,
the user space login program or somewhere else?

SMC1 is the serial HW used on a 860/862 CPU.
Kernel: linuxppc_2_4_devel from around 2.4.21-rc6 with all 8xx_io/uart.c patched to
current 2.4 version.
Userspace progs are from MontaVista hardhat 2.0. Login uses PAM.

 Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Serial port text corruption

[VanBaren, Gerald (AGRE)]

I would look at the SMC1 buffering and handling of caches (either snooping, not caching the buffers, or flushing before transmitting).

Another possiblility is sending data that is stored on the stack in a subroutine which subsequently returns before the data is actually transmitted -- when you are lucky, the data hasn't changed when the Tx occurs, when you are unlucky, a call sequence has overwritten the string on the stack.  Since this is (presumably) standard linux and that sort of a problem would have been found and fixed loooong ago in the linux core code, I would concentrate on your low level code.

Just to eliminate variables, you should hook a logic analyzer or 'scope to the board's Tx line and verify the baud rate hasn't changed when you get the garbage characters.  If the baud rate has changed, it will be a clocking problem.

gvb


> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Joakim
> Tjernlund
> Sent: Tuesday, May 18, 2004 6:03 AM
> To: Linuxppc-Embedded@Lists. Linuxppc. Org
> Subject: Serial port text corruption
>
>
>
> Details:
> Sometimes when connecting the RS323 port between a laptop on
> our custom board
> to login into a bash shell it looks like this:
>
> Press return to get a login prompt, type username(root), hit
> return. Now
> I expect to see the "Password: " prompt, but instead I see
> random crap chars. Wait until the login timeouts, about 60
> seconds, the timeout message
> is also crap chars, but the following login prompt displays OK and now
> I can login without any crap chars.
>
> This is very confusing and I would fix it but I don't know
> where to start.
> Any guesses as to where the problem is? Kernel serial layer,
> the 8xx uart.c driver,
> the user space login program or somewhere else?
>
> SMC1 is the serial HW used on a 860/862 CPU.
> Kernel: linuxppc_2_4_devel from around 2.4.21-rc6 with all
> 8xx_io/uart.c patched to
> current 2.4 version.
> Userspace progs are from MontaVista hardhat 2.0. Login uses PAM.
>
>  Jocke
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial port text corruption

[Dan Malek]

On May 18, 2004, at 6:03 AM, Joakim Tjernlund wrote:

> This is very confusing and I would fix it but I don't know where to
> start.
> Any guesses as to where the problem is? Kernel serial layer, the 8xx
> uart.c driver,
> the user space login program or somewhere else?

Are you using a USB to serial adapter on your laptop?  I've seen similar
things on many different systems only to trace down problems with the
USB/serial adapter and the host terminal emulation program.  Find some
computer with a real serial port and ensure it fails the same way.

On the other hand, many. many years ago when the 8xx uart driver was
written we added some delays during mode changes (which happens
during this phase of the log in) to ensure all of the CPM fifos were
drained
properly.  Again, this wasn't exactly the SMC problem, but shifting out
bits
that didn't look proper messed up the host serial interface.  Maybe
during
all of the recent updates to the drivers people "optimized" things not
knowing
their effects.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Serial port text corruption

[Joakim Tjernlund]

> On May 18, 2004, at 6:03 AM, Joakim Tjernlund wrote:
>
> > This is very confusing and I would fix it but I don't know where to
> > start.
> > Any guesses as to where the problem is? Kernel serial layer, the 8xx
> > uart.c driver,
> > the user space login program or somewhere else?
>
> Are you using a USB to serial adapter on your laptop?

Nope, this is a plain RS232 port with TeraTerm on top. This
has also happened on different laptops.

> On the other hand, many. many years ago when the 8xx uart driver was
> written we added some delays during mode changes (which happens
> during this phase of the log in) to ensure all of the CPM fifos were
> drained
> properly.  Again, this wasn't exactly the SMC problem, but shifting out
> bits
> that didn't look proper messed up the host serial interface.  Maybe
> during
> all of the recent updates to the drivers people "optimized" things not
> knowing
> their effects.

Had a look in the driver and the rs_8xx_ioctl()
calls tty_wait_until_sent(tty, 0) for most things but
rs_8xx_set_termios() calls change_speed without a delay.
Is this the delays you are thinking about?

I am using agetty and I have just read that agetty tries to figure
out parity settings during login and sets the tty accordinly. So
maybe agetty gets confused and changes the parity? Would
that affect the Password line but not the previous line where the username
is entered?

Relevant line of my inittab is:
  con:2345:respawn:/sbin/getty -L console 115200 vt100

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Serial port text corruption

[Joakim Tjernlund]

> I would look at the SMC1 buffering and handling of caches (either snooping, not caching the buffers, or flushing before
> transmitting).

The 8xx uses its internal memory as buffers and this is uncached memory, so this should not be a problem.

>
> Another possiblility is sending data that is stored on the stack in a subroutine which subsequently returns before the
> data is actually transmitted -- when you are lucky, the data hasn't changed when the Tx occurs, when you are unlucky, a
> call sequence has overwritten the string on the stack.  Since this is (presumably) standard linux and that sort of a
> problem would have been found and fixed loooong ago in the linux core code, I would concentrate on your low level code.

OK, I will have a look at this.

>
> Just to eliminate variables, you should hook a logic analyzer or 'scope to the board's Tx line and verify the baud rate
> hasn't changed when you get the garbage characters.  If the baud rate has changed, it will be a clocking problem.

I will see what I can do.

 Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Serial port text corruption

[Joakim Tjernlund]

> I am using agetty and I have just read that agetty tries to figure
> out parity settings during login and sets the tty accordinly. So
> maybe agetty gets confused and changes the parity? Would
> that affect the Password line but not the previous line where the username
> is entered?
>
> Relevant line of my inittab is:
>   con:2345:respawn:/sbin/getty -L console 115200 vt100

After some research and testing, I have found that agetty enables
parity checking if a character with the msb set while entering the
username. The parity setting(even or odd, based on the number of one's in the
char) becomes active during the password phase and that messes up the display.

I don't think that such a character was entered in my case, but perhaps a
random character was generated when connecting the cable?

Agettys auto parity algorithm is not very suited for todays keyboards. There
are plenty of computers with national characters on their keyboards. A user
could easily enter a national character and end up with garbled display.

Any ideas for a replacement getty?

 Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial port text corruption

[Dan Malek]

On May 19, 2004, at 11:49 AM, Joakim Tjernlund wrote:

> After some research and testing, I have found that agetty enables
> parity checking....

Interesting.

> I don't think that such a character was entered in my case, but
> perhaps a
> random character was generated when connecting the cable?

Well, you are running 115200, what happens if you use some reasonable
baud rate like 38400 or less?

> Any ideas for a replacement getty?

I use mgetty.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial port text corruption

[Mark Chambers]

> > I am using agetty and I have just read that agetty tries to figure
> > out parity settings during login and sets the tty accordinly...
>
> Any ideas for a replacement getty?
>

My inittab (from ELDK) has 'mingetty' which has never given me any problem.
It apparently just keeps the current baud and parity settings.

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Serial port text corruption

[Joakim Tjernlund]

> > I don't think that such a character was entered in my case, but
> > perhaps a
> > random character was generated when connecting the cable?
>
> Well, you are running 115200, what happens if you use some reasonable
> baud rate like 38400 or less?

The problem is very hard to reproduce at will. Trying to veriy if a lower
baud rate solves it is even harder. I will fix the getty problem and se
if it goes away.

> > Any ideas for a replacement getty?
>
> I use mgetty.

OK, thanks

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/