kernel lockup due to bad baud rate data

kernel lockup due to bad baud rate data

[johnlinn]

I'm testing with 2.6.39 and our serial driver that's unique to our ARM platform.  I suspect we have a problem with our serial driver but wanted to see if anyone has seen any similar behavior.

When running with 2 serial ports, any input from a serial terminal running at the wrong baud rate (9600 instead of 115.2K) on a 2nd shell (not the console shell) causes the kernel to lock up. It doesn't crash, I'm still trying to understand what it's doing.  I can no longer ping the board as the network was working prior.

I just wanted to make sure there's not any known tty issues related to this.

Thanks,
John

Re: kernel lockup due to bad baud rate data

[Greg KH]

On Thu, Jun 16, 2011 at 12:09:12AM +0000, johnlinn@comcast.net wrote:
> I'm testing with 2.6.39 and our serial driver that's unique to our ARM
> platform.  I suspect we have a problem with our serial driver but
> wanted to see if anyone has seen any similar behavior.
> 
> When running with 2 serial ports, any input from a serial terminal
> running at the wrong baud rate (9600 instead of 115.2K) on a 2nd shell
> (not the console shell) causes the kernel to lock up. It doesn't
> crash, I'm still trying to understand what it's doing.  I can no
> longer ping the board as the network was working prior.
> 
> I just wanted to make sure there's not any known tty issues related to
> this.

There are some odd issues with stuff in this area, care to try 3.0-rc3
and see if the problem is there as well or not?

thanks,

greg k-h

Re: kernel lockup due to bad baud rate data

[Alan Cox]

On Wed, 15 Jun 2011 17:21:30 -0700
Greg KH <greg@kroah.com> wrote:

> On Thu, Jun 16, 2011 at 12:09:12AM +0000, johnlinn@comcast.net wrote:
> > I'm testing with 2.6.39 and our serial driver that's unique to our ARM
> > platform.  I suspect we have a problem with our serial driver but
> > wanted to see if anyone has seen any similar behavior.
> > 
> > When running with 2 serial ports, any input from a serial terminal
> > running at the wrong baud rate (9600 instead of 115.2K) on a 2nd shell
> > (not the console shell) causes the kernel to lock up. It doesn't
> > crash, I'm still trying to understand what it's doing.  I can no
> > longer ping the board as the network was working prior.
> > 
> > I just wanted to make sure there's not any known tty issues related to
> > this.
> 
> There are some odd issues with stuff in this area, care to try 3.0-rc3
> and see if the problem is there as well or not?

If its driver specific as this seems I'd take a guess on the driver for
the hardware not properly handling framing errors or break so you get an
irq storm or some other failure from the framing error.

Re: kernel lockup due to bad baud rate data

[johnlinn]

> On Wed, 15 Jun 2011 17:21:30 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Thu, Jun 16, 2011 at 12:09:12AM +0000, johnlinn@comcast.net wrote:
> > > I'm testing with 2.6.39 and our serial driver that's unique to our ARM
> > > platform.  I suspect we have a problem with our serial driver but
> > > wanted to see if anyone has seen any similar behavior.
> > > 
> > > When running with 2 serial ports, any input from a serial terminal
> > > running at the wrong baud rate (9600 instead of 115.2K) on a 2nd shell
> > > (not the console shell) causes the kernel to lock up. It doesn't
> > > crash, I'm still trying to understand what it's doing.  I can no
> > > longer ping the board as the network was working prior.
> > > 
> > > I just wanted to make sure there's not any known tty issues related to
> > > this.
> > 
> > There are some odd issues with stuff in this area, care to try 3.0-rc3
> > and see if the problem is there as well or not?

I'll give it a try if I can get some time today. Thanks for input Greg.

> 
> If its driver specific as this seems I'd take a guess on the driver
> for the hardware not properly handling framing errors or break so you get
> an irq storm or some other failure from the framing error.

I was thinking in the same direction as Alan also.  Appreciate the input.

-- John