Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use

["Bruno Prémont" <bonbons@linux-vserver.org>]

Hi Greg,

Were you able to reproduce this with a FTDI usbserial device?


I just had a short look with 2.6.31-rc6, it crashes harder... once
kernel did panic with general protection fault after reporting
  tty_port_close_start: count=-1
The second time id started output of an Oops but only half of the first
line ever showed up on screen (Intel KMS).

Note: this was with just usbserial.ko and ftdi_sio.ko rebuilt with
CONFIG_DEBUG_INFO=y in the hope to find out what did access a bad
pointer. (make CONFIG_DEBUG_INFO=y drivers/usb/serial/$module.ko)

Will retry now with a fresh compile with CONFIG_DEBUG_INFO enabled for
whole kernel and see if I can get better information, eventually
switching to vesa framebuffer in case the partial output happens again.

This pretty much looks like unbalanced ref-count...

Thanks,
Bruno

On Mon, 10 August 2009 Greg KH <gregkh@suse.de> wrote:
> > > I have not tried yet with a different USB serial device but will
> > > do so soon to see if I can reproduce it there. (the other
> > > USBSerial device I have is: 067b:2303 Prolific Technology, Inc.
> > > PL2303 Serial Port)
> > 
> > I can't reproduce with this one.
> > 
> > Similar setup, but instead of SheevaPlug (with it's kernel started
> > with console=ttyS0,115200 + agetty run by init) I just started
> > agetty (same parameters) on a x86 box with uart serial port (e.g.
> > that x86 kernel does not have console kernel parameter) and
> > connected that one via NullModem cable to the Prolific USBSerial
> > converter.
> > 
> > In this case, no matter how often I pull the USBSerial converter
> > there is no Oops.
> > 
> > So it must be something that FTDI driver does differently from e.g.
> > Prolific one.
> 
> Ok, thanks, I'll dig through my big box of usb devices to try to find
> a ftdi device, I was testing this out on a pl2303 device, which is
> why I couldn't reproduce it it seems.