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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090810203501.4d57aa5b@neptune.home>
Date:	Mon, 10 Aug 2009 20:35:01 +0200
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while
 in use

On Mon, 10 August 2009 Greg KH <greg@...ah.com> wrote:
> On Mon, Aug 10, 2009 at 07:18:22PM +0200, Bruno Prémont wrote:
> > On Mon, 10 August 2009 Greg KH <greg@...ah.com> wrote:
> > > On Mon, Aug 10, 2009 at 11:18:29AM -0400, Alan Stern wrote:
> > > > On Sat, 8 Aug 2009, Bruno Prémont wrote:
> > > > 
> > > > > I tried bisecting this but bisect did end up on a fully
> > > > > unrelated commit (which is not even being compiled into my
> > > > > kernel). Possibly the failed bisect could be related to
> > > > > mis-classified kernel panic/hang while pulling the USB cable
> > > > > (there were two such panics for the whole iteration)?
> > > > > 
> > > > > There are quite a few patches touching tty, ttyUSB and friends
> > > > > between rc4 and now so pretty hard to guess on the correct
> > > > > one.
> > > > > 
> > > > > The oops always happens when I disconnect the USB serial
> > > > > console (here the one built into Marvell SheevaPlug) while
> > > > > having minicom connected to it.
> > > > > During the bisection for the last few bad iterations minicom
> > > > > got killed (segfault), the bad ones on the iteration left a
> > > > > minicom zombie in 'D' state.
> 
> Ok, a few questions.
> 
> Are you pulling the device out when you have a console attached to the
> device, or just a "normal" minicom connection with it?  I can't seem
> to duplicate this here at the moment for some reason :(
> 
> thanks,
> 
> greg k-h
> 

The SheevaPlug has a getty running on ttyS0 (agetty 115200 ttyS0 vt100).
That ttyS0 is exported via the FTDI USB to Serial+JTag converter.

On the laptop side (where the kernel Oopses) I see /dev/ttyUSB0 (which
I instruct minicom to use via symlink to
/dev/serial/by-id/usb-FTDI_SheevaPlug_JTAGKey_FT2232D_B_FTS55QK6-if01-port0
 -- minicom is limited to 63byte length for path to tty device)

I run minicom with the following parameters:
  minicom -o -c on sheeva

/etc/minicom/minirc.sheeva
  pu port             /etc/minicom/tty-sheeva
  pu rtscts           No

That is 115200 8N1, with neither hardware nor software flow control.

I'm pulling the USB cable while minicom is running and agetty on the
other side is waiting for password input. (pulling the USB cable is
too easy - and same effect is obtained when pulling power from the
SheevaPlug)


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)

thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/