* 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use @ 2009-08-08 17:47 Bruno Prémont 2009-08-09 14:02 ` Ozan Çağlayan 2009-08-10 15:18 ` Alan Stern 0 siblings, 2 replies; 42+ messages in thread From: Bruno Prémont @ 2009-08-08 17:47 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: linux-kernel, linux-usb, Rafael J. Wysocki 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. Regards, Bruno In case if can be of some use, here is the bisect log: git bisect start # bad: [cf265c2c5df57b0025713791cab06cc685eb3bfe] Revert "Subject: [PATCH V2] drm/i915: Detect lvds channel according to fixed mode line" git bisect bad cf265c2c5df57b0025713791cab06cc685eb3bfe # good: [4be3bd7849165e7efa6b0b35a23d6a3598d97465] Linux 2.6.31-rc4 git bisect good 4be3bd7849165e7efa6b0b35a23d6a3598d97465 # good: [4be3bd7849165e7efa6b0b35a23d6a3598d97465] Linux 2.6.31-rc4 git bisect good 4be3bd7849165e7efa6b0b35a23d6a3598d97465 # bad: [3822a0e38c329a598cb6f5baa16be7504e0db8d9] mmc: orphan subsystem git bisect bad 3822a0e38c329a598cb6f5baa16be7504e0db8d9 # bad: [7d084d96fdf1d791cb171da57efc1ca89d68dd6c] libata: Updates and fixes for pata_at91 driver git bisect bad 7d084d96fdf1d791cb171da57efc1ca89d68dd6c # good: [6a31d4aeab85a02f9a57ca37b935054393daa794] Merge branch 'fixes-for-linus' of git://git.monstr.eu/linux-2.6-microblaze git bisect good 6a31d4aeab85a02f9a57ca37b935054393daa794 # bad: [f1462147f15a954a1a0553390846c6fa3ca742b1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad f1462147f15a954a1a0553390846c6fa3ca742b1 # bad: [d14a7679ae9b7d4eb4b92e81f5039b719fd98c4d] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 git bisect bad d14a7679ae9b7d4eb4b92e81f5039b719fd98c4d # bad: [7adfd5c71693b81e995283805b17aa4a2ee0ecd9] rt2x00: Fix chipset detection for rt2500usb git bisect bad 7adfd5c71693b81e995283805b17aa4a2ee0ecd9 # bad: [48ab3578a65c5168ecaaa3b21292b643b7bcc2d5] rfkill: fix rfkill_set_states() to set the hw state git bisect bad 48ab3578a65c5168ecaaa3b21292b643b7bcc2d5 # bad: [7b80ece41aea0b73283c6df5a8f25d40aa13135d] iwlwifi: only update byte count table during aggregation git bisect bad 7b80ece41aea0b73283c6df5a8f25d40aa13135d # bad: [872ed1902f511a8947021c562f5728a5bf0640b5] iwlwifi: only show active power level via sysfs git bisect bad 872ed1902f511a8947021c562f5728a5bf0640b5 # bad: [513a2396d8e8327aff1ce50bea3fb4f16ff3455b] iwmc3200wifi: fix NULL pointer dereference in iwm_if_free git bisect bad 513a2396d8e8327aff1ce50bea3fb4f16ff3455b [ 1638.060039] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 1638.278185] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 1638.278195] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1638.278204] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 1638.278210] usb 1-2: Manufacturer: FTDI [ 1638.278216] usb 1-2: SerialNumber: FTS55QK6 [ 1638.278444] usb 1-2: configuration #1 chosen from 1 choice [ 1638.760727] usbcore: registered new interface driver usbserial [ 1638.760732] usbserial: USB Serial Driver core [ 1638.772202] USB Serial support registered for FTDI USB Serial Device [ 1638.772318] usb 1-2: Ignoring serial port reserved for JTAG [ 1638.772374] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 1638.772414] usb 1-2: Detected FT2232C [ 1638.772417] usb 1-2: Number of endpoints 2 [ 1638.772420] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 1638.772423] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 1638.772426] usb 1-2: Setting MaxPacketSize 64 [ 1638.774239] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 1638.774268] usbcore: registered new interface driver ftdi_sio [ 1638.774271] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 1761.750059] usb 1-2: USB disconnect, address 2 [ 1761.750475] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 1761.750505] ftdi_sio 1-2:1.1: device disconnected [ 1761.751734] tty_port_close_start: count = -1 [ 1769.392487] BUG: unable to handle kernel paging request at 61762056 [ 1769.392742] IP: [<de765d28>] serial_do_free+0x38/0x80 [usbserial] [ 1769.392979] *pde = 00000000 [ 1769.393101] Oops: 0000 [#1] [ 1769.393223] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 1769.393468] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec nsc_ircc ac97_bus snd_pcm snd_timer i2c_i801 pcspkr irda snd snd_page_alloc ehci_hcd uhci_hcd crc_ccitt usbcore [ 1769.394814] [ 1769.394890] Pid: 2588, comm: minicom Tainted: G M (2.6.31-rc5 #2) TravelMate 660 [ 1769.395144] EIP: 0060:[<de765d28>] EFLAGS: 00010246 CPU: 0 [ 1769.395344] EIP is at serial_do_free+0x38/0x80 [usbserial] [ 1769.395519] EAX: 6176203a EBX: daad3000 ECX: de765d70 EDX: daad3a00 [ 1769.395747] ESI: daad3038 EDI: 00000000 EBP: dc397e24 ESP: dc397e18 [ 1769.395945] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 1769.396135] Process minicom (pid: 2588, ti=dc397000 task=dd8e46a0 task.ti=dc397000) [ 1769.396374] Stack: [ 1769.396458] daad3a00 dc37e400 00000000 dc397e4c de765dd6 00000000 dc397e4c c115cf85 [ 1769.396835] <0> dc37e4a0 dc383d80 dc37e400 00000000 00000000 dc397edc c115f0c0 00000001 [ 1769.397256] <0> 00000002 c15a8380 dc383d80 00000000 00000000 c18541c0 40000000 00000000 [ 1769.397689] Call Trace: [ 1769.397799] [<de765dd6>] ? serial_close+0x66/0xa0 [usbserial] [ 1769.397992] [<c115cf85>] ? tty_fasync+0x55/0xe0 [ 1769.398163] [<c115f0c0>] ? tty_release_dev+0x130/0x490 [ 1769.398339] [<c1056b82>] ? put_page+0x42/0x120 [ 1769.398507] [<c10895b6>] ? mntput_no_expire+0x16/0x60 [ 1769.398675] [<c115f42a>] ? tty_release+0xa/0x10 [ 1769.398844] [<c1075d2c>] ? __fput+0xdc/0x1d0 [ 1769.398987] [<c1075e3f>] ? fput+0x1f/0x30 [ 1769.399142] [<c1072d9e>] ? filp_close+0x3e/0x70 [ 1769.399297] [<c1024dd2>] ? put_files_struct+0xa2/0xc0 [ 1769.399481] [<c1024e0c>] ? exit_files+0x1c/0x20 [ 1769.399633] [<c1026169>] ? do_exit+0xb9/0x630 [ 1769.399798] [<c103aab8>] ? __put_cred+0x18/0x20 [ 1769.399950] [<c102670d>] ? do_group_exit+0x2d/0x80 [ 1769.400145] [<c1026773>] ? sys_exit_group+0x13/0x20 [ 1769.400309] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 1769.400488] Code: 24 04 89 7c 24 08 80 b8 b6 00 00 00 00 74 14 8b 1c 24 8b 74 24 04 8b 7c 24 08 89 ec 5d c3 90 8d 74 26 00 8b 18 8b 43 04 8d 73 38 <8b> 78 1c 8d 82 bc 00 00 00 e8 1a c1 a4 e2 89 f0 e8 33 1d b5 e2 [ 1769.402352] EIP: [<de765d28>] serial_do_free+0x38/0x80 [usbserial] SS:ESP 0068:dc397e18 [ 1769.402649] CR2: 0000000061762056 [ 1769.402775] ---[ end trace e6175462c2b3a1ba ]--- [ 1769.402923] Fixing recursive fault but reboot is needed! ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-08 17:47 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use Bruno Prémont @ 2009-08-09 14:02 ` Ozan Çağlayan 2009-08-09 15:00 ` Alan Stern 2009-08-10 15:18 ` Alan Stern 1 sibling, 1 reply; 42+ messages in thread From: Ozan Çağlayan @ 2009-08-09 14:02 UTC (permalink / raw) To: Bruno Prémont Cc: Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki 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. > > Regards, > Bruno > > That may be a related/possible fix for that, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b68f2fb9e73f46037fbeca5fbd4ae8a7ddd8ef6b ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-09 14:02 ` Ozan Çağlayan @ 2009-08-09 15:00 ` Alan Stern 0 siblings, 0 replies; 42+ messages in thread From: Alan Stern @ 2009-08-09 15:00 UTC (permalink / raw) To: Ozan Çağlayan Cc: Bruno Prémont, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Sun, 9 Aug 2009, [UTF-8] Ozan ÇaÄŸlayan wrote: > 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. > > > > Regards, > > Bruno > > > > > > That may be a related/possible fix for that, > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b68f2fb9e73f46037fbeca5fbd4ae8a7ddd8ef6b That patch is already present in 2.6.31-rc5. The problem here may be related to the fact that the serial port is being used as a console. For non-console ports this doesn't happen. Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-08 17:47 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use Bruno Prémont 2009-08-09 14:02 ` Ozan Çağlayan @ 2009-08-10 15:18 ` Alan Stern 2009-08-10 15:44 ` Greg KH 1 sibling, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-10 15:18 UTC (permalink / raw) To: Bruno Prémont Cc: Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Sat, 8 Aug 2009, Bruno [UTF-8] 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. By the way, there are quite a few serial patches in Greg KH's tree. At least one of them looks like it is meant to fix exactly this problem. Can you try running with http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch applied to the standard 2.6.31-rc5 source? Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 15:18 ` Alan Stern @ 2009-08-10 15:44 ` Greg KH 2009-08-10 17:18 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Greg KH @ 2009-08-10 15:44 UTC (permalink / raw) To: Alan Stern Cc: Bruno Prémont, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, Aug 10, 2009 at 11:18:29AM -0400, Alan Stern wrote: > On Sat, 8 Aug 2009, Bruno [UTF-8] 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. > > By the way, there are quite a few serial patches in Greg KH's tree. At > least one of them looks like it is meant to fix exactly this problem. > > Can you try running with > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch > > applied to the standard 2.6.31-rc5 source? Yes, that would be good to find out, so we can pick the right patch to send in now. thanks, greg k-h ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 15:44 ` Greg KH @ 2009-08-10 17:18 ` Bruno Prémont 2009-08-10 18:13 ` Greg KH 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-10 17:18 UTC (permalink / raw) To: Greg KH Cc: Alan Stern, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, 10 August 2009 Greg KH <greg@kroah.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. > > > > By the way, there are quite a few serial patches in Greg KH's > > tree. At least one of them looks like it is meant to fix exactly > > this problem. > > > > Can you try running with > > > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch > > > > applied to the standard 2.6.31-rc5 source? > > Yes, that would be good to find out, so we can pick the right patch to > send in now. > > thanks, > > greg k-h > Unfortunately none of the patches in gregkh-all-2.6.31-rc5.patch do fix it. With these patches minicom segfaults instead of remaining as a zombie (but that also happened during my bisect sequence. In this case it looks rather like some use-after-free as kernel tries to access some memory at an address pretty far away from NULL. thanks, Bruno Here the kernel log for this attempt: [ 78.730035] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 78.948188] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 78.948198] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 78.948206] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 78.948213] usb 1-2: Manufacturer: FTDI [ 78.948219] usb 1-2: SerialNumber: FTS55QK6 [ 78.948452] usb 1-2: configuration #1 chosen from 1 choice [ 79.053847] usbcore: registered new interface driver usbserial [ 79.053851] usbserial: USB Serial Driver core [ 79.072653] USB Serial support registered for FTDI USB Serial Device [ 79.072865] usb 1-2: Ignoring serial port reserved for JTAG [ 79.072968] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 79.073030] usb 1-2: Detected FT2232C [ 79.073036] usb 1-2: Number of endpoints 2 [ 79.073042] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 79.073049] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 79.073055] usb 1-2: Setting MaxPacketSize 64 [ 79.074355] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 79.074395] usbcore: registered new interface driver ftdi_sio [ 79.074401] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 199.731548] loop0 used greatest stack depth: 1104 bytes left [ 213.040179] usb 1-2: USB disconnect, address 2 [ 213.040577] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 213.040607] ftdi_sio 1-2:1.1: device disconnected [ 213.040893] tty_port_close_start: count = -1 [ 213.040914] BUG: unable to handle kernel paging request at de1ab42c [ 213.041166] IP: [<c1165026>] tty_port_close_start+0x96/0x170 [ 213.046870] *pde = 00000000 [ 213.052897] Oops: 0002 [#1] [ 213.058817] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 213.064956] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer pcspkr snd ehci_hcd i2c_i801 snd_page_alloc uhci_hcd nsc_ircc usbcore irda crc_ccitt [ 213.078798] [ 213.085472] Pid: 2119, comm: minicom Tainted: G M (2.6.31-rc5-gregkh #3) TravelMate 660 [ 213.092424] EIP: 0060:[<c1165026>] EFLAGS: 00010096 CPU: 0 [ 213.099402] EIP is at tty_port_close_start+0x96/0x170 [ 213.106429] EAX: de1ab42c EBX: dd1ab404 ECX: ffffffff EDX: c13c6564 [ 213.113587] ESI: 00000286 EDI: daafc000 EBP: daaead8c ESP: daaead74 [ 213.120747] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 213.127925] Process minicom (pid: 2119, ti=daaea000 task=dd952120 task.ti=daaea000) [ 213.135206] Stack: [ 213.142493] c1374da0 ffffffff c1084cbd dd1ab400 dd1ab404 daafc000 daaeadb4 dfae8a36 [ 213.142869] <0> 00000000 daaeadb4 c115cb85 daafc0a0 db067e80 daafc000 00000000 00000000 [ 213.150558] <0> daaeae44 c115ed00 daaeaef4 4c99875a dd9d4a80 db067e80 00000000 00000000 [ 213.165774] Call Trace: [ 213.173463] [<c1084cbd>] ? dput+0x8d/0x120 [ 213.181179] [<dfae8a36>] ? serial_close+0x36/0x90 [usbserial] [ 213.188945] [<c115cb85>] ? tty_fasync+0x55/0xe0 [ 213.196693] [<c115ed00>] ? tty_release_dev+0x130/0x490 [ 213.204434] [<c12b6d8e>] ? mutex_lock+0xe/0x20 [ 213.212142] [<dfae8dc9>] ? usb_serial_put+0x29/0x30 [usbserial] [ 213.219890] [<dfae9060>] ? serial_open+0x70/0x250 [usbserial] [ 213.227741] [<c115f70d>] ? tty_open+0x45d/0x4b0 [ 213.235653] [<c1076fe6>] ? chrdev_open+0x96/0x140 [ 213.243604] [<c1072d7f>] ? __dentry_open+0x9f/0x250 [ 213.251588] [<c1073019>] ? nameidata_to_filp+0x59/0x70 [ 213.259570] [<c1076f50>] ? chrdev_open+0x0/0x140 [ 213.267596] [<c107f2f9>] ? do_filp_open+0x269/0x890 [ 213.275626] [<c10389ec>] ? ktime_get_ts+0x4c/0x50 [ 213.283673] [<c1072b47>] ? do_sys_open+0x57/0x140 [ 213.291762] [<c1026b65>] ? alarm_setitimer+0x35/0x70 [ 213.299872] [<c1072c99>] ? sys_open+0x29/0x40 [ 213.307998] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 213.316146] Code: eb b8 89 44 24 04 c7 04 24 a0 4d 37 c1 e8 3d 10 15 00 c7 43 0c 00 00 00 00 8d b6 00 00 00 00 8d bf 00 00 00 00 8d 83 28 00 00 01 <80> 8b 28 00 00 01 01 80 8f 2c 01 00 00 20 56 9d 0f b6 87 94 00 [ 213.334752] EIP: [<c1165026>] tty_port_close_start+0x96/0x170 SS:ESP 0068:daaead74 [ 213.343661] CR2: 00000000de1ab42c [ 213.352536] ---[ end trace 4e30eef18c7e8fe3 ]--- ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 17:18 ` Bruno Prémont @ 2009-08-10 18:13 ` Greg KH 2009-08-10 18:35 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Greg KH @ 2009-08-10 18:13 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Stern, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, Aug 10, 2009 at 07:18:22PM +0200, Bruno Prémont wrote: > On Mon, 10 August 2009 Greg KH <greg@kroah.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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 18:13 ` Greg KH @ 2009-08-10 18:35 ` Bruno Prémont 2009-08-10 18:51 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-10 18:35 UTC (permalink / raw) To: Greg KH Cc: Alan Stern, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, 10 August 2009 Greg KH <greg@kroah.com> wrote: > On Mon, Aug 10, 2009 at 07:18:22PM +0200, Bruno Prémont wrote: > > On Mon, 10 August 2009 Greg KH <greg@kroah.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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 18:35 ` Bruno Prémont @ 2009-08-10 18:51 ` Bruno Prémont 2009-08-10 19:29 ` Greg KH 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-10 18:51 UTC (permalink / raw) Cc: Greg KH, Alan Stern, Greg Kroah-Hartman, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, 10 August 2009 Bruno Prémont <bonbons@linux-vserver.org> wrote: > On Mon, 10 August 2009 Greg KH <greg@kroah.com> wrote: > > On Mon, Aug 10, 2009 at 07:18:22PM +0200, Bruno Prémont wrote: > > > On Mon, 10 August 2009 Greg KH <greg@kroah.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-_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) 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. thanks, Bruno ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 18:51 ` Bruno Prémont @ 2009-08-10 19:29 ` Greg KH 2009-08-18 17:00 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Greg KH @ 2009-08-10 19:29 UTC (permalink / raw) To: Bruno Prémont Cc: Greg KH, Alan Stern, linux-kernel, linux-usb, Rafael J. Wysocki On Mon, Aug 10, 2009 at 08:51:15PM +0200, Bruno Prémont wrote: > On Mon, 10 August 2009 Bruno Prémont <bonbons@linux-vserver.org> wrote: > > On Mon, 10 August 2009 Greg KH <greg@kroah.com> wrote: > > > On Mon, Aug 10, 2009 at 07:18:22PM +0200, Bruno Prémont wrote: > > > > On Mon, 10 August 2009 Greg KH <greg@kroah.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-_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) > > 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. greg k-h ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-10 19:29 ` Greg KH @ 2009-08-18 17:00 ` Bruno Prémont 2009-08-18 22:36 ` Greg KH 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-18 17:00 UTC (permalink / raw) To: Greg KH; +Cc: Greg KH, Alan Stern, linux-kernel, linux-usb, Rafael J. Wysocki 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-18 17:00 ` Bruno Prémont @ 2009-08-18 22:36 ` Greg KH 2009-08-18 23:16 ` Greg KH 2009-08-19 17:22 ` Bruno Prémont 0 siblings, 2 replies; 42+ messages in thread From: Greg KH @ 2009-08-18 22:36 UTC (permalink / raw) To: Bruno Prémont Cc: Greg KH, Alan Stern, linux-kernel, linux-usb, Rafael J. Wysocki On Tue, Aug 18, 2009 at 07:00:16PM +0200, Bruno Prémont wrote: > Hi Greg, > > Were you able to reproduce this with a FTDI usbserial device? No, I can't find one in my box. I'll go dig in the attic next to try to find on, I knew I had one before... > 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... Yeah, it sounds like it. More info would be great to have if you can get it. thanks, greg k-h ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-18 22:36 ` Greg KH @ 2009-08-18 23:16 ` Greg KH 2009-08-19 17:22 ` Bruno Prémont 1 sibling, 0 replies; 42+ messages in thread From: Greg KH @ 2009-08-18 23:16 UTC (permalink / raw) To: Bruno Prémont Cc: Greg KH, Alan Stern, linux-kernel, linux-usb, Rafael J. Wysocki On Tue, Aug 18, 2009 at 03:36:48PM -0700, Greg KH wrote: > On Tue, Aug 18, 2009 at 07:00:16PM +0200, Bruno Prémont wrote: > > Hi Greg, > > > > Were you able to reproduce this with a FTDI usbserial device? > > No, I can't find one in my box. I'll go dig in the attic next to try to > find on, I knew I had one before... Nope, all I found was mcd_u232 and pl2303 devices, no ftdi ones :( Anyone have a brand name, or a link to one online that I can buy so that I can get one for testing? thanks, greg k-h ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-18 22:36 ` Greg KH 2009-08-18 23:16 ` Greg KH @ 2009-08-19 17:22 ` Bruno Prémont 2009-08-19 18:20 ` Alan Stern 1 sibling, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-19 17:22 UTC (permalink / raw) To: Greg KH; +Cc: Greg KH, Alan Stern, linux-kernel, linux-usb, Rafael J. Wysocki On Tue, 18 August 2009 Greg KH <gregkh@suse.de> wrote: > Yeah, it sounds like it. More info would be great to have if you can > get it. I did try to understand what happens exactly, using backtrace from kernel compiled with debug info and running objdump on usbserial.ko. Trace used: [ 593.681350] BUG: unable to handle kernel paging request at 00700128 [ 593.681604] IP: [<dea40d28>] serial_do_free+0x38/0x80 [usbserial] [ 593.681842] *pde = 00000000 [ 593.681964] Oops: 0000 [#1] [ 593.682085] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 593.682330] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc uhci_hcd ehci_hcd irda snd_pcm snd_timer usbcore snd snd_page_alloc pcspkr i2c_i801 crc_ccitt [ 593.683672] [ 593.683747] Pid: 2209, comm: minicom Tainted: G M (2.6.31-rc6 #1) TravelMate 660 [ 593.684001] EIP: 0060:[<dea40d28>] EFLAGS: 00010246 CPU: 0 [ 593.684200] EIP is at serial_do_free+0x38/0x80 [usbserial] [ 593.684375] EAX: 0070010c EBX: dd1b2e00 ECX: dea40d70 EDX: dd1b2200 [ 593.684590] ESI: dd1b2e38 EDI: 00000000 EBP: da050e24 ESP: da050e18 [ 593.684787] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 593.684976] Process minicom (pid: 2209, ti=da050000 task=dd9addd0 task.ti=da050000) [ 593.685214] Stack: [ 593.685298] dd1b2200 dd12fc00 00000000 da050e4c dea40dd6 00000000 da050e4c c115d1a5 [ 593.685673] <0> dd12fca0 dd804b00 dd12fc00 00000000 00000000 da050edc c115f2e0 00000001 [ 593.686091] <0> 00000002 c17b1200 dd804b00 00000000 00000000 c1850740 40000000 00000000 [ 593.686520] Call Trace: [ 593.686631] [<dea40dd6>] ? serial_close+0x66/0xa0 [usbserial] [ 593.686824] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 593.686994] [<c115f2e0>] ? tty_release_dev+0x130/0x490 [ 593.687170] [<c1056d72>] ? put_page+0x42/0x120 [ 593.687339] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 593.687505] [<c115f64a>] ? tty_release+0xa/0x10 [ 593.687673] [<c1075f1c>] ? __fput+0xdc/0x1d0 [ 593.687817] [<c107602f>] ? fput+0x1f/0x30 [ 593.687970] [<c1072f8e>] ? filp_close+0x3e/0x70 [ 593.688126] [<c1024fa2>] ? put_files_struct+0xa2/0xc0 [ 593.688310] [<c1024fdc>] ? exit_files+0x1c/0x20 [ 593.688462] [<c1026339>] ? do_exit+0xb9/0x630 [ 593.688628] [<c103acd8>] ? __put_cred+0x18/0x20 [ 593.688780] [<c10268dd>] ? do_group_exit+0x2d/0x80 [ 593.688957] [<c1026943>] ? sys_exit_group+0x13/0x20 [ 593.689119] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 593.689298] Code: 24 04 89 7c 24 08 80 b8 b6 00 00 00 00 74 14 8b 1c 24 8b 74 24 04 8b 7c 24 08 89 ec 5d c3 90 8d 74 26 00 8b 18 8b 43 04 8d 73 38 <8b> 78 1c 8d 82 bc 00 00 00 e8 fa 13 77 e2 89 f0 e8 33 70 87 e2 [ 593.691175] EIP: [<dea40d28>] serial_do_free+0x38/0x80 [usbserial] SS:ESP 0068:da050e18 [ 593.691473] CR2: 0000000000700128 [ 593.691600] ---[ end trace bf5aabaeba706ceb ]--- Objdump (objdump -l -D usbserial.ko) result for serial_do_free: 00000cf0 <serial_do_free>: serial_do_free(): /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:322 cf0: 55 push %ebp cf1: 89 c2 mov %eax,%edx cf3: 89 e5 mov %esp,%ebp cf5: 83 ec 0c sub $0xc,%esp cf8: 89 1c 24 mov %ebx,(%esp) cfb: 89 74 24 04 mov %esi,0x4(%esp) cff: 89 7c 24 08 mov %edi,0x8(%esp) /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:328 d03: 80 b8 b6 00 00 00 00 cmpb $0x0,0xb6(%eax) d0a: 74 14 je d20 <serial_do_free+0x30> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:342 d0c: 8b 1c 24 mov (%esp),%ebx d0f: 8b 74 24 04 mov 0x4(%esp),%esi d13: 8b 7c 24 08 mov 0x8(%esp),%edi d17: 89 ec mov %ebp,%esp d19: 5d pop %ebp d1a: c3 ret d1b: 90 nop d1c: 8d 74 26 00 lea 0x0(%esi),%esi /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:331 d20: 8b 18 mov (%eax),%ebx /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:332 d22: 8b 43 04 mov 0x4(%ebx),%eax /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:335 d25: 8d 73 38 lea 0x38(%ebx),%esi /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:332 d28: 8b 78 1c mov 0x1c(%eax),%edi /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:333 d2b: 8d 82 bc 00 00 00 lea 0xbc(%edx),%eax d31: e8 fc ff ff ff call d32 <serial_do_free+0x42> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:335 d36: 89 f0 mov %esi,%eax d38: e8 fc ff ff ff call d39 <serial_do_free+0x49> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:336 d3d: f6 43 0c 01 testb $0x1,0xc(%ebx) d41: 74 1d je d60 <serial_do_free+0x70> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:338 d43: 89 f0 mov %esi,%eax d45: e8 fc ff ff ff call d46 <serial_do_free+0x56> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:339 d4a: 89 d8 mov %ebx,%eax d4c: e8 fc ff ff ff call d4d <serial_do_free+0x5d> /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:341 d51: 89 f8 mov %edi,%eax d53: e8 fc ff ff ff call d54 <serial_do_free+0x64> d58: eb b2 jmp d0c <serial_do_free+0x1c> d5a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:337 d60: 8b 43 08 mov 0x8(%ebx),%eax d63: e8 fc ff ff ff call d64 <serial_do_free+0x74> d68: eb d9 jmp d43 <serial_do_free+0x53> d6a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi >From what I understand it's serial->type which points to 0x00700128, which is inside of some freed memory. d22: 8b 43 04 mov 0x4(%ebx),%eax copy & serial (EBX)->type to EAX d28: 8b 78 1c mov 0x1c(%eax),%edi copy type (EAX)->driver.owner to EDI Am I reading this disassembled code correctly? Verifying by adding a few printk()'s inside serial_do_free() confirms my understanding of the objdump and also tells me that after unplug serial_do_free() is called twice (with different addresses for port->serial->type)! The first one (right after unplug) survives, the second one (when exiting minicom) crashes. Extract from the logs with my printk()'s [ 266.290632] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 266.290938] ftdi_sio 2-2:1.1: device disconnected [ 266.292378] tty_port_close_start: count = -1 [ 266.292535] serial_do_free(port @da0d9000) [ 266.292692] serial @da3e9840 [ 266.292791] type @deb45660 /* exit minicom */ [ 290.728196] serial_do_free(port @da0d9000) [ 290.728341] serial @da0d9200 [ 290.728461] type @3a6e6967 [ 290.728591] BUG: unable to handle kernel paging request at 3a6e6983 [ 290.728823] IP: [<deb02d5d>] serial_do_free+0x6d/0xd0 [usbserial] [ 290.729059] *pde = 00000000 [ 290.729182] Oops: 0000 [#1] [ 290.729303] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 290.729548] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd snd_timer nsc_ircc usbcore pcspkr irda snd snd_page_alloc i2c_i801 crc_ccitt [ 290.730912] [ 290.730987] Pid: 2206, comm: minicom Tainted: G M (2.6.31-rc6 #1) TravelMate 660 [ 290.731242] EIP: 0060:[<deb02d5d>] EFLAGS: 00010282 CPU: 0 [ 290.731441] EIP is at serial_do_free+0x6d/0xd0 [usbserial] [ 290.731615] EAX: 3a6e6967 EBX: da0d9000 ECX: ffffffff EDX: c13c6584 [ 290.731829] ESI: da0d9200 EDI: 00000000 EBP: d8dc9e24 ESP: d8dc9e10 [ 290.732027] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 290.732218] Process minicom (pid: 2206, ti=d8dc9000 task=dd8e5090 task.ti=d8dc9000) Printk's were added: if (port->console) return; /* here */ serial = serial->port; owner = serial->type->driver.owner /* crash here */ Is it useful to check calls to serial_do_free() for my pl2303 usb2serial converter? (e.g. to compare behavior from both of them) Thanks, Bruno ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 17:22 ` Bruno Prémont @ 2009-08-19 18:20 ` Alan Stern 2009-08-19 20:15 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-19 18:20 UTC (permalink / raw) To: Bruno Prémont Cc: Greg KH, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 19 Aug 2009, Bruno [UTF-8] Prémont wrote: > I did try to understand what happens exactly, using backtrace from > kernel compiled with debug info and running objdump on usbserial.ko. > Verifying by adding a few printk()'s inside serial_do_free() confirms my > understanding of the objdump and also tells me that after unplug > serial_do_free() is called twice (with different addresses for port->serial->type)! In fact, with different values for port->serial. Probably because port was deallocated before the second call occurred. > The first one (right after unplug) survives, the second one (when exiting > minicom) crashes. > > Extract from the logs with my printk()'s > [ 266.290632] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 > [ 266.290938] ftdi_sio 2-2:1.1: device disconnected > [ 266.292378] tty_port_close_start: count = -1 > [ 266.292535] serial_do_free(port @da0d9000) > [ 266.292692] serial @da3e9840 > [ 266.292791] type @deb45660 > /* exit minicom */ > [ 290.728196] serial_do_free(port @da0d9000) > [ 290.728341] serial @da0d9200 > [ 290.728461] type @3a6e6967 > [ 290.728591] BUG: unable to handle kernel paging request at 3a6e6983 > [ 290.728823] IP: [<deb02d5d>] serial_do_free+0x6d/0xd0 [usbserial] > Printk's were added: > > if (port->console) > return; > /* here */ > serial = serial->port; > owner = serial->type->driver.owner /* crash here */ > > Is it useful to check calls to serial_do_free() for my pl2303 > usb2serial converter? (e.g. to compare behavior from both of them) You could try; it wouldn't hurt. More useful would be to add some debugging messages to destroy_serial(). There should not be any calls to serial_do_free() after destroy_serial() runs. Also add some messages to the places that call usb_serial_put() and usb_serial_get_by_index(). Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 18:20 ` Alan Stern @ 2009-08-19 20:15 ` Bruno Prémont 2009-08-19 21:01 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-19 20:15 UTC (permalink / raw) To: Alan Stern Cc: Greg KH, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 19 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > On Wed, 19 Aug 2009, Bruno Prémont wrote: > > I did try to understand what happens exactly, using backtrace from > > kernel compiled with debug info and running objdump on usbserial.ko. > > > Verifying by adding a few printk()'s inside serial_do_free() > > confirms my understanding of the objdump and also tells me that > > after unplug serial_do_free() is called twice (with different > > addresses for port->serial->type)! > > In fact, with different values for port->serial. Probably because > port was deallocated before the second call occurred. > > > The first one (right after unplug) survives, the second one (when > > exiting minicom) crashes. > > > > Extract from the logs with my printk()'s > > [ 266.290632] ftdi_sio ttyUSB0: FTDI USB Serial Device converter > > now disconnected from ttyUSB0 [ 266.290938] ftdi_sio 2-2:1.1: > > device disconnected [ 266.292378] tty_port_close_start: count = -1 > > [ 266.292535] serial_do_free(port @da0d9000) > > [ 266.292692] serial @da3e9840 > > [ 266.292791] type @deb45660 > > /* exit minicom */ > > [ 290.728196] serial_do_free(port @da0d9000) > > [ 290.728341] serial @da0d9200 > > [ 290.728461] type @3a6e6967 > > [ 290.728591] BUG: unable to handle kernel paging request at > > 3a6e6983 [ 290.728823] IP: [<deb02d5d>] serial_do_free+0x6d/0xd0 > > [usbserial] > > > Printk's were added: > > > > if (port->console) > > return; > > /* here */ > > serial = serial->port; > > owner = serial->type->driver.owner /* crash here */ > > > > Is it useful to check calls to serial_do_free() for my pl2303 > > usb2serial converter? (e.g. to compare behavior from both of them) > > You could try; it wouldn't hurt. Huh that caused me a NULL port->serial on second call to serial_do_free() with the pl2302... weird! Just run minicom -o -c on server (with no getty listening on the other side, a good old legacy uart of x86 box). After more tries with pl2302 it seems possible to reproduce, but it is harder. For now it's rather the second attempt that is eventually successful as getting an Oops, though each time with NULL pointer dereference instead of bad pointer for serial->type. > More useful would be to add some debugging messages to > destroy_serial(). There should not be any calls to serial_do_free() > after destroy_serial() runs. > > Also add some messages to the places that call usb_serial_put() and > usb_serial_get_by_index(). I've added WARN_ON()s in usb_serial_put() and usb_serial_get_by_index() in order to have information on who called us (easier than searching around and adding lots of printk()s and output is also more verbose :) Below, my changes to usb-serial.c and dmesg extracts for crash cases with pl2302 and ftdi_sio. You have guessed right, there are calls to serial_do_free() after destroy_serial() in the crash cases. destroy_serial when disconnecting device and final serial_do_free() when exiting minicom. These are the changes I made to 2.6.31-rc6 to get debugging output: diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c index 99188c9..7859e44 100644 --- a/drivers/usb/serial/usb-serial.c +++ b/drivers/usb/serial/usb-serial.c @@ -74,6 +74,8 @@ struct usb_serial *usb_serial_get_by_index(unsigned index) mutex_lock(&table_lock); serial = serial_table[index]; + printk("usb_serial_get_by_index(index %d): @%p\n", index, serial); + WARN_ON(true); if (serial) kref_get(&serial->kref); @@ -135,7 +137,9 @@ static void destroy_serial(struct kref *kref) struct usb_serial_port *port; int i; + printk("destroy_serial(kref @%p)\n", kref); serial = to_usb_serial(kref); + printk(" serial @%p\n", serial); dbg("%s - %s", __func__, serial->type->description); @@ -171,6 +175,8 @@ static void destroy_serial(struct kref *kref) void usb_serial_put(struct usb_serial *serial) { + printk("usb_serial_put(serial @%p)\n", serial); + WARN_ON(true); mutex_lock(&table_lock); kref_put(&serial->kref, destroy_serial); mutex_unlock(&table_lock); @@ -328,6 +334,10 @@ static void serial_do_free(struct usb_serial_port *port) if (port->console) return; + printk(KERN_DEBUG "serial_do_free(port @%p)\n", port); + printk(KERN_DEBUG " serial @%p\n", port ? port->serial : NULL); + printk(KERN_DEBUG " type @%p\n", port && port->serial ? port->serial->type : NULL); + serial = port->serial; owner = serial->type->driver.owner; put_device(&port->dev); dmesg extract for pl2302 attempt [ 79.230040] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 79.396191] usb 2-1: New USB device found, idVendor=067b, idProduct=2303 [ 79.396201] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 79.396209] usb 2-1: Product: USB-Serial Controller [ 79.396216] usb 2-1: Manufacturer: Prolific Technology Inc. [ 79.396444] usb 2-1: configuration #1 chosen from 1 choice [ 79.532613] usbcore: registered new interface driver usbserial [ 79.532617] usbserial: USB Serial Driver core [ 79.559641] USB Serial support registered for pl2303 [ 79.559694] pl2303 2-1:1.0: pl2303 converter detected [ 79.571376] usb 2-1: pl2303 converter now attached to ttyUSB0 [ 79.571419] usbcore: registered new interface driver pl2303 [ 79.571425] pl2303: Prolific PL2303 USB to serial adaptor driver [ 100.366955] usb_serial_get_by_index(index 0): @d9cc29c0 [ 100.367151] ------------[ cut here ]------------ [ 100.367345] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 100.367696] Hardware name: TravelMate 660 [ 100.367843] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 100.369196] Pid: 2160, comm: minicom Tainted: G M 2.6.31-rc6 #1 [ 100.369434] Call Trace: [ 100.369529] [<c12b7052>] ? printk+0x18/0x1e [ 100.369694] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 100.369917] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 100.370143] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 100.370363] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 100.370554] [<dea49182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 100.370774] [<dea4936d>] serial_open+0x2d/0x250 [usbserial] [ 100.370975] [<c115f7b9>] ? tty_init_dev+0x89/0x160 [ 100.371135] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 100.371299] [<c1077566>] chrdev_open+0x96/0x140 [ 100.371454] [<c10732ff>] __dentry_open+0x9f/0x250 [ 100.371628] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 100.371793] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 100.371964] [<c107f889>] do_filp_open+0x269/0x890 [ 100.372121] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 100.372298] [<c10730c7>] do_sys_open+0x57/0x140 [ 100.372451] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 100.372632] [<c1073219>] sys_open+0x29/0x40 [ 100.372774] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 100.372951] ---[ end trace d126221248e369ae ]--- [ 149.040186] usb 2-1: USB disconnect, address 2 [ 149.040856] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 149.041116] usb_serial_put(serial @d9cc29c0) [ 149.041254] ------------[ cut here ]------------ [ 149.041438] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 149.041778] Hardware name: TravelMate 660 [ 149.041922] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 149.043273] Pid: 978, comm: khubd Tainted: G M W 2.6.31-rc6 #1 [ 149.043489] Call Trace: [ 149.043583] [<c12b7052>] ? printk+0x18/0x1e [ 149.043746] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 149.043946] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 149.044141] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 149.044335] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 149.044525] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 149.044720] [<dea48f81>] usb_serial_disconnect+0xf1/0x160 [usbserial] [ 149.044981] [<deb54447>] ? usb_disable_interface+0x37/0x50 [usbcore] [ 149.045214] [<deb57221>] usb_unbind_interface+0xf1/0x130 [usbcore] [ 149.045437] [<c11b5441>] __device_release_driver+0x51/0xa0 [ 149.045618] [<c11b5540>] device_release_driver+0x20/0x40 [ 149.045809] [<c11b4aad>] bus_remove_device+0x7d/0xb0 [ 149.045974] [<c11b2ef2>] device_del+0x102/0x190 [ 149.046167] [<deb543a7>] usb_disable_device+0x87/0xf0 [usbcore] [ 149.046384] [<deb4f8a6>] usb_disconnect+0x96/0xf0 [usbcore] [ 149.046608] [<deb50989>] hub_thread+0x829/0x1210 [usbcore] [ 149.046796] [<c10357a0>] ? autoremove_wake_function+0x0/0x50 [ 149.047022] [<deb50160>] ? hub_thread+0x0/0x1210 [usbcore] [ 149.047203] [<c10353cc>] kthread+0x7c/0x90 [ 149.047358] [<c1035350>] ? kthread+0x0/0x90 [ 149.047500] [<c1003673>] kernel_thread_helper+0x7/0x14 [ 149.047684] ---[ end trace d126221248e369af ]--- [ 149.047833] pl2303 2-1:1.0: device disconnected [ 184.321029] serial_do_free(port @d9c61a00) [ 184.321175] serial @d9cc29c0 [ 184.321297] type @de77dc20 [ 184.321398] usb_serial_put(serial @d9cc29c0) [ 184.321550] ------------[ cut here ]------------ [ 184.321715] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 184.322074] Hardware name: TravelMate 660 [ 184.322202] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 184.323568] Pid: 2160, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 184.323775] Call Trace: [ 184.323883] [<c12b7052>] ? printk+0x18/0x1e [ 184.324032] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 184.324246] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 184.324426] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 184.324636] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 184.324810] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 184.325022] [<dea48db9>] serial_do_free+0x99/0xd0 [usbserial] [ 184.325217] [<dea48e57>] serial_close+0x67/0xa0 [usbserial] [ 184.325417] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 184.325569] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 184.325756] [<c1056d72>] ? put_page+0x42/0x120 [ 184.325908] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 184.326091] [<c115f64a>] tty_release+0xa/0x10 [ 184.326237] [<c1075f1c>] __fput+0xdc/0x1d0 [ 184.326391] [<c107602f>] fput+0x1f/0x30 [ 184.326523] [<c1072f8e>] filp_close+0x3e/0x70 [ 184.326687] [<c1024fa2>] put_files_struct+0xa2/0xc0 [ 184.326849] [<c1024fdc>] exit_files+0x1c/0x20 [ 184.327011] [<c1026339>] do_exit+0xb9/0x630 [ 184.327154] [<c103acd8>] ? __put_cred+0x18/0x20 [ 184.327322] [<c10268dd>] do_group_exit+0x2d/0x80 [ 184.327476] [<c1026943>] sys_exit_group+0x13/0x20 [ 184.327650] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 184.327810] ---[ end trace d126221248e369b0 ]--- [ 184.327974] destroy_serial(kref @d9cc29f4) [ 184.328105] serial @d9cc29c0 [ 300.000233] Machine check events logged [ 417.320036] usb 2-1: new full speed USB device using uhci_hcd and address 3 [ 417.486198] usb 2-1: New USB device found, idVendor=067b, idProduct=2303 [ 417.486418] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 417.486663] usb 2-1: Product: USB-Serial Controller [ 417.486820] usb 2-1: Manufacturer: Prolific Technology Inc. [ 417.487238] usb 2-1: configuration #1 chosen from 1 choice [ 417.490544] pl2303 2-1:1.0: pl2303 converter detected [ 417.502366] usb 2-1: pl2303 converter now attached to ttyUSB0 [ 419.476126] usb_serial_get_by_index(index 0): @d9cc2720 [ 419.476320] ------------[ cut here ]------------ [ 419.476518] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 419.476870] Hardware name: TravelMate 660 [ 419.477016] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 419.478371] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 419.478609] Call Trace: [ 419.478704] [<c12b7052>] ? printk+0x18/0x1e [ 419.478869] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 419.479092] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 419.487714] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 419.496407] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 419.505172] [<dea49182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 419.514032] [<dea4936d>] serial_open+0x2d/0x250 [usbserial] [ 419.522887] [<c115f7b9>] ? tty_init_dev+0x89/0x160 [ 419.531577] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 419.540063] [<c1077566>] chrdev_open+0x96/0x140 [ 419.548236] [<c10732ff>] __dentry_open+0x9f/0x250 [ 419.556144] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 419.563852] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 419.571517] [<c107f889>] do_filp_open+0x269/0x890 [ 419.579145] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 419.586769] [<c10730c7>] do_sys_open+0x57/0x140 [ 419.594351] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 419.601918] [<c1073219>] sys_open+0x29/0x40 [ 419.609406] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 419.616902] ---[ end trace d126221248e369b1 ]--- [ 434.000189] usb 2-1: USB disconnect, address 3 [ 434.001726] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 434.001986] usb_serial_put(serial @d9cc2720) [ 434.002126] ------------[ cut here ]------------ [ 434.002310] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 434.002650] Hardware name: TravelMate 660 [ 434.002795] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 434.004145] Pid: 978, comm: khubd Tainted: G M W 2.6.31-rc6 #1 [ 434.004361] Call Trace: [ 434.004455] [<c12b7052>] ? printk+0x18/0x1e [ 434.004620] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.004818] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 434.005014] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.005208] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 434.005398] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 434.005594] [<dea48f81>] usb_serial_disconnect+0xf1/0x160 [usbserial] [ 434.005857] [<deb54447>] ? usb_disable_interface+0x37/0x50 [usbcore] [ 434.006091] [<deb57221>] usb_unbind_interface+0xf1/0x130 [usbcore] [ 434.006314] [<c11b5441>] __device_release_driver+0x51/0xa0 [ 434.006495] [<c11b5540>] device_release_driver+0x20/0x40 [ 434.006686] [<c11b4aad>] bus_remove_device+0x7d/0xb0 [ 434.006850] [<c11b2ef2>] device_del+0x102/0x190 [ 434.007043] [<deb543a7>] usb_disable_device+0x87/0xf0 [usbcore] [ 434.007261] [<deb4f8a6>] usb_disconnect+0x96/0xf0 [usbcore] [ 434.007486] [<deb50989>] hub_thread+0x829/0x1210 [usbcore] [ 434.007673] [<c10357a0>] ? autoremove_wake_function+0x0/0x50 [ 434.007901] [<deb50160>] ? hub_thread+0x0/0x1210 [usbcore] [ 434.008082] [<c10353cc>] kthread+0x7c/0x90 [ 434.008236] [<c1035350>] ? kthread+0x0/0x90 [ 434.008379] [<c1003673>] kernel_thread_helper+0x7/0x14 [ 434.008562] ---[ end trace d126221248e369b2 ]--- [ 434.008710] pl2303 2-1:1.0: device disconnected [ 434.009183] usb_serial_get_by_index(index 0): @d9cc2720 [ 434.009354] ------------[ cut here ]------------ [ 434.009532] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 434.009885] Hardware name: TravelMate 660 [ 434.010054] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 434.011402] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 434.011626] Call Trace: [ 434.011714] [<c12b7052>] ? printk+0x18/0x1e [ 434.011877] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 434.012097] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 434.012293] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 434.012511] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 434.012701] [<dea49182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 434.012920] [<dea4936d>] serial_open+0x2d/0x250 [usbserial] [ 434.013123] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 434.013292] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 434.013456] [<c1077566>] chrdev_open+0x96/0x140 [ 434.013611] [<c10732ff>] __dentry_open+0x9f/0x250 [ 434.013786] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 434.013950] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 434.014120] [<c107f889>] do_filp_open+0x269/0x890 [ 434.014278] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 434.023849] [<c10730c7>] do_sys_open+0x57/0x140 [ 434.033742] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 434.043683] [<c1073219>] sys_open+0x29/0x40 [ 434.053671] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 434.063679] ---[ end trace d126221248e369b3 ]--- [ 434.079109] usb_serial_put(serial @d9cc2720) [ 434.083537] ------------[ cut here ]------------ [ 434.087641] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 434.091916] Hardware name: TravelMate 660 [ 434.096132] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 434.105454] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 434.109980] Call Trace: [ 434.114426] [<c12b7052>] ? printk+0x18/0x1e [ 434.118801] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.123133] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 434.127306] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.131466] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 434.135581] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 434.139755] [<dea493b0>] serial_open+0x70/0x250 [usbserial] [ 434.143923] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 434.148035] [<c1077566>] chrdev_open+0x96/0x140 [ 434.152172] [<c10732ff>] __dentry_open+0x9f/0x250 [ 434.156257] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 434.160367] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 434.164429] [<c107f889>] do_filp_open+0x269/0x890 [ 434.168489] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 434.172551] [<c10730c7>] do_sys_open+0x57/0x140 [ 434.176561] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 434.180600] [<c1073219>] sys_open+0x29/0x40 [ 434.184596] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 434.188611] ---[ end trace d126221248e369b4 ]--- [ 434.193345] tty_port_close_start: count = -1 [ 434.290041] serial_do_free(port @d8df5c00) [ 434.299763] serial @d9cc2720 [ 434.309450] type @de77dc20 [ 434.319321] usb_serial_put(serial @d9cc2720) [ 434.323540] ------------[ cut here ]------------ [ 434.327490] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 434.331601] Hardware name: TravelMate 660 [ 434.335662] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 434.344746] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 434.349160] Call Trace: [ 434.353463] [<c12b7052>] ? printk+0x18/0x1e [ 434.357707] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.361868] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 434.365907] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.369882] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 434.373881] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 434.377868] [<dea48db9>] serial_do_free+0x99/0xd0 [usbserial] [ 434.381857] [<dea48e57>] serial_close+0x67/0xa0 [usbserial] [ 434.385792] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 434.389716] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 434.393638] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 434.397546] [<c10207e3>] ? __cond_resched+0x23/0x40 [ 434.401443] [<c12b7d7e>] ? mutex_lock+0xe/0x20 [ 434.405321] [<dea48d0b>] ? usb_serial_put+0x4b/0x60 [usbserial] [ 434.409216] [<dea493b0>] ? serial_open+0x70/0x250 [usbserial] [ 434.413153] [<c115fced>] tty_open+0x45d/0x4b0 [ 434.417051] [<c1077566>] chrdev_open+0x96/0x140 [ 434.420985] [<c10732ff>] __dentry_open+0x9f/0x250 [ 434.424892] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 434.428818] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 434.432630] [<c107f889>] do_filp_open+0x269/0x890 [ 434.436315] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 434.439985] [<c10730c7>] do_sys_open+0x57/0x140 [ 434.443676] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 434.447346] [<c1073219>] sys_open+0x29/0x40 [ 434.451022] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 434.454672] ---[ end trace d126221248e369b5 ]--- [ 434.459076] destroy_serial(kref @d9cc2754) [ 434.462686] serial @d9cc2720 [ 454.363600] serial_do_free(port @d8df5c00) [ 454.363745] serial @d8df5a00 [ 454.363868] type @(null) [ 454.363992] BUG: unable to handle kernel NULL pointer dereference at 0000001c [ 454.364252] IP: [<dea48d8d>] serial_do_free+0x6d/0xd0 [usbserial] [ 454.364487] *pde = 00000000 [ 454.364609] Oops: 0000 [#1] [ 454.364731] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 454.364974] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt [ 454.366315] [ 454.366391] Pid: 2186, comm: minicom Tainted: G M W (2.6.31-rc6 #1) TravelMate 660 [ 454.366644] EIP: 0060:[<dea48d8d>] EFLAGS: 00010282 CPU: 0 [ 454.366844] EIP is at serial_do_free+0x6d/0xd0 [usbserial] [ 454.367018] EAX: 00000000 EBX: d8df5c00 ECX: ffffffff EDX: c13c6584 [ 454.367245] ESI: d8df5a00 EDI: 00000000 EBP: d8cc3e24 ESP: d8cc3e10 [ 454.367444] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 454.367633] Process minicom (pid: 2186, ti=d8cc3000 task=dd8e1dd0 task.ti=d8cc3000) [ 454.367870] Stack: [ 454.367954] dea4cc4e 00000000 d8df5c00 dd0d8c00 00000000 d8cc3e4c dea48e57 00000000 [ 454.368329] <0> d8cc3e4c c115d1a5 dd0d8ca0 dd8d1180 dd0d8c00 00000000 00000000 d8cc3edc [ 454.368749] <0> c115f2e0 40000000 d8cc3e94 00000082 dd8d1180 00000000 00000000 00000000 [ 454.369178] Call Trace: [ 454.369290] [<dea48e57>] ? serial_close+0x67/0xa0 [usbserial] [ 454.369483] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 454.369652] [<c115f2e0>] ? tty_release_dev+0x130/0x490 [ 454.369828] [<c1056d72>] ? put_page+0x42/0x120 [ 454.369993] [<c105435a>] ? free_hot_page+0xa/0x10 [ 454.370195] [<c105438f>] ? __free_pages+0x2f/0x40 [ 454.370356] [<c107042e>] ? __free_slab+0xae/0x160 [ 454.370530] [<c115f64a>] ? tty_release+0xa/0x10 [ 454.370681] [<c1075f1c>] ? __fput+0xdc/0x1d0 [ 454.370840] [<c107602f>] ? fput+0x1f/0x30 [ 454.370976] [<c1072f8e>] ? filp_close+0x3e/0x70 [ 454.371148] [<c1024fa2>] ? put_files_struct+0xa2/0xc0 [ 454.371315] [<c1024fdc>] ? exit_files+0x1c/0x20 [ 454.371483] [<c1026339>] ? do_exit+0xb9/0x630 [ 454.371631] [<c103acd8>] ? __put_cred+0x18/0x20 [ 454.371799] [<c10268dd>] ? do_group_exit+0x2d/0x80 [ 454.371959] [<c1026943>] ? sys_exit_group+0x13/0x20 [ 454.372137] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 454.372300] Code: a4 de 89 44 24 04 e8 cd e2 86 e2 8b 13 31 c0 85 d2 74 03 8b 42 04 89 44 24 04 c7 04 24 4e cc a4 de e8 b2 e2 86 e2 8b 33 8b 46 04 <8b> 78 1c 8d 83 bc 00 00 00 e8 95 93 76 e2 8d 5e 38 89 d8 e8 cb [ 454.374157] EIP: [<dea48d8d>] serial_do_free+0x6d/0xd0 [usbserial] SS:ESP 0068:d8cc3e10 [ 454.374470] CR2: 000000000000001c [ 454.374580] ---[ end trace d126221248e369b6 ]--- [ 454.374742] Fixing recursive fault but reboot is needed! First unplug attempt with running minicom survived, the second attempt crashed. dmesg extract for ftdi_sio attempt: [ 97.650041] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 97.868191] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 97.868410] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 97.868655] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 97.868831] usb 1-2: Manufacturer: FTDI [ 97.868972] usb 1-2: SerialNumber: FTS55QK6 [ 97.869346] usb 1-2: configuration #1 chosen from 1 choice [ 98.005741] usbcore: registered new interface driver usbserial [ 98.005961] usbserial: USB Serial Driver core [ 98.105309] USB Serial support registered for FTDI USB Serial Device [ 98.105782] usb 1-2: Ignoring serial port reserved for JTAG [ 98.106078] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 98.106359] usb 1-2: Detected FT2232C [ 98.106482] usb 1-2: Number of endpoints 2 [ 98.106634] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 98.106783] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 98.106947] usb 1-2: Setting MaxPacketSize 64 [ 98.108347] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 98.108641] usbcore: registered new interface driver ftdi_sio [ 98.108824] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 109.201971] usb_serial_get_by_index(index 0): @d8c60c00 [ 109.211271] ------------[ cut here ]------------ [ 109.220604] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 109.230195] Hardware name: TravelMate 660 [ 109.239718] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 109.260505] Pid: 2163, comm: minicom Tainted: G M 2.6.31-rc6 #1 [ 109.270831] Call Trace: [ 109.281027] [<c12b7052>] ? printk+0x18/0x1e [ 109.291242] [<dea5d182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 109.301505] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 109.311732] [<dea5d182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 109.322008] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 109.332244] [<dea5d182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 109.342515] [<dea5d36d>] serial_open+0x2d/0x250 [usbserial] [ 109.352742] [<c115f7b9>] ? tty_init_dev+0x89/0x160 [ 109.362895] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 109.372987] [<c1077566>] chrdev_open+0x96/0x140 [ 109.383039] [<c10732ff>] __dentry_open+0x9f/0x250 [ 109.393033] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 109.402978] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 109.412910] [<c107f889>] do_filp_open+0x269/0x890 [ 109.422804] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 109.432598] [<c10730c7>] do_sys_open+0x57/0x140 [ 109.442338] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 109.451867] [<c1073219>] sys_open+0x29/0x40 [ 109.461165] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 109.470466] ---[ end trace 3473a8310f07944c ]--- [ 119.290059] usb 1-2: USB disconnect, address 2 [ 119.290625] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 119.290932] usb_serial_put(serial @d8c60c00) [ 119.291070] ------------[ cut here ]------------ [ 119.291255] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 119.291584] Hardware name: TravelMate 660 [ 119.291728] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 119.293082] Pid: 989, comm: khubd Tainted: G M W 2.6.31-rc6 #1 [ 119.293313] Call Trace: [ 119.293406] [<c12b7052>] ? printk+0x18/0x1e [ 119.293570] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.293769] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 119.293964] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.294158] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 119.294348] [<dea5cceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 119.294543] [<dea5cf81>] usb_serial_disconnect+0xf1/0x160 [usbserial] [ 119.294819] [<deb54447>] ? usb_disable_interface+0x37/0x50 [usbcore] [ 119.295053] [<deb57221>] usb_unbind_interface+0xf1/0x130 [usbcore] [ 119.295276] [<c11b5441>] __device_release_driver+0x51/0xa0 [ 119.295457] [<c11b5540>] device_release_driver+0x20/0x40 [ 119.295649] [<c11b4aad>] bus_remove_device+0x7d/0xb0 [ 119.295813] [<c11b2ef2>] device_del+0x102/0x190 [ 119.296006] [<deb543a7>] usb_disable_device+0x87/0xf0 [usbcore] [ 119.296223] [<deb4f8a6>] usb_disconnect+0x96/0xf0 [usbcore] [ 119.296448] [<deb50989>] hub_thread+0x829/0x1210 [usbcore] [ 119.296636] [<c10357a0>] ? autoremove_wake_function+0x0/0x50 [ 119.296863] [<deb50160>] ? hub_thread+0x0/0x1210 [usbcore] [ 119.297044] [<c10353cc>] kthread+0x7c/0x90 [ 119.297198] [<c1035350>] ? kthread+0x0/0x90 [ 119.297341] [<c1003673>] kernel_thread_helper+0x7/0x14 [ 119.297524] ---[ end trace 3473a8310f07944d ]--- [ 119.297673] ftdi_sio 1-2:1.1: device disconnected [ 119.299108] usb_serial_get_by_index(index 0): @d8c60c00 [ 119.299287] ------------[ cut here ]------------ [ 119.299473] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 119.299823] Hardware name: TravelMate 660 [ 119.299968] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 119.301355] Pid: 2163, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 119.301562] Call Trace: [ 119.301667] [<c12b7052>] ? printk+0x18/0x1e [ 119.301815] [<dea5d182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 119.302051] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 119.302230] [<dea5d182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 119.302464] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 119.302638] [<dea5d182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 119.302873] [<dea5d36d>] serial_open+0x2d/0x250 [usbserial] [ 119.303061] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 119.303247] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 119.303395] [<c1077566>] chrdev_open+0x96/0x140 [ 119.303566] [<c10732ff>] __dentry_open+0x9f/0x250 [ 119.313182] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 119.323123] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 119.333092] [<c107f889>] do_filp_open+0x269/0x890 [ 119.343121] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 119.353157] [<c10730c7>] do_sys_open+0x57/0x140 [ 119.363185] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 119.373242] [<c1073219>] sys_open+0x29/0x40 [ 119.383280] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 119.393324] ---[ end trace 3473a8310f07944e ]--- [ 119.408837] usb_serial_put(serial @d8c60c00) [ 119.413343] ------------[ cut here ]------------ [ 119.417526] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 119.421858] Hardware name: TravelMate 660 [ 119.426125] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 119.435491] Pid: 2163, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 119.440021] Call Trace: [ 119.444452] [<c12b7052>] ? printk+0x18/0x1e [ 119.448835] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.453171] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 119.457354] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.461511] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 119.465632] [<dea5cceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 119.469788] [<dea5d3b0>] serial_open+0x70/0x250 [usbserial] [ 119.473949] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 119.478075] [<c1077566>] chrdev_open+0x96/0x140 [ 119.482212] [<c10732ff>] __dentry_open+0x9f/0x250 [ 119.486300] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 119.490406] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 119.494476] [<c107f889>] do_filp_open+0x269/0x890 [ 119.498540] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 119.502596] [<c10730c7>] do_sys_open+0x57/0x140 [ 119.506622] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 119.510654] [<c1073219>] sys_open+0x29/0x40 [ 119.514676] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 119.518689] ---[ end trace 3473a8310f07944f ]--- [ 119.523383] tty_port_close_start: count = -1 [ 119.527396] serial_do_free(port @da025e00) [ 119.531404] serial @d8c60c00 [ 119.535353] type @deb0e660 [ 119.539434] usb_serial_put(serial @d8c60c00) [ 119.543430] ------------[ cut here ]------------ [ 119.547389] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 119.551513] Hardware name: TravelMate 660 [ 119.555583] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 119.564707] Pid: 2163, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 119.569109] Call Trace: [ 119.573439] [<c12b7052>] ? printk+0x18/0x1e [ 119.577675] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.581857] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 119.585894] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.589896] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 119.593885] [<dea5cceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 119.597906] [<dea5cdb9>] serial_do_free+0x99/0xd0 [usbserial] [ 119.601891] [<dea5ce57>] serial_close+0x67/0xa0 [usbserial] [ 119.605852] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 119.609774] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 119.613714] [<dea5cceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 119.617621] [<c10207e3>] ? __cond_resched+0x23/0x40 [ 119.621535] [<c12b7d7e>] ? mutex_lock+0xe/0x20 [ 119.625407] [<dea5cd0b>] ? usb_serial_put+0x4b/0x60 [usbserial] [ 119.629318] [<dea5d3b0>] ? serial_open+0x70/0x250 [usbserial] [ 119.633249] [<c115fced>] tty_open+0x45d/0x4b0 [ 119.637046] [<c1077566>] chrdev_open+0x96/0x140 [ 119.640727] [<c10732ff>] __dentry_open+0x9f/0x250 [ 119.644412] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 119.648080] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 119.651781] [<c107f889>] do_filp_open+0x269/0x890 [ 119.655451] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 119.659128] [<c10730c7>] do_sys_open+0x57/0x140 [ 119.662807] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 119.666484] [<c1073219>] sys_open+0x29/0x40 [ 119.670149] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 119.673808] ---[ end trace 3473a8310f079450 ]--- [ 119.678200] destroy_serial(kref @d8c60c34) [ 119.681814] serial @d8c60c00 [ 128.465874] serial_do_free(port @da025e00) [ 128.466022] serial @da025400 [ 128.466147] type @203a6e69 [ 128.466277] BUG: unable to handle kernel paging request at 203a6e85 [ 128.466510] IP: [<dea5cd8d>] serial_do_free+0x6d/0xd0 [usbserial] [ 128.466747] *pde = 00000000 [ 128.466870] Oops: 0000 [#1] [ 128.466991] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 128.467236] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus ehci_hcd uhci_hcd nsc_ircc snd_pcm usbcore irda snd_timer pcspkr snd i2c_i801 snd_page_alloc crc_ccitt [ 128.468576] [ 128.468651] Pid: 2163, comm: minicom Tainted: G M W (2.6.31-rc6 #1) TravelMate 660 [ 128.468905] EIP: 0060:[<dea5cd8d>] EFLAGS: 00010282 CPU: 0 [ 128.469105] EIP is at serial_do_free+0x6d/0xd0 [usbserial] [ 128.469279] EAX: 203a6e69 EBX: da025e00 ECX: ffffffff EDX: c13c6584 [ 128.469507] ESI: da025400 EDI: 00000000 EBP: db56de24 ESP: db56de10 [ 128.469706] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 128.469895] Process minicom (pid: 2163, ti=db56d000 task=dd9ac9f0 task.ti=db56d000) [ 128.470166] Stack: [ 128.470236] dea60c4e 203a6e69 da025e00 db442c00 00000000 db56de4c dea5ce57 00000000 [ 128.470612] <0> db56de4c c115d1a5 db442ca0 d9c84280 db442c00 00000000 00000000 db56dedc [ 128.471032] <0> c115f2e0 00000001 00000002 c17b1c00 d9c84280 00000000 00000000 c1817d80 [ 128.471479] Call Trace: [ 128.471576] [<dea5ce57>] ? serial_close+0x67/0xa0 [usbserial] [ 128.471784] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 128.471938] [<c115f2e0>] ? tty_release_dev+0x130/0x490 [ 128.472130] [<c1056d72>] ? put_page+0x42/0x120 [ 128.472282] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 128.472466] [<c115f64a>] ? tty_release+0xa/0x10 [ 128.472618] [<c1075f1c>] ? __fput+0xdc/0x1d0 [ 128.472777] [<c107602f>] ? fput+0x1f/0x30 [ 128.472914] [<c1072f8e>] ? filp_close+0x3e/0x70 [ 128.473086] [<c1024fa2>] ? put_files_struct+0xa2/0xc0 [ 128.473253] [<c1024fdc>] ? exit_files+0x1c/0x20 [ 128.473421] [<c1026339>] ? do_exit+0xb9/0x630 [ 128.473570] [<c103acd8>] ? __put_cred+0x18/0x20 [ 128.473738] [<c10268dd>] ? do_group_exit+0x2d/0x80 [ 128.473898] [<c1026943>] ? sys_exit_group+0x13/0x20 [ 128.474076] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 128.474240] Code: a6 de 89 44 24 04 e8 cd a2 85 e2 8b 13 31 c0 85 d2 74 03 8b 42 04 89 44 24 04 c7 04 24 4e 0c a6 de e8 b2 a2 85 e2 8b 33 8b 46 04 <8b> 78 1c 8d 83 bc 00 00 00 e8 95 53 75 e2 8d 5e 38 89 d8 e8 cb [ 128.476094] EIP: [<dea5cd8d>] serial_do_free+0x6d/0xd0 [usbserial] SS:ESP 0068:db56de10 [ 128.476408] CR2: 00000000203a6e85 [ 128.476518] ---[ end trace 3473a8310f079451 ]--- [ 128.476680] Fixing recursive fault but reboot is needed! With ftdi it crashes on first attempt each time I try. ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 20:15 ` Bruno Prémont @ 2009-08-19 21:01 ` Alan Stern 2009-08-19 21:50 ` Alan Cox 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-19 21:01 UTC (permalink / raw) To: Bruno Prémont, Alan Cox Cc: Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 19 Aug 2009, Bruno [UTF-8] Prémont wrote: > I've added WARN_ON()s in usb_serial_put() and usb_serial_get_by_index() > in order to have information on who called us (easier than searching > around and adding lots of printk()s and output is also more verbose :) > > Below, my changes to usb-serial.c and dmesg extracts for crash cases with > pl2302 and ftdi_sio. > > You have guessed right, there are calls to serial_do_free() after > destroy_serial() in the crash cases. destroy_serial when disconnecting > device and final serial_do_free() when exiting minicom. Good work. This shows clearly where the problem is. > [ 417.320036] usb 2-1: new full speed USB device using uhci_hcd and address 3 > [ 417.486198] usb 2-1: New USB device found, idVendor=067b, idProduct=2303 > [ 417.486418] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > [ 417.486663] usb 2-1: Product: USB-Serial Controller > [ 417.486820] usb 2-1: Manufacturer: Prolific Technology Inc. > [ 417.487238] usb 2-1: configuration #1 chosen from 1 choice > [ 417.490544] pl2303 2-1:1.0: pl2303 converter detected > [ 417.502366] usb 2-1: pl2303 converter now attached to ttyUSB0 The pl2303 was plugged in. > [ 419.476126] usb_serial_get_by_index(index 0): @d9cc2720 > [ 419.476320] ------------[ cut here ]------------ > [ 419.476518] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() > [ 419.476870] Hardware name: TravelMate 660 > [ 419.477016] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 419.478371] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 > [ 419.478609] Call Trace: > [ 419.478704] [<c12b7052>] ? printk+0x18/0x1e > [ 419.478869] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 419.479092] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 > [ 419.487714] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 419.496407] [<c1023765>] warn_slowpath_null+0x15/0x20 > [ 419.505172] [<dea49182>] usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 419.514032] [<dea4936d>] serial_open+0x2d/0x250 [usbserial] Minicom opened the device file. > [ 434.000189] usb 2-1: USB disconnect, address 3 > [ 434.001726] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 > [ 434.001986] usb_serial_put(serial @d9cc2720) > [ 434.002126] ------------[ cut here ]------------ > [ 434.002310] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() > [ 434.002650] Hardware name: TravelMate 660 > [ 434.002795] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 434.004145] Pid: 978, comm: khubd Tainted: G M W 2.6.31-rc6 #1 > [ 434.004361] Call Trace: > [ 434.004455] [<c12b7052>] ? printk+0x18/0x1e > [ 434.004620] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.004818] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 > [ 434.005014] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.005208] [<c1023765>] warn_slowpath_null+0x15/0x20 > [ 434.005398] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] > [ 434.005594] [<dea48f81>] usb_serial_disconnect+0xf1/0x160 [usbserial] ... > [ 434.008710] pl2303 2-1:1.0: device disconnected The pl2303 was unplugged. > [ 434.009183] usb_serial_get_by_index(index 0): @d9cc2720 > [ 434.009354] ------------[ cut here ]------------ > [ 434.009532] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() > [ 434.009885] Hardware name: TravelMate 660 > [ 434.010054] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 434.011402] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 > [ 434.011626] Call Trace: > [ 434.011714] [<c12b7052>] ? printk+0x18/0x1e > [ 434.011877] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 434.012097] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 > [ 434.012293] [<dea49182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 434.012511] [<c1023765>] warn_slowpath_null+0x15/0x20 > [ 434.012701] [<dea49182>] usb_serial_get_by_index+0x42/0x70 [usbserial] > [ 434.012920] [<dea4936d>] serial_open+0x2d/0x250 [usbserial] > [ 434.013123] [<c10897b6>] ? mntput_no_expire+0x16/0x60 > [ 434.013292] [<c115fa4d>] tty_open+0x1bd/0x4b0 For some reason, minicom attempted to reopen the device file immediately. > [ 434.079109] usb_serial_put(serial @d9cc2720) > [ 434.083537] ------------[ cut here ]------------ > [ 434.087641] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() > [ 434.091916] Hardware name: TravelMate 660 > [ 434.096132] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 434.105454] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 > [ 434.109980] Call Trace: > [ 434.114426] [<c12b7052>] ? printk+0x18/0x1e > [ 434.118801] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.123133] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 > [ 434.127306] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.131466] [<c1023765>] warn_slowpath_null+0x15/0x20 > [ 434.135581] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] > [ 434.139755] [<dea493b0>] serial_open+0x70/0x250 [usbserial] > [ 434.143923] [<c115fa4d>] tty_open+0x1bd/0x4b0 The open failed, because the device had been unplugged. serial_open() would therefore return -ENODEV. > [ 434.193345] tty_port_close_start: count = -1 > [ 434.290041] serial_do_free(port @d8df5c00) > [ 434.299763] serial @d9cc2720 > [ 434.309450] type @de77dc20 > [ 434.319321] usb_serial_put(serial @d9cc2720) > [ 434.323540] ------------[ cut here ]------------ > [ 434.327490] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() > [ 434.331601] Hardware name: TravelMate 660 > [ 434.335662] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 434.344746] Pid: 2186, comm: minicom Tainted: G M W 2.6.31-rc6 #1 > [ 434.349160] Call Trace: > [ 434.353463] [<c12b7052>] ? printk+0x18/0x1e > [ 434.357707] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.361868] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 > [ 434.365907] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.369882] [<c1023765>] warn_slowpath_null+0x15/0x20 > [ 434.373881] [<dea48ceb>] usb_serial_put+0x2b/0x60 [usbserial] > [ 434.377868] [<dea48db9>] serial_do_free+0x99/0xd0 [usbserial] > [ 434.381857] [<dea48e57>] serial_close+0x67/0xa0 [usbserial] > [ 434.385792] [<c115d1a5>] ? tty_fasync+0x55/0xe0 > [ 434.389716] [<c115f2e0>] tty_release_dev+0x130/0x490 > [ 434.393638] [<dea48ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] > [ 434.397546] [<c10207e3>] ? __cond_resched+0x23/0x40 > [ 434.401443] [<c12b7d7e>] ? mutex_lock+0xe/0x20 > [ 434.405321] [<dea48d0b>] ? usb_serial_put+0x4b/0x60 [usbserial] > [ 434.409216] [<dea493b0>] ? serial_open+0x70/0x250 [usbserial] > [ 434.413153] [<c115fced>] tty_open+0x45d/0x4b0 This is the key. When the open failed, tty_open() went on to call tty_release_dev(), which in turn called serial_close(). In other words, the TTY layer was trying to close a device reference which had never successfully been opened! This resulted in an unbalanced call to usb_serial_put(). > [ 434.459076] destroy_serial(kref @d9cc2754) > [ 434.462686] serial @d9cc2720 The extra put caused the data structure to be released too soon. > [ 454.363600] serial_do_free(port @d8df5c00) > [ 454.363745] serial @d8df5a00 > [ 454.363868] type @(null) > [ 454.363992] BUG: unable to handle kernel NULL pointer dereference at 0000001c > [ 454.364252] IP: [<dea48d8d>] serial_do_free+0x6d/0xd0 [usbserial] > [ 454.364487] *pde = 00000000 > [ 454.364609] Oops: 0000 [#1] > [ 454.364731] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input > [ 454.364974] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_hcd nsc_ircc usbcore snd_timer irda snd pcspkr i2c_i801 snd_page_alloc crc_ccitt > [ 454.366315] > [ 454.366391] Pid: 2186, comm: minicom Tainted: G M W (2.6.31-rc6 #1) TravelMate 660 > [ 454.366644] EIP: 0060:[<dea48d8d>] EFLAGS: 00010282 CPU: 0 > [ 454.366844] EIP is at serial_do_free+0x6d/0xd0 [usbserial] > [ 454.367018] EAX: 00000000 EBX: d8df5c00 ECX: ffffffff EDX: c13c6584 > [ 454.367245] ESI: d8df5a00 EDI: 00000000 EBP: d8cc3e24 ESP: d8cc3e10 > [ 454.367444] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 > [ 454.367633] Process minicom (pid: 2186, ti=d8cc3000 task=dd8e1dd0 task.ti=d8cc3000) > [ 454.367870] Stack: > [ 454.367954] dea4cc4e 00000000 d8df5c00 dd0d8c00 00000000 d8cc3e4c dea48e57 00000000 > [ 454.368329] <0> d8cc3e4c c115d1a5 dd0d8ca0 dd8d1180 dd0d8c00 00000000 00000000 d8cc3edc > [ 454.368749] <0> c115f2e0 40000000 d8cc3e94 00000082 dd8d1180 00000000 00000000 00000000 > [ 454.369178] Call Trace: > [ 454.369290] [<dea48e57>] ? serial_close+0x67/0xa0 [usbserial] > [ 454.369483] [<c115d1a5>] ? tty_fasync+0x55/0xe0 > [ 454.369652] [<c115f2e0>] ? tty_release_dev+0x130/0x490 > [ 454.369828] [<c1056d72>] ? put_page+0x42/0x120 > [ 454.369993] [<c105435a>] ? free_hot_page+0xa/0x10 > [ 454.370195] [<c105438f>] ? __free_pages+0x2f/0x40 > [ 454.370356] [<c107042e>] ? __free_slab+0xae/0x160 > [ 454.370530] [<c115f64a>] ? tty_release+0xa/0x10 > [ 454.370681] [<c1075f1c>] ? __fput+0xdc/0x1d0 > [ 454.370840] [<c107602f>] ? fput+0x1f/0x30 > [ 454.370976] [<c1072f8e>] ? filp_close+0x3e/0x70 > [ 454.371148] [<c1024fa2>] ? put_files_struct+0xa2/0xc0 > [ 454.371315] [<c1024fdc>] ? exit_files+0x1c/0x20 > [ 454.371483] [<c1026339>] ? do_exit+0xb9/0x630 And this is the actual close that occurred when minicom exited. But by then it was too late. So Alan, what's the explanation? An unsuccessful open method call should not lead to a close method call. Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 21:01 ` Alan Stern @ 2009-08-19 21:50 ` Alan Cox 2009-08-19 22:44 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Alan Cox @ 2009-08-19 21:50 UTC (permalink / raw) To: Alan Stern Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki > So Alan, what's the explanation? An unsuccessful open method call > should not lead to a close method call. For tty it always has since back in 0.9x, and most drivers depend upon this behaviour. Alan ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 21:50 ` Alan Cox @ 2009-08-19 22:44 ` Alan Stern 2009-08-20 19:25 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-19 22:44 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 19 Aug 2009, Alan Cox wrote: > > So Alan, what's the explanation? An unsuccessful open method call > > should not lead to a close method call. > > For tty it always has since back in 0.9x, and most drivers depend upon > this behaviour. Curiouser and curiouser... Okay Bruno, try out this patch and let's see if it helps. It should fix the problem with the pl2303. I'm not so sure about the FTDI device because that driver maintains its own reference count for its private data. Alan Stern Index: usb-2.6/drivers/usb/serial/usb-serial.c =================================================================== --- usb-2.6.orig/drivers/usb/serial/usb-serial.c +++ usb-2.6/drivers/usb/serial/usb-serial.c @@ -209,8 +209,13 @@ static int serial_open (struct tty_struc * to be acquired while serial->disc_mutex is held. */ mutex_unlock(&serial->disc_mutex); + + /* For reasons that have been lost in antiquity, the TTY layer calls + * our close method even if the open call fails. Hence we must not + * drop the reference obtained by usb_serial_get_by_index(). + */ if (retval) - goto bailout_serial_put; + return retval; if (mutex_lock_interruptible(&port->mutex)) { retval = -ERESTARTSYS; @@ -276,8 +281,6 @@ bailout_mutex_unlock: mutex_unlock(&port->mutex); bailout_port_put: put_device(&port->dev); -bailout_serial_put: - usb_serial_put(serial); return retval; } ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-19 22:44 ` Alan Stern @ 2009-08-20 19:25 ` Bruno Prémont 2009-08-20 21:20 ` Alan Stern 2009-08-20 21:58 ` Alan Cox 0 siblings, 2 replies; 42+ messages in thread From: Bruno Prémont @ 2009-08-20 19:25 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 19 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > On Wed, 19 Aug 2009, Alan Cox wrote: > > > > So Alan, what's the explanation? An unsuccessful open method call > > > should not lead to a close method call. > > > > For tty it always has since back in 0.9x, and most drivers depend > > upon this behaviour. > > Curiouser and curiouser... > > Okay Bruno, try out this patch and let's see if it helps. It should > fix the problem with the pl2303. I'm not so sure about the FTDI > device because that driver maintains its own reference count for its > private data. > > Alan Stern No, that one does not really help (well it avoids dereferencing a bad pointer (NULL for pl2302 or invalid for ftdi) with serial_do_free() after destroy_serial() but is does underflow module refcount (refcount ends up at 2^32-1) and lets the kernel stall/panic a short time later without any useful information at that moment (only very first line of trace ever appears) [ftdi for the panic/freeze]. So I would say at best it's just a step towards the solution... there are still unbalanced operations left (module refcount being the visible one, then probably the already mentioned private book-keeping of ftdi)! Bruno > Index: usb-2.6/drivers/usb/serial/usb-serial.c > =================================================================== > --- usb-2.6.orig/drivers/usb/serial/usb-serial.c > +++ usb-2.6/drivers/usb/serial/usb-serial.c > @@ -209,8 +209,13 @@ static int serial_open (struct tty_struc > * to be acquired while serial->disc_mutex is held. > */ > mutex_unlock(&serial->disc_mutex); > + > + /* For reasons that have been lost in antiquity, the TTY > layer calls > + * our close method even if the open call fails. Hence we > must not > + * drop the reference obtained by usb_serial_get_by_index(). > + */ > if (retval) > - goto bailout_serial_put; > + return retval; > > if (mutex_lock_interruptible(&port->mutex)) { > retval = -ERESTARTSYS; > @@ -276,8 +281,6 @@ bailout_mutex_unlock: > mutex_unlock(&port->mutex); > bailout_port_put: > put_device(&port->dev); > -bailout_serial_put: > - usb_serial_put(serial); > return retval; > } > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-20 19:25 ` Bruno Prémont @ 2009-08-20 21:20 ` Alan Stern 2009-08-21 9:25 ` Bruno Prémont 2009-08-20 21:58 ` Alan Cox 1 sibling, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-20 21:20 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Thu, 20 Aug 2009, Bruno [UTF-8] Prémont wrote: > No, that one does not really help (well it avoids dereferencing a bad > pointer (NULL for pl2302 or invalid for ftdi) with serial_do_free() after > destroy_serial() but is does underflow module refcount (refcount ends > up at 2^32-1) and lets the kernel stall/panic a short time later without > any useful information at that moment (only very first line of trace > ever appears) [ftdi for the panic/freeze]. More information, please. Does the problem occur with the pl2303 or only with the ftdi? Which module's refcount underflows? What else can you provide? I don't see the same sort of thing with my pl2303 device, but maybe I'm using a different version of minicom. Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-20 21:20 ` Alan Stern @ 2009-08-21 9:25 ` Bruno Prémont 2009-08-21 15:43 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-21 9:25 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Thu, 20 Aug 2009 17:20:35 Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 20 Aug 2009, Bruno [UTF-8] Prémont wrote: > > > No, that one does not really help (well it avoids dereferencing a > > bad pointer (NULL for pl2302 or invalid for ftdi) with > > serial_do_free() after destroy_serial() but is does underflow > > module refcount (refcount ends up at 2^32-1) and lets the kernel > > stall/panic a short time later without any useful information at > > that moment (only very first line of trace ever appears) [ftdi for > > the panic/freeze]. > > More information, please. Does the problem occur with the pl2303 or > only with the ftdi? Which module's refcount underflows? What else > can you provide? The module refcount was for both. It's the pl2302/ftdi-sio module's refcount. I don't remember for sure about the panic if it also affects pl2302 or not. At least one of the panics was when running dmesg after exiting minicom. I will redo the tests this evening when I get home and report back with more details. > I don't see the same sort of thing with my pl2303 device, but maybe > I'm using a different version of minicom. > > Alan Stern Bruno ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 9:25 ` Bruno Prémont @ 2009-08-21 15:43 ` Alan Stern 2009-08-21 15:48 ` Alan Cox 2009-08-21 16:50 ` Bruno Prémont 0 siblings, 2 replies; 42+ messages in thread From: Alan Stern @ 2009-08-21 15:43 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Fri, 21 Aug 2009, Bruno [UTF-8] Prémont wrote: > The module refcount was for both. It's the pl2302/ftdi-sio module's > refcount. > > I don't remember for sure about the panic if it also affects > pl2302 or not. > At least one of the panics was when running dmesg after exiting minicom. > > I will redo the tests this evening when I get home and report back with > more details. Apparently the problem is in serial_do_free(); it doesn't know whether it's getting called for a successful open or an unsuccessful open, so it decrements the module count when it shouldn't. The same is true for port->dev's refcount. Alan, related to this problem is the fact that usb_serial_driver doesn't include a "hangup" method. I'm not sure that making serial_hangup() call serial_do_down() is correct, but if it is then shouldn't we call port->serial->type->open() afterwards? Otherwise the lower driver can't know that the port is still open. Furthermore, shouldn't we check ASYNCB_INITIALIZED in serial_close()? Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 15:43 ` Alan Stern @ 2009-08-21 15:48 ` Alan Cox 2009-08-21 17:39 ` Alan Stern 2009-08-21 16:50 ` Bruno Prémont 1 sibling, 1 reply; 42+ messages in thread From: Alan Cox @ 2009-08-21 15:48 UTC (permalink / raw) To: Alan Stern Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki > Alan, related to this problem is the fact that usb_serial_driver > doesn't include a "hangup" method. I'm not sure that making > serial_hangup() call serial_do_down() is correct, but if it is then > shouldn't we call port->serial->type->open() afterwards? Otherwise the > lower driver can't know that the port is still open. After a hangup the port isn't open (at the physical level anyway). It may be re-opened by another open() call later but the original user lost access to it and shouldn't touch the h/w post hangup completion. > Furthermore, shouldn't we check ASYNCB_INITIALIZED in serial_close()? Possibly - I was in the middle of debugging the newest bits when Linus annoyed me. Certainly there are issues in the current code if you get a hangup while waiting for open to complete. I fixed that in the patches I sent Greg but didn't finish debugging it. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 15:48 ` Alan Cox @ 2009-08-21 17:39 ` Alan Stern 2009-08-21 18:42 ` Alan Cox 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-21 17:39 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Fri, 21 Aug 2009, Alan Cox wrote: > > Alan, related to this problem is the fact that usb_serial_driver > > doesn't include a "hangup" method. I'm not sure that making > > serial_hangup() call serial_do_down() is correct, but if it is then > > shouldn't we call port->serial->type->open() afterwards? Otherwise the > > lower driver can't know that the port is still open. > > After a hangup the port isn't open (at the physical level anyway). It may > be re-opened by another open() call later Or, oddly enough, another open() call earlier... > but the original user lost > access to it and shouldn't touch the h/w post hangup completion. Then surely serial_open() should call serial->type->open() _after_ tty_port_block_til_ready(), not before. > > Furthermore, shouldn't we check ASYNCB_INITIALIZED in serial_close()? > > Possibly - I was in the middle of debugging the newest bits when Linus > annoyed me. Certainly there are issues in the current code if you get > a hangup while waiting for open to complete. I fixed that in the patches > I sent Greg but didn't finish debugging it. Well, yes. The way it is now, you get: serial_open() /* first user */ serial->type->open() /* initializes the hardware */ tty_port_block_til_ready() /* returns immediately */ serial_open() /* second user */ serial->type->open skipped because the port is already open tty_port_block_til_ready() /* blocks */ serial_hangup() /* first connection drops */ serial_do_down() serial->type-close() /* resets the hardware */ ... tty_port_block_til_ready() returns Now the second user tries to do stuff but the hardware isn't ready. Instead this should go: serial_open() /* first user */ tty_port_block_til_ready() /* returns immediately */ serial->type->open() /* initializes the hardware */ serial_open() /* second user */ tty_port_block_til_ready() /* blocks */ serial_hangup() /* first connection drops */ serial_do_down() serial->type-close() /* resets the hardware */ ... tty_port_block_til_ready() returns serial->type->open() /* not skipped */ Now the second user can proceed to use the hardware. Or have I misunderstood how this is intended to work? Alan Stern P.S.: Can you explain the reason why tty_port and tty_struct are two separate structures? Isn't the same port always associated with the same tty? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 17:39 ` Alan Stern @ 2009-08-21 18:42 ` Alan Cox 2009-08-21 20:52 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Alan Cox @ 2009-08-21 18:42 UTC (permalink / raw) To: Alan Stern Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki > Then surely serial_open() should call serial->type->open() _after_ > tty_port_block_til_ready(), not before. It needs the hardware active and running to do the block_til_ready > Now the second user tries to do stuff but the hardware isn't ready. > Instead this should go: > > serial_open() /* first user */ > tty_port_block_til_ready() /* returns immediately */ > serial->type->open() /* initializes the hardware */ > > serial_open() /* second user */ > tty_port_block_til_ready() /* blocks */ If the first user succeeded then second should open immediately as the use count is >= 1 already. It is re-opening the open device, unless the hangup occurs first. > > serial_hangup() /* first connection drops */ > serial_do_down() > serial->type-close() /* resets the hardware */ > > ... tty_port_block_til_ready() returns > serial->type->open() /* not skipped */ > > Now the second user can proceed to use the hardware. Or have I > misunderstood how this is intended to work? Usual paths open block_til_ready open returns 0 do stuff close open block_til_ready open returns 0 do stuff hangup (closes hw side) further stuff errors close (does nothing to the hw side tty_port_close knows about this) open block_til_ready hangup open returns error close path called - knows about hangup in tty_close_port Hence the reason it always calls the close path to cleanup hardware and other resources even if open returns an error > > Alan Stern > > P.S.: Can you explain the reason why tty_port and tty_struct are two > separate structures? Isn't the same port always associated with the > same tty? The tty structure is the virtual interface side, the tty_port is the hardware device. Historically the port side varied randomly by device preventing any commonality being extracted into helpers. For most hardware the tty_port lifetime is the physical port lifetime, the tty lifetime is open->final close (or a final kref drop afterwards) It also means eventually that we can have a tty_port and things hung off it for all hardware which means - Most of the locking costs for receiving v hangup go away (as you queue to the tty_port not the tty - ie move the tty_buffer struct) - It becomes possible to have a proper generic console/debug console without hacks and fake tty devices. Most drivers tend to look like open test ASYNC_INITIALIZED init hardware [either in full or clean up partial] set ASYNC_INITIALIZED) any other alloc/counter magic tty->private_data = my stuff block_til_ready return ok/error close if (hung_up) return if (tty->driver_data == NULL) return counts clean up resources if (last && test_clear INITIALIZED) deinit-hardware return ok/error hangup if (initialized & test_clear INITIALIZED) { deinit hardware } which is where I was trying to get the USB code. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 18:42 ` Alan Cox @ 2009-08-21 20:52 ` Alan Stern 2009-08-21 23:16 ` Alan Cox 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-21 20:52 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Fri, 21 Aug 2009, Alan Cox wrote: > > serial_open() /* first user */ > > tty_port_block_til_ready() /* returns immediately */ > > serial->type->open() /* initializes the hardware */ > > > > serial_open() /* second user */ > > tty_port_block_til_ready() /* blocks */ > > If the first user succeeded then second should open immediately as the use > count is >= 1 already. It is re-opening the open device, unless the > hangup occurs first. What about protecting the use counter? In tty_port.c it's always protected by port->lock, but not in serial_open(). Is that a mistake? How are hangups synchronized with opens? Do you rely on the BKL? Suppose a hangup occurs, and do_tty_hangup() marks all the existing file references with hung_up_tty_fops. But before it gets around to calling tty->ops->hangup(), another open occurs. I can't imagine the BKL will prevent this; do_tty_hangup() is so complex it must sleep somewhere. Thus it's possible for __tty_open() to call tty->ops->open() before tty->ops->hangup() is called, which means the open will succeed. The when the driver's hangup routine finally gets around to calling tty_port_hangup(), port->count will be set back to 0. So now we've got an uncounted open file. > Most drivers tend to look like > > open > test ASYNC_INITIALIZED > init hardware > [either in full or clean up partial] > set ASYNC_INITIALIZED) > any other alloc/counter magic > tty->private_data = my stuff tty->driver_data, right? > block_til_ready > return ok/error > > close > if (hung_up) > return > if (tty->driver_data == NULL) > return > counts Is "counts" shorthand for: if (tty_port_close_start(...) == 0) return ? > clean up resources > if (last && test_clear INITIALIZED) How do you check for "last"? Doesn't the fact that we are here mean that there are no remaining open references? > deinit-hardware > return ok/error > > hangup > if (initialized & test_clear INITIALIZED) { What is "initialized" supposed to be? Isn't INITIALIZED enough? > deinit hardware > } > > which is where I was trying to get the USB code. It doesn't look as though we're too far away. Thanks for the detailed explanations. Alan Stern P.S.: Consider this code in tty_port_block_til_ready(): /* if non-blocking mode is set we can pass directly to open unless the port has just hung up or is in another error state */ if ((filp->f_flags & O_NONBLOCK) || (tty->flags & (1 << TTY_IO_ERROR))) { port->flags |= ASYNC_NORMAL_ACTIVE; return 0; } The comment doesn't agree with the logic of the test. Which is wrong? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 20:52 ` Alan Stern @ 2009-08-21 23:16 ` Alan Cox 2009-08-22 2:30 ` Alan Stern 2009-08-23 2:51 ` Alan Stern 0 siblings, 2 replies; 42+ messages in thread From: Alan Cox @ 2009-08-21 23:16 UTC (permalink / raw) To: Alan Stern Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki > What about protecting the use counter? In tty_port.c it's always > protected by port->lock, but not in serial_open(). Is that a mistake? Ah good an easy question to begin with Yes it is in error. > How are hangups synchronized with opens? Do you rely on the BKL? In a sense this is up the driver. hangup can only occur from two paths 1. User triggered hangup (requires open has completed, user has an fd) 2. Driver calls hangup from its interrupt or other similar event handler The core of both hangup and open are still BKL protected against one another (ugly - wants fixing), release_one_dev() liekwise. This is probably inadequate as they may well sleep in various spots > Suppose a hangup occurs, and do_tty_hangup() marks all the existing > file references with hung_up_tty_fops. But before it gets around to > calling tty->ops->hangup(), another open occurs. I can't imagine the > BKL will prevent this; do_tty_hangup() is so complex it must sleep > somewhere. Thus it's possible for __tty_open() to call > tty->ops->open() before tty->ops->hangup() is called, which means the > open will succeed. I don't think that is any different (logically) to the new open occuring just after the hangup. In other words I agree its a race but I am not sure it is of itself an actual problem > The when the driver's hangup routine finally gets around to calling > tty_port_hangup(), port->count will be set back to 0. So now we've got > an uncounted open file. But that would be and I don't immediately see anything preventing it from happening. Or if it can't happen there is a good deal of luck rather than judgement involved 8) The hangup path doesn't sleep until it has set TTY_HUPPED and I think until the tty_kref_put calls are done. The ops->close/hangup can certainly sleep however and would be the first point that hangup sleeps. So it is I think safe that way - but not at all a good design at the moment. On the open side tty_reopen can sleep as can tty_init_dev. block_til_ready ought to be safe as of itself and is coded to avoid the problem. It checks tty_hung_up_p under the port lock before adjusting the port count. hangup takes the same lock when adjusting the port count. tty_hung_up_p relies on the filp operations changes and BKL So I think the tty_port parts work (half through luck) but the serial.c bits may well not and without the BKL it would fall apart totally at the moment. > > > > Most drivers tend to look like > > > > open > > test ASYNC_INITIALIZED > > init hardware > > [either in full or clean up partial] > > set ASYNC_INITIALIZED) > > any other alloc/counter magic > > tty->private_data = my stuff > > tty->driver_data, right? Yes sorry > > > block_til_ready > > return ok/error > > > > close > > if (hung_up) > > return > > if (tty->driver_data == NULL) > > return > > counts > > Is "counts" shorthand for: > > if (tty_port_close_start(...) == 0) > return Usually - but not all drivers use tty_port_close_start yet, some still open code all the open/close posix logic or some variant of it > ? > > > clean up resources > > if (last && test_clear INITIALIZED) > > How do you check for "last"? Doesn't the fact that we are here mean > that there are no remaining open references? It means there are no remaining file references to the handle, but you may have multiple file handles referencing the same tty (eg open /dev/ttyS0 open /dev/ttyS0 produces two handles to one tty. The tty closes at the hardware level when the last file handle reference goes away. This is important because of open /dev/tty, and the like) ie we have a count of users of the file, which on hitting zero calls tty_release_dev and eventually the port close method. we have a separate count above that of opens to the port which we drop by one for each final close of a file handle. > > > deinit-hardware > > return ok/error > > > > hangup > > if (initialized & test_clear INITIALIZED) { > > What is "initialized" supposed to be? Isn't INITIALIZED enough? It depends on the driver. I believe for anything using the helpers it is enough but I may be wrong. > P.S.: Consider this code in tty_port_block_til_ready(): > > /* if non-blocking mode is set we can pass directly to open unless > the port has just hung up or is in another error state */ > if ((filp->f_flags & O_NONBLOCK) || > (tty->flags & (1 << TTY_IO_ERROR))) { > port->flags |= ASYNC_NORMAL_ACTIVE; > return 0; > } > > The comment doesn't agree with the logic of the test. Which is wrong? The code and comment were copied from the original drivers (and occur in several places ;)) The intended logic is if O_NONBLOCK is set succeed immediately if there is a hangup (or other pending error) succeed immediately So if this occurs open hangup we don't do open hangup block for carrier twiddle thumbs ... but do open hangup ok fd = 4 read fd -EIO (ditto for a hangup from say unplugging the hardware where it would make no sense to wait for the carrier) -- "Alan, I'm getting a bit worried about you." -- Linus Torvalds ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 23:16 ` Alan Cox @ 2009-08-22 2:30 ` Alan Stern 2009-08-23 2:51 ` Alan Stern 1 sibling, 0 replies; 42+ messages in thread From: Alan Stern @ 2009-08-22 2:30 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Sat, 22 Aug 2009, Alan Cox wrote: > > What about protecting the use counter? In tty_port.c it's always > > protected by port->lock, but not in serial_open(). Is that a mistake? > > Ah good an easy question to begin with > > Yes it is in error. Okay, I'll fix it. > The core of both hangup and open are still BKL protected against > one another (ugly - wants fixing), release_one_dev() liekwise. This is > probably inadequate as they may well sleep in various spots Would you consider ideas for changing the protection to something else? I don't have anything in mind at the moment -- I need to study the code some more to understand it better. But eventually a possibility may suggest itself. > > > clean up resources > > > if (last && test_clear INITIALIZED) > > > > How do you check for "last"? Doesn't the fact that we are here mean > > that there are no remaining open references? > > It means there are no remaining file references to the handle, but you > may have multiple file handles referencing the same tty So basically this amounts to testing whether port->count == 0? But isn't that already implicit when tty_port_close_start() returns 0? It sounds like this is another little thingy needed only by drivers that don't use the new helpers. > > P.S.: Consider this code in tty_port_block_til_ready(): > > > > /* if non-blocking mode is set we can pass directly to open unless > > the port has just hung up or is in another error state */ > > if ((filp->f_flags & O_NONBLOCK) || > > (tty->flags & (1 << TTY_IO_ERROR))) { > > port->flags |= ASYNC_NORMAL_ACTIVE; > > return 0; > > } > > > > The comment doesn't agree with the logic of the test. Which is wrong? > > The code and comment were copied from the original drivers (and occur in > several places ;)) > > The intended logic is > > if O_NONBLOCK is set > succeed immediately > if there is a hangup (or other pending error) > succeed immediately Got it -- the comment is wrong. It should say something like: /* If non-blocking mode is set or the port is in an error state * then we can return directly; tty_open() will handle everything. */ Thanks, Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 23:16 ` Alan Cox 2009-08-22 2:30 ` Alan Stern @ 2009-08-23 2:51 ` Alan Stern 2009-08-23 16:15 ` Alan Stern 1 sibling, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-23 2:51 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki Alan: There's a problem with the tty->ops->shutdown method. It needs to release the last port reference owned by the current tty. But when was that reference originally acquired? Evidently during the first time serial_open() was called for the current tty. The problem is that serial_open() has no way to know if a particular invocation is the first one for this tty! The ASYNCB_INITIALIZED flag doesn't help, because it might not get set during the first call (i.e., if an error occurs). To do this right, we need a flag in the tty_struct or the tty_port which serial_open() can set when acquiring that first reference and shutdown method can clear. Should I add such a flag? Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-23 2:51 ` Alan Stern @ 2009-08-23 16:15 ` Alan Stern 2009-08-23 16:30 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-23 16:15 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Sat, 22 Aug 2009, Alan Stern wrote: > Alan: > > There's a problem with the tty->ops->shutdown method. It needs to > release the last port reference owned by the current tty. But when was > that reference originally acquired? Evidently during the first time > serial_open() was called for the current tty. > > The problem is that serial_open() has no way to know if a particular > invocation is the first one for this tty! The ASYNCB_INITIALIZED flag > doesn't help, because it might not get set during the first call (i.e., > if an error occurs). > > To do this right, we need a flag in the tty_struct or the tty_port > which serial_open() can set when acquiring that first reference and > shutdown method can clear. Should I add such a flag? Never mind, I figured out an answer. Instead of a new flag, the routine can simply test whether or not tty->driver_data has been set. One more question: Under what circumstances should serial_open() increment port->port.count? It seems that this should happen on every call unless tty->driver_data is NULL or filp has been hung up. Is that right? I have a big patch almost ready for testing. Unfortunately I don't have access to my usual hardware right now, so I can't test it until the middle of the week. Bruno, if you like I will send you the patch when it looks okay and you can try it out. Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-23 16:15 ` Alan Stern @ 2009-08-23 16:30 ` Bruno Prémont 2009-08-24 1:24 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-23 16:30 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Sun, 23 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > I have a big patch almost ready for testing. Unfortunately I don't > have access to my usual hardware right now, so I can't test it until > the middle of the week. Bruno, if you like I will send you the patch > when it looks okay and you can try it out. Fine for me, I can test every week-day during evening as well as during week-end (European time, UTC+2). If there are any specific tests (other than the surviving of disconnect) that I shall run, just ask! Bruno ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-23 16:30 ` Bruno Prémont @ 2009-08-24 1:24 ` Alan Stern 2009-08-24 20:15 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-24 1:24 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Sun, 23 Aug 2009, Bruno [UTF-8] Prémont wrote: > On Sun, 23 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > > I have a big patch almost ready for testing. Unfortunately I don't > > have access to my usual hardware right now, so I can't test it until > > the middle of the week. Bruno, if you like I will send you the patch > > when it looks okay and you can try it out. > > Fine for me, I can test every week-day during evening as well as during > week-end (European time, UTC+2). > If there are any specific tests (other than the surviving of disconnect) > that I shall run, just ask! Here it is. This is meant to apply on top of gregkh-all-2.6.31-rc6; it replaces the small patch you tried earlier. In fact this ought to be split up into at least four individual patches, but you can test it all in one piece. Surviving disconnect, ability to reconnect, deallocating memory (destroy_serial and port_free) at the right time... Anything else you can think of. Alan Stern P.S.: You may already have the first part, with the changes to tty_port.c. Index: usb-2.6/drivers/char/tty_port.c =================================================================== --- usb-2.6.orig/drivers/char/tty_port.c +++ usb-2.6/drivers/char/tty_port.c @@ -100,7 +100,7 @@ EXPORT_SYMBOL(tty_port_tty_set); static void tty_port_shutdown(struct tty_port *port) { if (port->ops->shutdown && - test_and_clear_bit(ASYNC_INITIALIZED, &port->flags)) + test_and_clear_bit(ASYNCB_INITIALIZED, &port->flags)) port->ops->shutdown(port); } @@ -311,7 +311,7 @@ int tty_port_close_start(struct tty_port port->ops->drop(port); return 0; } - set_bit(ASYNC_CLOSING, &port->flags); + set_bit(ASYNCB_CLOSING, &port->flags); tty->closing = 1; spin_unlock_irqrestore(&port->lock, flags); /* Don't block on a stalled port, just pull the chain */ Index: usb-2.6/drivers/usb/serial/usb-serial.c =================================================================== --- usb-2.6.orig/drivers/usb/serial/usb-serial.c +++ usb-2.6/drivers/usb/serial/usb-serial.c @@ -126,8 +126,10 @@ static void return_serial(struct usb_ser dbg("%s", __func__); + mutex_lock(&table_lock); for (i = 0; i < serial->num_ports; ++i) serial_table[serial->minor + i] = NULL; + mutex_unlock(&table_lock); } static void destroy_serial(struct kref *kref) @@ -146,35 +148,24 @@ static void destroy_serial(struct kref * serial->type->release(serial); - for (i = 0; i < serial->num_ports; ++i) { + for (i = 0; i < serial->num_port_pointers; ++i) { port = serial->port[i]; if (port) - put_device(&port->dev); - } - - /* If this is a "fake" port, we have to clean it up here, as it will - * not get cleaned up in port_release() as it was never registered with - * the driver core */ - if (serial->num_ports < serial->num_port_pointers) { - for (i = serial->num_ports; - i < serial->num_port_pointers; ++i) { - port = serial->port[i]; - if (port) - port_free(port); - } + port_free(port); } usb_put_dev(serial->dev); - - /* free up any memory that we allocated */ kfree(serial); } +void usb_serial_get(struct usb_serial *serial) +{ + kref_get(&serial->kref); +} + void usb_serial_put(struct usb_serial *serial) { - mutex_lock(&table_lock); kref_put(&serial->kref, destroy_serial); - mutex_unlock(&table_lock); } /***************************************************************************** @@ -186,16 +177,13 @@ static int serial_open (struct tty_struc struct usb_serial_port *port; unsigned int portNumber; int retval = 0; - int first = 0; dbg("%s", __func__); /* get the serial object associated with this tty pointer */ serial = usb_serial_get_by_index(tty->index); - if (!serial) { - tty->driver_data = NULL; + if (!serial) return -ENODEV; - } mutex_lock(&serial->disc_mutex); portNumber = tty->index - serial->minor; @@ -209,24 +197,42 @@ static int serial_open (struct tty_struc * to be acquired while serial->disc_mutex is held. */ mutex_unlock(&serial->disc_mutex); - if (retval) - goto bailout_serial_put; + /* serial is pinned by port->dev, so we can drop its reference */ + usb_serial_put(serial); + + /* Associate this tty with our port structure, if it isn't already + * associated. This reference will be dropped in serial_shutdown(), + * when the TTY layer is finished with the tty. + */ + if (retval == 0 && !tty->driver_data) { + tty->driver_data = port; + get_device(&port->dev); + } + + /* Every open call associated with a port must increment the + * port's use counter, even if the call fails, unless the tty + * has been hung up. + */ + if (tty->driver_data) { + spin_lock_irq(&port->port.lock); + if (!tty_hung_up_p(filp)) + ++port->port.count; + spin_unlock_irq(&port->port.lock); + tty_port_tty_set(&port->port, tty); + } + + if (retval) + return retval; if (mutex_lock_interruptible(&port->mutex)) { retval = -ERESTARTSYS; goto bailout_port_put; } - ++port->port.count; - - /* set up our port structure making the tty driver - * remember our port object, and us it */ - tty->driver_data = port; - tty_port_tty_set(&port->port, tty); - - /* If the console is attached, the device is already open */ - if (port->port.count == 1 && !port->console) { - first = 1; + /* Do the device-specific open only if the hardware isn't + * already initialized. + */ + if (!test_bit(ASYNCB_INITIALIZED, &port->port.flags)) { /* lock this module before we call it * this may fail, which means we must bail out, * safe because we are called with BKL held */ @@ -243,8 +249,6 @@ static int serial_open (struct tty_struc if (retval) goto bailout_module_put; - /* only call the device specific open if this - * is the first time the port is opened */ retval = serial->type->open(tty, port); if (retval) goto bailout_interface_put; @@ -252,32 +256,26 @@ static int serial_open (struct tty_struc set_bit(ASYNCB_INITIALIZED, &port->port.flags); } mutex_unlock(&port->mutex); + + /* The port object was pinned by the tty when the association + * was made above. We don't need an extra reference for each + * open call. + */ + put_device(&port->dev); + /* Now do the correct tty layer semantics */ retval = tty_port_block_til_ready(&port->port, tty, filp); - if (retval == 0) { - if (!first) - usb_serial_put(serial); - return 0; - } - mutex_lock(&port->mutex); - if (first == 0) - goto bailout_mutex_unlock; - /* Undo the initial port actions */ - mutex_lock(&serial->disc_mutex); -bailout_interface_put: + return retval; + + bailout_interface_put: usb_autopm_put_interface(serial->interface); -bailout_module_put: + bailout_module_put: mutex_unlock(&serial->disc_mutex); module_put(serial->type->driver.owner); -bailout_mutex_unlock: - port->port.count = 0; - tty->driver_data = NULL; - tty_port_tty_set(&port->port, NULL); + bailout_mutex_unlock: mutex_unlock(&port->mutex); -bailout_port_put: + bailout_port_put: put_device(&port->dev); -bailout_serial_put: - usb_serial_put(serial); return retval; } @@ -287,56 +285,34 @@ bailout_serial_put: * * Shut down a USB port unless it is the console. We never shut down the * console hardware as it will always be in use. - * - * Don't free any resources at this point */ static void serial_do_down(struct usb_serial_port *port) { - struct usb_serial_driver *drv = port->serial->type; + struct usb_serial *serial = port->serial; + struct usb_serial_driver *drv = serial->type; /* The console is magical, do not hang up the console hardware or there will be tears */ if (port->console) return; + /* Don't call the close method if the hardware hasn't been + * initialized. + */ + if (!test_and_clear_bit(ASYNCB_INITIALIZED, &port->port.flags)) + return; + mutex_lock(&port->mutex); if (drv->close) drv->close(port); mutex_unlock(&port->mutex); -} - -/** - * serial_do_free - free resources post close/hangup - * @port: port to free up - * - * Do the resource freeing and refcount dropping for the port. We must - * be careful about ordering and we must avoid freeing up the console. - * - * Called when the last tty kref is dropped. - */ -static void serial_do_free(struct tty_struct *tty) -{ - struct usb_serial_port *port = tty->driver_data; - struct usb_serial *serial; - struct module *owner; + module_put(drv->driver.owner); - /* The console is magical, do not hang up the console hardware - or there will be tears */ - if (port == NULL || port->console) - return; - - serial = port->serial; - owner = serial->type->driver.owner; - put_device(&port->dev); - /* Mustn't dereference port any more */ mutex_lock(&serial->disc_mutex); if (!serial->disconnected) usb_autopm_put_interface(serial->interface); mutex_unlock(&serial->disc_mutex); - usb_serial_put(serial); - /* Mustn't dereference serial any more */ - module_put(owner); } static void serial_close(struct tty_struct *tty, struct file *filp) @@ -348,21 +324,45 @@ static void serial_close(struct tty_stru dbg("%s - port %d", __func__, port->number); + if (tty_hung_up_p(filp)) + return; if (tty_port_close_start(&port->port, tty, filp) == 0) return; + serial_do_down(port); tty_port_close_end(&port->port, tty); tty_port_tty_set(&port->port, NULL); - } static void serial_hangup(struct tty_struct *tty) { struct usb_serial_port *port = tty->driver_data; + serial_do_down(port); tty_port_hangup(&port->port); - /* We must not free port yet - the USB serial layer depends on it's - continued existence */ +} + +/** + * serial_shutdown - free resources post close/hangup + * @tty: TTY whose port should be freed + * + * Do the resource freeing and refcount dropping for the port. We must + * avoid freeing up the console. + * + * Called when the last tty kref is dropped. + */ +static void serial_shutdown(struct tty_struct *tty) +{ + struct usb_serial_port *port = tty->driver_data; + + /* The console is magical, do not hang up the console hardware + or there will be tears */ + if (port == NULL || port->console) + return; + + /* Release the reference owned by the tty object */ + tty->driver_data = NULL; + put_device(&port->dev); } static int serial_write(struct tty_struct *tty, const unsigned char *buf, @@ -581,7 +581,9 @@ static void port_release(struct device * struct usb_serial_port *port = to_usb_serial_port(dev); dbg ("%s - %s", __func__, dev_name(dev)); - port_free(port); + + /* The port structure will be freed in destroy_serial(). */ + usb_serial_put(port->serial); } static void kill_traffic(struct usb_serial_port *port) @@ -945,10 +947,16 @@ int usb_serial_probe(struct usb_interfac goto probe_error; tty_port_init(&port->port); port->port.ops = &serial_port_ops; - port->serial = serial; spin_lock_init(&port->lock); mutex_init(&port->mutex); INIT_WORK(&port->work, usb_serial_port_work); + port->dev.parent = &interface->dev; + port->dev.driver = NULL; + port->dev.bus = &usb_serial_bus_type; + port->dev.release = &port_release; + device_initialize(&port->dev); + port->serial = serial; + usb_serial_get(serial); serial->port[i] = port; } @@ -1097,15 +1105,10 @@ int usb_serial_probe(struct usb_interfac /* register all of the individual ports with the driver core */ for (i = 0; i < num_ports; ++i) { port = serial->port[i]; - port->dev.parent = &interface->dev; - port->dev.driver = NULL; - port->dev.bus = &usb_serial_bus_type; - port->dev.release = &port_release; - dev_set_name(&port->dev, "ttyUSB%d", port->number); dbg ("%s - registering %s", __func__, dev_name(&port->dev)); port->dev_state = PORT_REGISTERING; - retval = device_register(&port->dev); + retval = device_add(&port->dev); if (retval) { dev_err(&port->dev, "Error registering port device, " "continuing\n"); @@ -1123,41 +1126,13 @@ exit: return 0; probe_error: - for (i = 0; i < num_bulk_in; ++i) { - port = serial->port[i]; - if (!port) - continue; - usb_free_urb(port->read_urb); - kfree(port->bulk_in_buffer); - } - for (i = 0; i < num_bulk_out; ++i) { - port = serial->port[i]; - if (!port) - continue; - if (port->write_fifo) - kfifo_free(port->write_fifo); - usb_free_urb(port->write_urb); - kfree(port->bulk_out_buffer); - } - for (i = 0; i < num_interrupt_in; ++i) { - port = serial->port[i]; - if (!port) - continue; - usb_free_urb(port->interrupt_in_urb); - kfree(port->interrupt_in_buffer); - } - for (i = 0; i < num_interrupt_out; ++i) { + /* free all the ports, along with their URBs */ + for (i = 0; i < serial->num_port_pointers; ++i) { port = serial->port[i]; - if (!port) - continue; - usb_free_urb(port->interrupt_out_urb); - kfree(port->interrupt_out_buffer); + if (port) + put_device(&port->dev); } - - /* free up any memory that we allocated */ - for (i = 0; i < serial->num_port_pointers; ++i) - kfree(serial->port[i]); - kfree(serial); + usb_serial_put(serial); return -EIO; } EXPORT_SYMBOL_GPL(usb_serial_probe); @@ -1205,6 +1180,7 @@ void usb_serial_disconnect(struct usb_in port->dev_state = PORT_UNREGISTERED; } } + put_device(&port->dev); } serial->type->disconnect(serial); @@ -1269,7 +1245,7 @@ static const struct tty_operations seria .chars_in_buffer = serial_chars_in_buffer, .tiocmget = serial_tiocmget, .tiocmset = serial_tiocmset, - .shutdown = serial_do_free, + .shutdown = serial_shutdown, .install = serial_install, .proc_fops = &serial_proc_fops, }; ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-24 1:24 ` Alan Stern @ 2009-08-24 20:15 ` Bruno Prémont 2009-08-25 1:42 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-24 20:15 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Sun, 23 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > On Sun, 23 Aug 2009, Bruno [UTF-8] Prémont wrote: > > > On Sun, 23 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > > > I have a big patch almost ready for testing. Unfortunately I > > > don't have access to my usual hardware right now, so I can't test > > > it until the middle of the week. Bruno, if you like I will send > > > you the patch when it looks okay and you can try it out. > > > > Fine for me, I can test every week-day during evening as well as > > during week-end (European time, UTC+2). > > If there are any specific tests (other than the surviving of > > disconnect) that I shall run, just ask! > > Here it is. This is meant to apply on top of gregkh-all-2.6.31-rc6; > it replaces the small patch you tried earlier. In fact this ought to > be split up into at least four individual patches, but you can test it > all in one piece. > > Surviving disconnect, ability to reconnect, deallocating memory > (destroy_serial and port_free) at the right time... Anything else > you can think of. > > Alan Stern > > P.S.: You may already have the first part, with the changes to > tty_port.c. Yep, that one was already included The patch does not work properly: When I plug in the USB2serial converter (be it ftdi or pl2302) device node is created properly and minicom can use it. When I exit minicom I can no longer start it again, eventually I get a killed minicom with NULL-dereference A rmmod/modprobe cycle works but the end result is no device node created by udev and udev's path_id helper is stuck. (unable to determine where for now as netconsole causes trouble with netdev polling) I will have a deeper look tomorrow as this evening is already over. Bruno Trace result for ftdi device: [ 75.620038] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 75.838941] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 75.844208] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 75.849432] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 75.854628] usb 1-2: Manufacturer: FTDI [ 75.859783] usb 1-2: SerialNumber: FTS55QK6 [ 75.866989] usb 1-2: configuration #1 chosen from 1 choice [ 76.001724] usbcore: registered new interface driver usbserial [ 76.006901] usbserial: USB Serial Driver core [ 76.085962] USB Serial support registered for FTDI USB Serial Device [ 76.091471] usb 1-2: Ignoring serial port reserved for JTAG [ 76.093889] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 76.096350] usb 1-2: Detected FT2232C [ 76.098739] usb 1-2: Number of endpoints 2 [ 76.101418] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 76.103792] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 76.106153] usb 1-2: Setting MaxPacketSize 64 [ 76.111012] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 76.113433] usbcore: registered new interface driver ftdi_sio [ 76.115797] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 163.471333] BUG: unable to handle kernel NULL pointer dereference at 00000064 [ 163.471531] IP: [<c115f7ae>] tty_open+0x11e/0x4b0 [ 163.471650] *pde = 00000000 [ 163.471730] Oops: 0000 [#1] [ 163.471809] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 163.471944] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd snd_page_alloc ehci_hcd pcspkr i2c_i801 uhci_hcd usbcore crc_ccitt [ 163.472927] [ 163.472967] Pid: 2157, comm: minicom Tainted: G M (2.6.31-rc6-gregkh #2) TravelMate 660 [ 163.473148] EIP: 0060:[<c115f7ae>] EFLAGS: 00010246 CPU: 0 [ 163.473247] EIP is at tty_open+0x11e/0x4b0 [ 163.473338] EAX: dba89000 EBX: dbdb2480 ECX: 00000000 EDX: 00000000 [ 163.473449] ESI: dd24d400 EDI: 0bc00000 EBP: db646e70 ESP: db646e4c [ 163.473575] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 163.473673] Process minicom (pid: 2157, ti=db646000 task=dd9ae7c0 task.ti=db646000) [ 163.473833] Stack: [ 163.473873] dbdb2484 dbe24e00 dba8e67c 00000902 00000100 00000000 00000000 dbdb2488 [ 163.474133] <0> dba8e67c db646e8c c1077246 dbe24e00 db646e98 dbe24e00 dba8e67c 00000000 [ 163.474431] <0> db646ea8 c1072fdf dd8afb00 dd524f00 dbe24e00 db646ef4 dbe24e00 db646ec4 [ 163.474751] Call Trace: [ 163.474808] [<c1077246>] ? chrdev_open+0x96/0x140 [ 163.474918] [<c1072fdf>] ? __dentry_open+0x9f/0x250 [ 163.475012] [<c1073279>] ? nameidata_to_filp+0x59/0x70 [ 163.475124] [<c10771b0>] ? chrdev_open+0x0/0x140 [ 163.475214] [<c107f569>] ? do_filp_open+0x269/0x890 [ 163.475324] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 163.475417] [<c1072da7>] ? do_sys_open+0x57/0x140 [ 163.475525] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 163.475619] [<c1072ef9>] ? sys_open+0x29/0x40 [ 163.475719] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 163.475811] Code: d0 89 45 f0 8d 43 04 89 45 dc e8 9e f7 f9 ff 85 db 74 ca 85 f6 0f 84 22 02 00 00 80 be 84 00 00 00 00 8b 56 08 0f 88 32 01 00 00 <66> 83 7a 64 04 75 0b 66 83 7a 66 01 0f 84 05 01 00 00 ff 86 88 [ 163.477244] EIP: [<c115f7ae>] tty_open+0x11e/0x4b0 SS:ESP 0068:db646e4c [ 163.477410] CR2: 0000000000000064 [ 163.477472] ---[ end trace e2a30538356d938d ]--- # Plug-in # minicom # exit minicom # minicom # (it can't open serial port & exits) # minicom # -> havok # rmmod + modprobe # minicom # (ad infinitum as no dev node, # udev fails to recreate device node: hangs on path_id) Similar results for pl2302: [ 69.260039] usb 1-1: new full speed USB device using uhci_hcd and address 2 [ 69.426990] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 69.427000] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 69.427008] usb 1-1: Product: USB-Serial Controller [ 69.427015] usb 1-1: Manufacturer: Prolific Technology Inc. [ 69.427242] usb 1-1: configuration #1 chosen from 1 choice [ 69.558897] usbcore: registered new interface driver usbserial [ 69.558906] usbserial: USB Serial Driver core [ 69.612215] USB Serial support registered for pl2303 [ 69.612267] pl2303 1-1:1.0: pl2303 converter detected [ 69.624165] usb 1-1: pl2303 converter now attached to ttyUSB0 [ 69.624205] usbcore: registered new interface driver pl2303 [ 69.624211] pl2303: Prolific PL2303 USB to serial adaptor driver [ 140.790070] usb 1-1: USB disconnect, address 2 [ 140.793165] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 140.796051] pl2303 1-1:1.0: device disconnected [ 147.280036] usb 1-1: new full speed USB device using uhci_hcd and address 3 [ 147.446990] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 147.449674] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 147.452428] usb 1-1: Product: USB-Serial Controller [ 147.455149] usb 1-1: Manufacturer: Prolific Technology Inc. [ 147.459847] usb 1-1: configuration #1 chosen from 1 choice [ 147.466047] pl2303 1-1:1.0: pl2303 converter detected [ 147.479158] usb 1-1: pl2303 converter now attached to ttyUSB0 [ 168.770687] BUG: unable to handle kernel paging request at 697665c8 [ 168.770876] IP: [<c115f7ae>] tty_open+0x11e/0x4b0 [ 168.770995] *pde = 00000000 [ 168.771075] Oops: 0000 [#1] [ 168.771154] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 168.771304] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer ehci_hcd snd uhci_hcd usbcore pcspkr snd_page_alloc nsc_ircc i2c_i801 irda crc_ccitt [ 168.772283] [ 168.772322] Pid: 2166, comm: minicom Tainted: G M (2.6.31-rc6-gregkh #2) TravelMate 660 [ 168.772503] EIP: 0060:[<c115f7ae>] EFLAGS: 00010202 CPU: 0 [ 168.772602] EIP is at tty_open+0x11e/0x4b0 [ 168.772694] EAX: db661800 EBX: db07c6c0 ECX: 00000000 EDX: 69766564 [ 168.772804] ESI: db17e000 EDI: 0bc00000 EBP: db17ae70 ESP: db17ae4c [ 168.772944] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 168.773041] Process minicom (pid: 2166, ti=db17a000 task=dd9ae7c0 task.ti=db17a000) [ 168.773202] Stack: [ 168.773242] db07c6c4 dd07d200 dd33c4f4 00000902 00000100 00000000 00000000 db07c6c8 [ 168.773502] <0> dd33c4f4 db17ae8c c1077246 dd07d200 00000000 dd07d200 dd33c4f4 00000000 [ 168.773799] <0> db17aea8 c1072fdf dd8d2680 dd502e80 dd07d200 db17aef4 dd07d200 db17aec4 [ 168.774120] Call Trace: [ 168.774177] [<c1077246>] ? chrdev_open+0x96/0x140 [ 168.774287] [<c1072fdf>] ? __dentry_open+0x9f/0x250 [ 168.774380] [<c1073279>] ? nameidata_to_filp+0x59/0x70 [ 168.774492] [<c10771b0>] ? chrdev_open+0x0/0x140 [ 168.774582] [<c107f569>] ? do_filp_open+0x269/0x890 [ 168.774691] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 168.774784] [<c1072da7>] ? do_sys_open+0x57/0x140 [ 168.774893] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 168.774987] [<c1072ef9>] ? sys_open+0x29/0x40 [ 168.775088] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 168.775180] Code: d0 89 45 f0 8d 43 04 89 45 dc e8 9e f7 f9 ff 85 db 74 ca 85 f6 0f 84 22 02 00 00 80 be 84 00 00 00 00 8b 56 08 0f 88 32 01 00 00 <66> 83 7a 64 04 75 0b 66 83 7a 66 01 0f 84 05 01 00 00 ff 86 88 [ 168.776606] EIP: [<c115f7ae>] tty_open+0x11e/0x4b0 SS:ESP 0068:db17ae4c [ 168.776772] CR2: 00000000697665c8 [ 168.776836] ---[ end trace f7ba75fd75a3f993 ]--- For both cases EIP is at: drivers/char/tty_io.c:1253: 1246:static int tty_reopen(struct tty_struct *tty) 1247:{ 1248: struct tty_driver *driver = tty->driver; ... 1253: if (driver->type == TTY_DRIVER_TYPE_PTY && 1254: driver->subtype == PTY_TYPE_MASTER) { ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-24 20:15 ` Bruno Prémont @ 2009-08-25 1:42 ` Alan Stern 2009-08-25 20:19 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-25 1:42 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Mon, 24 Aug 2009, Bruno [UTF-8] Prémont wrote: > The patch does not work properly: > > When I plug in the USB2serial converter (be it ftdi or pl2302) device > node is created properly and minicom can use it. > > When I exit minicom I can no longer start it again, eventually I get > a killed minicom with NULL-dereference > > A rmmod/modprobe cycle works but the end result is no device node > created by udev and udev's path_id helper is stuck. (unable to > determine where for now as netconsole causes trouble with netdev > polling) > I will have a deeper look tomorrow as this evening is already over. > > Bruno > > > Trace result for ftdi device: > [ 76.115797] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver > [ 163.471333] BUG: unable to handle kernel NULL pointer dereference at 00000064 > [ 163.471531] IP: [<c115f7ae>] tty_open+0x11e/0x4b0 > [ 163.471650] *pde = 00000000 > [ 163.471730] Oops: 0000 [#1] > [ 163.471809] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input > [ 163.471944] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd snd_page_alloc ehci_hcd pcspkr i2c_i801 uhci_hcd usbcore crc_ccitt > [ 163.472927] > [ 163.472967] Pid: 2157, comm: minicom Tainted: G M (2.6.31-rc6-gregkh #2) TravelMate 660 > [ 163.473148] EIP: 0060:[<c115f7ae>] EFLAGS: 00010246 CPU: 0 > [ 163.473247] EIP is at tty_open+0x11e/0x4b0 > For both cases EIP is at: > drivers/char/tty_io.c:1253: > 1246:static int tty_reopen(struct tty_struct *tty) > 1247:{ > 1248: struct tty_driver *driver = tty->driver; > ... > 1253: if (driver->type == TTY_DRIVER_TYPE_PTY && > 1254: driver->subtype == PTY_TYPE_MASTER) { Okay, thanks for trying it out. Apparently the tty isn't getting removed from the driver the way it should when minicom closes it the first time. And no wonder -- I just realized that my new serial_shutdown() routine doesn't call tty_shutdown(tty). Try inserting such a call right before tty->driver_data gets set to NULL. The division of labor between the TTY core and the lower drivers makes very little sense... Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-25 1:42 ` Alan Stern @ 2009-08-25 20:19 ` Bruno Prémont 2009-08-25 23:42 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-25 20:19 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Mon, 24 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > Apparently the tty isn't getting removed from the driver the way it > should when minicom closes it the first time. And no wonder -- I just > realized that my new serial_shutdown() routine doesn't call > tty_shutdown(tty). Try inserting such a call right before > tty->driver_data gets set to NULL. Done that, it brings us to n_tty_set_termios() this time: [ 107.990039] usb 2-2: new full speed USB device using uhci_hcd and address 2 [ 108.208982] usb 2-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 108.208992] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 108.209000] usb 2-2: Product: SheevaPlug JTAGKey FT2232D B [ 108.209007] usb 2-2: Manufacturer: FTDI [ 108.209013] usb 2-2: SerialNumber: FTS55QK6 [ 108.209243] usb 2-2: configuration #1 chosen from 1 choice [ 108.323938] usbcore: registered new interface driver usbserial [ 108.323943] usbserial: USB Serial Driver core [ 108.357581] USB Serial support registered for FTDI USB Serial Device [ 108.357819] usb 2-2: Ignoring serial port reserved for JTAG [ 108.357924] ftdi_sio 2-2:1.1: FTDI USB Serial Device converter detected [ 108.357990] usb 2-2: Detected FT2232C [ 108.357996] usb 2-2: Number of endpoints 2 [ 108.358003] usb 2-2: Endpoint 1 MaxPacketSize 64 [ 108.358009] usb 2-2: Endpoint 2 MaxPacketSize 64 [ 108.358015] usb 2-2: Setting MaxPacketSize 64 [ 108.360175] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 108.360216] usbcore: registered new interface driver ftdi_sio [ 108.360223] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 200.248102] BUG: unable to handle kernel NULL pointer dereference at 0000000c [ 200.248257] IP: [<c115ff36>] n_tty_set_termios+0x1a6/0x410 [ 200.248369] *pde = 00000000 [ 200.248429] Oops: 0000 [#1] [ 200.248489] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input [ 200.248607] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec nsc_ircc ac97_bus irda snd_pcm pcspkr i2c_i801 snd_timer uhci_hcd ehci_hcd snd snd_page_alloc crc_ccitt usbcore [ 200.249280] [ 200.249317] Pid: 2155, comm: minicom Tainted: G M (2.6.31-rc6-gregkh #2) TravelMate 660 [ 200.249466] EIP: 0060:[<c115ff36>] EFLAGS: 00010246 CPU: 0 [ 200.249563] EIP is at n_tty_set_termios+0x1a6/0x410 [ 200.249649] EAX: 00000000 EBX: dbdd9000 ECX: 00000000 EDX: 00000000 [ 200.249757] ESI: 00000000 EDI: 00000000 EBP: dd2dade8 ESP: dd2dadd8 [ 200.249866] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 200.249962] Process minicom (pid: 2155, ti=dd2da000 task=dd91b500 task.ti=dd2da000) [ 200.250090] Stack: [ 200.250129] c11616ab dbdd9000 dbdd9000 00000000 dd2dadf4 c11617db dbaf20e8 dd2dae04 [ 200.250312] <0> c1164280 dbdd9000 dbdd9000 dd2dae20 c1164432 dbaf20e8 dbdd9000 dbdd9000 [ 200.250514] <0> db953a80 dbdd9000 dd2dae44 c115f5b9 dd2dae7c dd2daef4 00000000 00000000 [ 200.250722] Call Trace: [ 200.250773] [<c11616ab>] ? reset_buffer_flags+0xab/0xe0 [ 200.250870] [<c11617db>] ? n_tty_open+0x3b/0x90 [ 200.250954] [<c1164280>] ? tty_ldisc_open+0x30/0x50 [ 200.251044] [<c1164432>] ? tty_ldisc_setup+0x22/0x70 [ 200.251135] [<c115f5b9>] ? tty_init_dev+0x89/0x160 [ 200.251223] [<c115f9fc>] ? tty_open+0x36c/0x4b0 [ 200.251310] [<c1077246>] ? chrdev_open+0x96/0x140 [ 200.251400] [<c1072fdf>] ? __dentry_open+0x9f/0x250 [ 200.251490] [<c1073279>] ? nameidata_to_filp+0x59/0x70 [ 200.251584] [<c10771b0>] ? chrdev_open+0x0/0x140 [ 200.251672] [<c107f569>] ? do_filp_open+0x269/0x890 [ 200.251762] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 200.251852] [<c1072da7>] ? do_sys_open+0x57/0x140 [ 200.251943] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 200.252035] [<c1072ef9>] ? sys_open+0x29/0x40 [ 200.252116] [<c1002e08>] ? sysenter_do_call+0x12/0x26 [ 200.252205] Code: 31 c0 f3 ab 0f b6 93 2c 01 00 00 31 f6 8b 83 60 01 00 00 8b 7b 30 89 b3 74 03 00 00 80 e2 fd 89 83 78 03 00 00 88 93 2c 01 00 00 <8b> 47 0c 83 e0 02 0f 85 8a fe ff ff 8b 8b 64 01 00 00 85 c9 0f [ 200.252995] EIP: [<c115ff36>] n_tty_set_termios+0x1a6/0x410 SS:ESP 0068:dd2dadd8 [ 200.253134] CR2: 000000000000000c [ 200.253225] ---[ end trace f4b79a25ac2c3be9 ]--- My actions: plug-in ftdi run minicom exit minicom run minicom -> bang Bang at: /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1456 1449: if (canon_change) { 1450: memset(&tty->read_flags, 0, sizeof tty->read_flags); 1451: tty->canon_head = tty->read_tail; 1452: tty->canon_data = 0; 1453: tty->erasing = 0; 1454: } 1455: 1456: if (canon_change && !L_ICANON(tty) && tty->read_cnt) 1457: wake_up_interruptible(&tty->read_wait); Not sure which part of the if() it is that explodes, I would guess it's !L_ICANON(tty): #define ICANON 0000002 #define _L_FLAG(tty, f) ((tty)->termios->c_lflag & (f)) #define L_ICANON(tty) _L_FLAG((tty), ICANON) => if (canon_change && !((tty)->termios->c_lflag & (ICANON)) && tty->read_cnt) => tty->termios is probably NULL Anyhow, here is the matching extract of objdump for n_tty.o: /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1453 37f: 0f b6 93 2c 01 00 00 movzbl 0x12c(%ebx),%edx /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1452 386: 31 f6 xor %esi,%esi /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1451 388: 8b 83 60 01 00 00 mov 0x160(%ebx),%eax /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1456 38e: 8b 7b 30 mov 0x30(%ebx),%edi /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1452 391: 89 b3 74 03 00 00 mov %esi,0x374(%ebx) /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1453 397: 80 e2 fd and $0xfd,%dl /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1451 39a: 89 83 78 03 00 00 mov %eax,0x378(%ebx) /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1453 3a0: 88 93 2c 01 00 00 mov %dl,0x12c(%ebx) /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1456 > 3a6: 8b 47 0c mov 0xc(%edi),%eax 3a9: 83 e0 02 and $0x2,%eax 3ac: 0f 85 8a fe ff ff jne 23c <n_tty_set_termios+0x3c> 3b2: 8b 8b 64 01 00 00 mov 0x164(%ebx),%ecx 3b8: 85 c9 test %ecx,%ecx 3ba: 0f 84 7c fe ff ff je 23c <n_tty_set_termios+0x3c> Some further notes: - disconnect causes the device to vanish and minicom to tell so. Quit minicom works without complaint. Any restart produces the same effect as above - after this trace some lock remains taken that causes processes to stall (processes ending up in D state) - when booting with this kernel some part of the init sequence never shows up on screen (e.g. everything from init's runlevel 3 is missing and getty's prompt shows up with some delay compared to gettys on other VTs. Bruno ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-25 20:19 ` Bruno Prémont @ 2009-08-25 23:42 ` Alan Stern 2009-08-26 20:32 ` Bruno Prémont 0 siblings, 1 reply; 42+ messages in thread From: Alan Stern @ 2009-08-25 23:42 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Tue, 25 Aug 2009, Bruno [UTF-8] Prémont wrote: > On Mon, 24 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > > Apparently the tty isn't getting removed from the driver the way it > > should when minicom closes it the first time. And no wonder -- I just > > realized that my new serial_shutdown() routine doesn't call > > tty_shutdown(tty). Try inserting such a call right before > > tty->driver_data gets set to NULL. > > Done that, it brings us to n_tty_set_termios() this time: > [ 200.248102] BUG: unable to handle kernel NULL pointer dereference at 0000000c > [ 200.248257] IP: [<c115ff36>] n_tty_set_termios+0x1a6/0x410 > My actions: > plug-in ftdi > run minicom > exit minicom > run minicom -> bang > > Bang at: > /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1456 > > 1449: if (canon_change) { > 1450: memset(&tty->read_flags, 0, sizeof tty->read_flags); > 1451: tty->canon_head = tty->read_tail; > 1452: tty->canon_data = 0; > 1453: tty->erasing = 0; > 1454: } > 1455: > 1456: if (canon_change && !L_ICANON(tty) && tty->read_cnt) > 1457: wake_up_interruptible(&tty->read_wait); > > Not sure which part of the if() it is that explodes, I would guess > it's !L_ICANON(tty): > > #define ICANON 0000002 > #define _L_FLAG(tty, f) ((tty)->termios->c_lflag & (f)) > #define L_ICANON(tty) _L_FLAG((tty), ICANON) > => > if (canon_change && !((tty)->termios->c_lflag & (ICANON)) && tty->read_cnt) > => > tty->termios is probably NULL Unquestionably that is the problem. It looks like something is wrong in serial_install(). We want to call tty_init_termios(tty) always, regardless of whether tty->driver->termios[idx] is NULL. But after the call it definitely won't be NULL, so the test has to be made before the call is done. Something like this: struct ktermios *t = tty->driver->termios[idx]; /* perform the standard setup */ retval = tty_init_termios(tty); if (retval) return retval; /* If the specialized termios setup has yet to be done */ if (!t) { ... Want to try that? Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-25 23:42 ` Alan Stern @ 2009-08-26 20:32 ` Bruno Prémont 2009-08-27 2:19 ` Alan Stern 0 siblings, 1 reply; 42+ messages in thread From: Bruno Prémont @ 2009-08-26 20:32 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Tue, 25 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > On Tue, 25 Aug 2009, Bruno Prémont wrote: > > Bang at: > > /tmp/linux-2.6.31-rc6-gregkh/drivers/char/n_tty.c:1456 > > > > 1456: if (canon_change && !L_ICANON(tty) && tty->read_cnt) > > 1457: wake_up_interruptible(&tty->read_wait); > > > > #define ICANON 0000002 > > #define _L_FLAG(tty, f) ((tty)->termios->c_lflag & (f)) > > #define L_ICANON(tty) _L_FLAG((tty), ICANON) > > => > > if (canon_change && !((tty)->termios->c_lflag & (ICANON)) && tty->read_cnt) > > => > > tty->termios is probably NULL > > Unquestionably that is the problem. > > It looks like something is wrong in serial_install(). We want to > call tty_init_termios(tty) always, regardless of whether > tty->driver->termios[idx] is NULL. But after the call it definitely > won't be NULL, so the test has to be made before the call is done. > Something like this: > > struct ktermios *t = tty->driver->termios[idx]; > > /* perform the standard setup */ > retval = tty_init_termios(tty); > if (retval) > return retval; > > /* If the specialized termios setup has yet to be done */ > if (!t) { > ... > > Want to try that? Change applied to usb-serial.c, serial_instal(). Tried it out with both pl2302 and ftdi-sio, no visible issues! Actions I tried: connect, disconnect (with minicom running as well as without), start/stop minicom multiple times. I've seen nothing unexpected or bad in kernel log (just a note that some sending failed while typing into minicom and pulling the USB plug: pl2303_write_bulk_callback - failed resubmitting write urb, error -19) Bruno Full log while trying out: [ 96.060039] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 96.278980] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 96.279105] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 96.279249] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 96.279346] usb 1-2: Manufacturer: FTDI [ 96.279433] usb 1-2: SerialNumber: FTS55QK6 [ 96.279746] usb 1-2: configuration #1 chosen from 1 choice [ 96.386173] usbcore: registered new interface driver usbserial [ 96.386245] usbserial: USB Serial Driver core [ 96.448488] USB Serial support registered for FTDI USB Serial Device [ 96.448888] usb 1-2: Ignoring serial port reserved for JTAG [ 96.449106] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 96.449296] usb 1-2: Detected FT2232C [ 96.449367] usb 1-2: Number of endpoints 2 [ 96.449460] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 96.449544] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 96.449643] usb 1-2: Setting MaxPacketSize 64 [ 96.450799] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 96.450895] usbcore: registered new interface driver ftdi_sio [ 96.450938] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 147.540073] usb 1-2: USB disconnect, address 2 [ 147.540627] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 147.540820] ftdi_sio 1-2:1.1: device disconnected [ 177.410037] usb 1-2: new full speed USB device using uhci_hcd and address 3 [ 177.628979] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 177.629105] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 177.629251] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 177.629349] usb 1-2: Manufacturer: FTDI [ 177.629436] usb 1-2: SerialNumber: FTS55QK6 [ 177.629751] usb 1-2: configuration #1 chosen from 1 choice [ 177.637131] usb 1-2: Ignoring serial port reserved for JTAG [ 177.642161] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 177.642379] usb 1-2: Detected FT2232C [ 177.642452] usb 1-2: Number of endpoints 2 [ 177.642546] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 177.642629] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 177.642729] usb 1-2: Setting MaxPacketSize 64 [ 177.643137] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 199.790072] usb 1-2: USB disconnect, address 3 [ 199.790622] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 199.790815] ftdi_sio 1-2:1.1: device disconnected [ 202.910037] usb 1-2: new full speed USB device using uhci_hcd and address 4 [ 203.128984] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 203.129101] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 203.129242] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 203.129333] usb 1-2: Manufacturer: FTDI [ 203.129415] usb 1-2: SerialNumber: FTS55QK6 [ 203.129723] usb 1-2: configuration #1 chosen from 1 choice [ 203.137131] usb 1-2: Ignoring serial port reserved for JTAG [ 203.142155] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 203.142366] usb 1-2: Detected FT2232C [ 203.142431] usb 1-2: Number of endpoints 2 [ 203.142519] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 203.142596] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 203.142691] usb 1-2: Setting MaxPacketSize 64 [ 203.143150] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1 [ 266.033894] usbcore: deregistering interface driver ftdi_sio [ 266.038905] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1 [ 266.042730] ftdi_sio 1-2:1.1: device disconnected [ 266.045992] USB Serial deregistering driver FTDI USB Serial Device [ 284.281542] usbcore: deregistering interface driver usbserial [ 288.540072] usb 1-2: USB disconnect, address 4 [ 294.000036] usb 1-2: new full speed USB device using uhci_hcd and address 5 [ 294.218988] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 294.219114] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 294.219259] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 294.219357] usb 1-2: Manufacturer: FTDI [ 294.219443] usb 1-2: SerialNumber: FTS55QK6 [ 294.219759] usb 1-2: configuration #1 chosen from 1 choice [ 294.261216] usbcore: registered new interface driver usbserial [ 294.261288] usbserial: USB Serial Driver core [ 294.267068] USB Serial support registered for FTDI USB Serial Device [ 294.267281] usb 1-2: Ignoring serial port reserved for JTAG [ 294.267383] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 294.267479] usb 1-2: Detected FT2232C [ 294.267509] usb 1-2: Number of endpoints 2 [ 294.267555] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 294.267590] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 294.267639] usb 1-2: Setting MaxPacketSize 64 [ 294.269091] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 294.269197] usbcore: registered new interface driver ftdi_sio [ 294.269240] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 300.000027] Machine check events logged [ 723.280035] usb 1-1: new full speed USB device using uhci_hcd and address 6 [ 723.446315] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 723.450777] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 723.455164] usb 1-1: Product: USB-Serial Controller [ 723.459524] usb 1-1: Manufacturer: Prolific Technology Inc. [ 723.465908] usb 1-1: configuration #1 chosen from 1 choice [ 723.916652] USB Serial support registered for pl2303 [ 723.921271] pl2303 1-1:1.0: pl2303 converter detected [ 723.935435] usb 1-1: pl2303 converter now attached to ttyUSB1 [ 723.939890] usbcore: registered new interface driver pl2303 [ 723.944327] pl2303: Prolific PL2303 USB to serial adaptor driver [ 739.750073] usb 1-1: USB disconnect, address 6 [ 739.750909] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1 [ 739.751075] pl2303 1-1:1.0: device disconnected [ 743.530041] usb 1-1: new full speed USB device using uhci_hcd and address 7 [ 743.696932] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 743.697050] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 743.697190] usb 1-1: Product: USB-Serial Controller [ 743.697271] usb 1-1: Manufacturer: Prolific Technology Inc. [ 743.697600] usb 1-1: configuration #1 chosen from 1 choice [ 743.700108] pl2303 1-1:1.0: pl2303 converter detected [ 743.712094] usb 1-1: pl2303 converter now attached to ttyUSB2 [ 752.250070] usb 1-1: USB disconnect, address 7 [ 752.250499] usb 1-1: pl2303_write_bulk_callback - failed resubmitting write urb, error -19 [ 752.251803] pl2303 ttyUSB2: pl2303 converter now disconnected from ttyUSB2 [ 752.251967] pl2303 1-1:1.0: device disconnected [ 776.780035] usb 1-1: new full speed USB device using uhci_hcd and address 8 [ 776.946378] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 776.946496] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 776.946633] usb 1-1: Product: USB-Serial Controller [ 776.946716] usb 1-1: Manufacturer: Prolific Technology Inc. [ 776.947044] usb 1-1: configuration #1 chosen from 1 choice [ 776.949528] pl2303 1-1:1.0: pl2303 converter detected [ 776.961542] usb 1-1: pl2303 converter now attached to ttyUSB3 [ 816.250068] usb 1-1: USB disconnect, address 8 [ 816.250476] pl2303 ttyUSB3: pl2303 converter now disconnected from ttyUSB3 [ 816.250644] pl2303 1-1:1.0: device disconnected [ 818.250058] usb 1-2: USB disconnect, address 5 [ 818.250531] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 818.250723] ftdi_sio 1-2:1.1: device disconnected [ 829.914462] usbcore: deregistering interface driver pl2303 [ 829.915564] USB Serial deregistering driver pl2303 [ 829.915958] usbcore: deregistering interface driver ftdi_sio [ 829.916113] USB Serial deregistering driver FTDI USB Serial Device [ 829.916472] usbcore: deregistering interface driver usbserial ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-26 20:32 ` Bruno Prémont @ 2009-08-27 2:19 ` Alan Stern 0 siblings, 0 replies; 42+ messages in thread From: Alan Stern @ 2009-08-27 2:19 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Wed, 26 Aug 2009, Bruno [UTF-8] Prémont wrote: > Change applied to usb-serial.c, serial_instal(). > Tried it out with both pl2302 and ftdi-sio, no visible issues! > > Actions I tried: connect, disconnect (with minicom running as well as > without), start/stop minicom multiple times. > > I've seen nothing unexpected or bad in kernel log (just a note that > some sending failed while typing into minicom and pulling the USB > plug: pl2303_write_bulk_callback - failed resubmitting write urb, error -19) Great! Okay, I'll break this up into a bunch of logically separate patches and submit them for 2.6.32. When they have gotten sufficient testing, they can be back-ported into 2.6.31.stable. Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-21 15:43 ` Alan Stern 2009-08-21 15:48 ` Alan Cox @ 2009-08-21 16:50 ` Bruno Prémont 1 sibling, 0 replies; 42+ messages in thread From: Bruno Prémont @ 2009-08-21 16:50 UTC (permalink / raw) To: Alan Stern Cc: Alan Cox, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Fri, 21 August 2009 Alan Stern <stern@rowland.harvard.edu> wrote: > On Fri, 21 Aug 2009, Bruno [UTF-8] Prémont wrote: > > > The module refcount was for both. It's the pl2302/ftdi-sio module's > > refcount. > > > > I don't remember for sure about the panic if it also affects > > pl2302 or not. > > At least one of the panics was when running dmesg after exiting > > minicom. > > > > I will redo the tests this evening when I get home and report back > > with more details. > > Apparently the problem is in serial_do_free(); it doesn't know > whether it's getting called for a successful open or an unsuccessful > open, so it decrements the module count when it shouldn't. The same > is true for port->dev's refcount. That makes sense, see below dmesg log extracts (from USB plug-in until after exiting minicom), there are two calls to serial_do_free(). On USB disconnect module refcount is zero, on minicom exit it underflows. > Alan, related to this problem is the fact that usb_serial_driver > doesn't include a "hangup" method. I'm not sure that making > serial_hangup() call serial_do_down() is correct, but if it is then > shouldn't we call port->serial->type->open() afterwards? Otherwise > the lower driver can't know that the port is still open. > > Furthermore, shouldn't we check ASYNCB_INITIALIZED in serial_close()? > > Alan Stern This time I had no crash (neither with ftdi nor with pl2302), possibly a matter of what memory areas were affected... Bruno dmesg + lsmod as at end of dmesg log. First for ftdi device, second for pl2302 device: [ 389.940038] usb 1-2: new full speed USB device using uhci_hcd and address 2 [ 390.158982] usb 1-2: New USB device found, idVendor=9e88, idProduct=9e8f [ 390.159202] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 390.159447] usb 1-2: Product: SheevaPlug JTAGKey FT2232D B [ 390.159622] usb 1-2: Manufacturer: FTDI [ 390.159763] usb 1-2: SerialNumber: FTS55QK6 [ 390.160160] usb 1-2: configuration #1 chosen from 1 choice [ 390.243200] usbcore: registered new interface driver usbserial [ 390.243309] usbserial: USB Serial Driver core [ 390.274397] USB Serial support registered for FTDI USB Serial Device [ 390.274888] usb 1-2: Ignoring serial port reserved for JTAG [ 390.275185] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected [ 390.275467] usb 1-2: Detected FT2232C [ 390.275589] usb 1-2: Number of endpoints 2 [ 390.275740] usb 1-2: Endpoint 1 MaxPacketSize 64 [ 390.275888] usb 1-2: Endpoint 2 MaxPacketSize 64 [ 390.276052] usb 1-2: Setting MaxPacketSize 64 [ 390.278136] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 [ 390.278435] usbcore: registered new interface driver ftdi_sio [ 390.278619] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver [ 394.507447] usb_serial_get_by_index(index 0): @dd0b88a0 [ 394.507642] ------------[ cut here ]------------ [ 394.507836] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 394.508189] Hardware name: TravelMate 660 [ 394.508334] Modules linked in: ftdi_sio usbserial usb_storage squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd i2c_i801 ehci_hcd uhci_hcd usbcore snd_page_alloc pcspkr crc_ccitt [ 394.509752] Pid: 3116, comm: minicom Tainted: G M 2.6.31-rc6 #1 [ 394.509959] Call Trace: [ 394.510089] [<c12b7052>] ? printk+0x18/0x1e [ 394.510241] [<df57b182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 394.510480] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 394.510660] [<df57b182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 394.510894] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 394.511068] [<df57b182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 394.511304] [<df57b36d>] serial_open+0x2d/0x250 [usbserial] [ 394.511490] [<c115f7b9>] ? tty_init_dev+0x89/0x160 [ 394.511666] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 394.511815] [<c1077566>] chrdev_open+0x96/0x140 [ 394.511986] [<c10732ff>] __dentry_open+0x9f/0x250 [ 394.512144] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 394.512324] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 394.512478] [<c107f889>] do_filp_open+0x269/0x890 [ 394.512652] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 394.512812] [<c10730c7>] do_sys_open+0x57/0x140 [ 394.512983] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 394.513148] [<c1073219>] sys_open+0x29/0x40 [ 394.513306] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 394.513466] ---[ end trace a4862da83be6d4cc ]--- [ 410.250064] usb 1-2: USB disconnect, address 2 [ 410.250628] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 410.250935] usb_serial_put(serial @dd0b88a0) [ 410.251074] ------------[ cut here ]------------ [ 410.251257] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 410.251586] Hardware name: TravelMate 660 [ 410.251730] Modules linked in: ftdi_sio usbserial usb_storage squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd i2c_i801 ehci_hcd uhci_hcd usbcore snd_page_alloc pcspkr crc_ccitt [ 410.253139] Pid: 976, comm: khubd Tainted: G M W 2.6.31-rc6 #1 [ 410.253339] Call Trace: [ 410.253448] [<c12b7052>] ? printk+0x18/0x1e [ 410.253598] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 410.253813] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 410.253992] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 410.254202] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 410.254376] [<df57aceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 410.254588] [<df57af81>] usb_serial_disconnect+0xf1/0x160 [usbserial] [ 410.254835] [<dea3f447>] ? usb_disable_interface+0x37/0x50 [usbcore] [ 410.255086] [<dea42221>] usb_unbind_interface+0xf1/0x130 [usbcore] [ 410.255293] [<c11b5441>] __device_release_driver+0x51/0xa0 [ 410.255491] [<c11b5540>] device_release_driver+0x20/0x40 [ 410.255666] [<c11b4aad>] bus_remove_device+0x7d/0xb0 [ 410.255847] [<c11b2ef2>] device_del+0x102/0x190 [ 410.256025] [<dea3f3a7>] usb_disable_device+0x87/0xf0 [usbcore] [ 410.256259] [<dea3a8a6>] usb_disconnect+0x96/0xf0 [usbcore] [ 410.256469] [<dea3b989>] hub_thread+0x829/0x1210 [usbcore] [ 410.256672] [<c10357a0>] ? autoremove_wake_function+0x0/0x50 [ 410.256882] [<dea3b160>] ? hub_thread+0x0/0x1210 [usbcore] [ 410.257079] [<c10353cc>] kthread+0x7c/0x90 [ 410.257217] [<c1035350>] ? kthread+0x0/0x90 [ 410.257376] [<c1003673>] kernel_thread_helper+0x7/0x14 [ 410.257543] ---[ end trace a4862da83be6d4cd ]--- [ 410.257708] ftdi_sio 1-2:1.1: device disconnected [ 410.258188] usb_serial_get_by_index(index 0): @dd0b88a0 [ 410.258358] ------------[ cut here ]------------ [ 410.258537] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 410.258887] Hardware name: TravelMate 660 [ 410.259031] Modules linked in: ftdi_sio usbserial usb_storage squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd i2c_i801 ehci_hcd uhci_hcd usbcore snd_page_alloc pcspkr crc_ccitt [ 410.260453] Pid: 3116, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 410.260660] Call Trace: [ 410.260763] [<c12b7052>] ? printk+0x18/0x1e [ 410.260912] [<df57b182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 410.261161] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 410.261340] [<df57b182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 410.261589] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 410.261763] [<df57b182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 410.262012] [<df57b36d>] serial_open+0x2d/0x250 [usbserial] [ 410.262198] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 410.262384] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 410.262531] [<c1077566>] chrdev_open+0x96/0x140 [ 410.262701] [<c10732ff>] __dentry_open+0x9f/0x250 [ 410.262859] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 410.263040] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 410.263194] [<c107f889>] do_filp_open+0x269/0x890 [ 410.263367] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 410.273068] [<c10730c7>] do_sys_open+0x57/0x140 [ 410.283083] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 410.293149] [<c1073219>] sys_open+0x29/0x40 [ 410.303259] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 410.313388] ---[ end trace a4862da83be6d4ce ]--- [ 410.331134] tty_port_close_start: count = -1 [ 410.335326] serial_do_free(port @d8c72400) [ 410.339451] serial @dd0b88a0 [ 410.343874] type @df5d8660 [ 410.348150] usb_serial_put(serial @dd0b88a0) [ 410.352244] ------------[ cut here ]------------ [ 410.356280] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 410.360483] Hardware name: TravelMate 660 [ 410.364569] Modules linked in: ftdi_sio usbserial usb_storage squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd i2c_i801 ehci_hcd uhci_hcd usbcore snd_page_alloc pcspkr crc_ccitt [ 410.373535] Pid: 3116, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 410.377676] Call Trace: [ 410.381732] [<c12b7052>] ? printk+0x18/0x1e [ 410.385770] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 410.389857] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 410.393946] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 410.398034] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 410.402115] [<df57aceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 410.406209] [<df57adb9>] serial_do_free+0x99/0xd0 [usbserial] [ 410.410283] [<df57ae57>] serial_close+0x67/0xa0 [usbserial] [ 410.414352] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 410.418378] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 410.422426] [<c102372e>] ? warn_slowpath_common+0x9e/0xc0 [ 410.426440] [<c10207e3>] ? __cond_resched+0x23/0x40 [ 410.430475] [<c12b7555>] ? _cond_resched+0x25/0x40 [ 410.434478] [<c12b7d7e>] ? mutex_lock+0xe/0x20 [ 410.438499] [<df57b3a9>] ? serial_open+0x69/0x250 [usbserial] [ 410.442530] [<c115fced>] tty_open+0x45d/0x4b0 [ 410.446533] [<c1077566>] chrdev_open+0x96/0x140 [ 410.450546] [<c10732ff>] __dentry_open+0x9f/0x250 [ 410.454546] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 410.458525] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 410.462523] [<c107f889>] do_filp_open+0x269/0x890 [ 410.466498] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 410.470499] [<c10730c7>] do_sys_open+0x57/0x140 [ 410.474455] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 410.478424] [<c1073219>] sys_open+0x29/0x40 [ 410.482384] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 410.486332] ---[ end trace a4862da83be6d4cf ]--- [ 518.992741] serial_do_free(port @d8c72400) [ 518.992888] serial @dd0b88a0 [ 518.993010] type @df5d8660 [ 518.993115] usb_serial_put(serial @dd0b88a0) [ 518.993268] ------------[ cut here ]------------ [ 518.993435] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 518.993794] Hardware name: TravelMate 660 [ 518.993923] Modules linked in: ftdi_sio usbserial usb_storage squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd i2c_i801 ehci_hcd uhci_hcd usbcore snd_page_alloc pcspkr crc_ccitt [ 518.995333] Pid: 3116, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 518.995571] Call Trace: [ 518.995665] [<c12b7052>] ? printk+0x18/0x1e [ 518.995830] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 518.996029] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 518.996225] [<df57aceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 518.996419] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 518.996609] [<df57aceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 518.996804] [<df57adb9>] serial_do_free+0x99/0xd0 [usbserial] [ 518.997016] [<df57ae57>] serial_close+0x67/0xa0 [usbserial] [ 518.997200] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 518.997369] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 518.997539] [<c1056d72>] ? put_page+0x42/0x120 [ 518.997708] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 518.997875] [<c115f64a>] tty_release+0xa/0x10 [ 518.998037] [<c1075f1c>] __fput+0xdc/0x1d0 [ 518.998174] [<c107602f>] fput+0x1f/0x30 [ 518.998323] [<c1072f8e>] filp_close+0x3e/0x70 [ 518.998470] [<c1024fa2>] put_files_struct+0xa2/0xc0 [ 518.998648] [<c1024fdc>] exit_files+0x1c/0x20 [ 518.998795] [<c1026339>] do_exit+0xb9/0x630 [ 518.998954] [<c103acd8>] ? __put_cred+0x18/0x20 [ 518.999107] [<c10268dd>] do_group_exit+0x2d/0x80 [ 518.999277] [<c1026943>] sys_exit_group+0x13/0x20 [ 518.999434] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 518.999610] ---[ end trace a4862da83be6d4d0 ]--- [ 518.999758] destroy_serial(kref @dd0b88d4) [ 518.999905] serial @dd0b88a0 Module Size Used by ftdi_sio 51372 4294967295 usbserial 31164 1 ftdi_sio usb_storage 49504 0 squashfs 20936 1 zlib_inflate 16164 1 squashfs nfs 141068 0 lockd 65768 1 nfs nfs_acl 2884 1 nfs sunrpc 170044 3 nfs,lockd,nfs_acl 8021q 19872 0 snd_pcm_oss 36096 0 snd_mixer_oss 14564 1 snd_pcm_oss xfs 483008 1 exportfs 3844 1 xfs loop 14352 2 snd_intel8x0 29792 0 nsc_ircc 16112 0 snd_ac97_codec 101540 1 snd_intel8x0 ac97_bus 1540 1 snd_ac97_codec irda 101496 1 nsc_ircc snd_pcm 60524 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 18344 1 snd_pcm snd 48772 6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer i2c_i801 8500 0 ehci_hcd 33972 0 uhci_hcd 21876 0 usbcore 133920 5 ftdi_sio,usbserial,usb_storage,ehci_hcd,uhci_hcd snd_page_alloc 8044 2 snd_intel8x0,snd_pcm pcspkr 2276 0 crc_ccitt 1796 1 irda [ 691.010035] usb 1-1: new full speed USB device using uhci_hcd and address 2 [ 691.176987] usb 1-1: New USB device found, idVendor=067b, idProduct=2303 [ 691.177206] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 691.177451] usb 1-1: Product: USB-Serial Controller [ 691.177608] usb 1-1: Manufacturer: Prolific Technology Inc. [ 691.178025] usb 1-1: configuration #1 chosen from 1 choice [ 691.254399] usbcore: registered new interface driver usbserial [ 691.254507] usbserial: USB Serial Driver core [ 691.274470] USB Serial support registered for pl2303 [ 691.274732] pl2303 1-1:1.0: pl2303 converter detected [ 691.286169] usb 1-1: pl2303 converter now attached to ttyUSB0 [ 691.286430] usbcore: registered new interface driver pl2303 [ 691.286610] pl2303: Prolific PL2303 USB to serial adaptor driver [ 702.598739] usb_serial_get_by_index(index 0): @da6a3780 [ 702.598931] ------------[ cut here ]------------ [ 702.599124] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 702.599476] Hardware name: TravelMate 660 [ 702.599621] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc irda snd_pcm snd_timer snd ehci_hcd pcspkr i2c_i801 uhci_hcd snd_page_alloc crc_ccitt usbcore [ 702.601064] Pid: 2528, comm: minicom Tainted: G M 2.6.31-rc6 #1 [ 702.601272] Call Trace: [ 702.601383] [<c12b7052>] ? printk+0x18/0x1e [ 702.601532] [<deb16182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 702.601771] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 702.601950] [<deb16182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 702.602198] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 702.602372] [<deb16182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 702.602621] [<deb1636d>] serial_open+0x2d/0x250 [usbserial] [ 702.602806] [<c115f7b9>] ? tty_init_dev+0x89/0x160 [ 702.602981] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 702.603129] [<c1077566>] chrdev_open+0x96/0x140 [ 702.603300] [<c10732ff>] __dentry_open+0x9f/0x250 [ 702.603457] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 702.603637] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 702.603793] [<c107f889>] do_filp_open+0x269/0x890 [ 702.603966] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 702.604126] [<c10730c7>] do_sys_open+0x57/0x140 [ 702.604296] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 702.604461] [<c1073219>] sys_open+0x29/0x40 [ 702.604619] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 702.604779] ---[ end trace 11618bfb3543f78d ]--- [ 733.750062] usb 1-1: USB disconnect, address 2 [ 733.751174] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 733.751434] usb_serial_put(serial @da6a3780) [ 733.751573] ------------[ cut here ]------------ [ 733.751756] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 733.752096] Hardware name: TravelMate 660 [ 733.752241] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc irda snd_pcm snd_timer snd ehci_hcd pcspkr i2c_i801 uhci_hcd snd_page_alloc crc_ccitt usbcore [ 733.753645] Pid: 956, comm: khubd Tainted: G M W 2.6.31-rc6 #1 [ 733.753846] Call Trace: [ 733.753954] [<c12b7052>] ? printk+0x18/0x1e [ 733.754103] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 733.754317] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 733.754497] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 733.754707] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 733.754880] [<deb15ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 733.755092] [<deb15f81>] usb_serial_disconnect+0xf1/0x160 [usbserial] [ 733.755339] [<dea0c447>] ? usb_disable_interface+0x37/0x50 [usbcore] [ 733.755590] [<dea0f221>] usb_unbind_interface+0xf1/0x130 [usbcore] [ 733.755797] [<c11b5441>] __device_release_driver+0x51/0xa0 [ 733.755994] [<c11b5540>] device_release_driver+0x20/0x40 [ 733.756169] [<c11b4aad>] bus_remove_device+0x7d/0xb0 [ 733.756349] [<c11b2ef2>] device_del+0x102/0x190 [ 733.756528] [<dea0c3a7>] usb_disable_device+0x87/0xf0 [usbcore] [ 733.756762] [<dea078a6>] usb_disconnect+0x96/0xf0 [usbcore] [ 733.756971] [<dea08989>] hub_thread+0x829/0x1210 [usbcore] [ 733.757175] [<c10357a0>] ? autoremove_wake_function+0x0/0x50 [ 733.757386] [<dea08160>] ? hub_thread+0x0/0x1210 [usbcore] [ 733.757584] [<c10353cc>] kthread+0x7c/0x90 [ 733.757722] [<c1035350>] ? kthread+0x0/0x90 [ 733.757881] [<c1003673>] kernel_thread_helper+0x7/0x14 [ 733.758049] ---[ end trace 11618bfb3543f78e ]--- [ 733.758213] pl2303 1-1:1.0: device disconnected [ 733.759141] usb_serial_get_by_index(index 0): @da6a3780 [ 733.759316] ------------[ cut here ]------------ [ 733.759497] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:78 usb_serial_get_by_index+0x42/0x70 [usbserial]() [ 733.759847] Hardware name: TravelMate 660 [ 733.759992] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc irda snd_pcm snd_timer snd ehci_hcd pcspkr i2c_i801 uhci_hcd snd_page_alloc crc_ccitt usbcore [ 733.761423] Pid: 2528, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 733.761660] Call Trace: [ 733.761750] [<c12b7052>] ? printk+0x18/0x1e [ 733.761914] [<deb16182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 733.762133] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 733.762329] [<deb16182>] ? usb_serial_get_by_index+0x42/0x70 [usbserial] [ 733.762547] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 733.762737] [<deb16182>] usb_serial_get_by_index+0x42/0x70 [usbserial] [ 733.762957] [<deb1636d>] serial_open+0x2d/0x250 [usbserial] [ 733.763159] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 733.763328] [<c115fa4d>] tty_open+0x1bd/0x4b0 [ 733.763492] [<c1077566>] chrdev_open+0x96/0x140 [ 733.763647] [<c10732ff>] __dentry_open+0x9f/0x250 [ 733.763821] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 733.763985] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 733.764155] [<c107f889>] do_filp_open+0x269/0x890 [ 733.764313] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 733.773926] [<c10730c7>] do_sys_open+0x57/0x140 [ 733.783856] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 733.793832] [<c1073219>] sys_open+0x29/0x40 [ 733.803856] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 733.813897] ---[ end trace 11618bfb3543f78f ]--- [ 733.829386] tty_port_close_start: count = -1 [ 733.930036] serial_do_free(port @dd86ae00) [ 733.940088] serial @da6a3780 [ 733.950089] type @deb25c20 [ 733.960455] usb_serial_put(serial @da6a3780) [ 733.964507] ------------[ cut here ]------------ [ 733.968561] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 733.973026] Hardware name: TravelMate 660 [ 733.977130] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc irda snd_pcm snd_timer snd ehci_hcd pcspkr i2c_i801 uhci_hcd snd_page_alloc crc_ccitt usbcore [ 733.986053] Pid: 2528, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 733.990213] Call Trace: [ 733.994262] [<c12b7052>] ? printk+0x18/0x1e [ 733.998300] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 734.002543] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 734.006612] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 734.010724] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 734.014796] [<deb15ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 734.018898] [<deb15db9>] serial_do_free+0x99/0xd0 [usbserial] [ 734.022988] [<deb15e57>] serial_close+0x67/0xa0 [usbserial] [ 734.027062] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 734.031105] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 734.035140] [<c102372e>] ? warn_slowpath_common+0x9e/0xc0 [ 734.039158] [<c10207e3>] ? __cond_resched+0x23/0x40 [ 734.043201] [<c12b7555>] ? _cond_resched+0x25/0x40 [ 734.047213] [<c12b7d7e>] ? mutex_lock+0xe/0x20 [ 734.051243] [<deb163a9>] ? serial_open+0x69/0x250 [usbserial] [ 734.055258] [<c115fced>] tty_open+0x45d/0x4b0 [ 734.059281] [<c1077566>] chrdev_open+0x96/0x140 [ 734.063302] [<c10732ff>] __dentry_open+0x9f/0x250 [ 734.067307] [<c1073599>] nameidata_to_filp+0x59/0x70 [ 734.071304] [<c10774d0>] ? chrdev_open+0x0/0x140 [ 734.075288] [<c107f889>] do_filp_open+0x269/0x890 [ 734.079264] [<c1038c5c>] ? ktime_get_ts+0x4c/0x50 [ 734.083275] [<c10730c7>] do_sys_open+0x57/0x140 [ 734.087234] [<c1026d55>] ? alarm_setitimer+0x35/0x70 [ 734.091225] [<c1073219>] sys_open+0x29/0x40 [ 734.095170] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 734.099124] ---[ end trace 11618bfb3543f790 ]--- [ 834.133234] serial_do_free(port @dd86ae00) [ 834.133379] serial @da6a3780 [ 834.133499] type @deb25c20 [ 834.133621] usb_serial_put(serial @da6a3780) [ 834.133757] ------------[ cut here ]------------ [ 834.133939] WARNING: at /usr/src/linux-2.6/drivers/usb/serial/usb-serial.c:179 usb_serial_put+0x2b/0x60 [usbserial]() [ 834.134266] Hardware name: TravelMate 660 [ 834.134410] Modules linked in: pl2303 usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 snd_ac97_codec ac97_bus nsc_ircc irda snd_pcm snd_timer snd ehci_hcd pcspkr i2c_i801 uhci_hcd snd_page_alloc crc_ccitt usbcore [ 834.135811] Pid: 2528, comm: minicom Tainted: G M W 2.6.31-rc6 #1 [ 834.136018] Call Trace: [ 834.136127] [<c12b7052>] ? printk+0x18/0x1e [ 834.136276] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 834.136489] [<c10236fc>] warn_slowpath_common+0x6c/0xc0 [ 834.136669] [<deb15ceb>] ? usb_serial_put+0x2b/0x60 [usbserial] [ 834.136878] [<c1023765>] warn_slowpath_null+0x15/0x20 [ 834.137051] [<deb15ceb>] usb_serial_put+0x2b/0x60 [usbserial] [ 834.137262] [<deb15db9>] serial_do_free+0x99/0xd0 [usbserial] [ 834.137457] [<deb15e57>] serial_close+0x67/0xa0 [usbserial] [ 834.137658] [<c115d1a5>] ? tty_fasync+0x55/0xe0 [ 834.137810] [<c115f2e0>] tty_release_dev+0x130/0x490 [ 834.137995] [<c1056d72>] ? put_page+0x42/0x120 [ 834.138148] [<c10897b6>] ? mntput_no_expire+0x16/0x60 [ 834.138331] [<c115f64a>] tty_release+0xa/0x10 [ 834.138477] [<c1075f1c>] __fput+0xdc/0x1d0 [ 834.138630] [<c107602f>] fput+0x1f/0x30 [ 834.138763] [<c1072f8e>] filp_close+0x3e/0x70 [ 834.138926] [<c1024fa2>] put_files_struct+0xa2/0xc0 [ 834.139088] [<c1024fdc>] exit_files+0x1c/0x20 [ 834.139251] [<c1026339>] do_exit+0xb9/0x630 [ 834.139393] [<c103acd8>] ? __put_cred+0x18/0x20 [ 834.139562] [<c10268dd>] do_group_exit+0x2d/0x80 [ 834.139717] [<c1026943>] sys_exit_group+0x13/0x20 [ 834.139890] [<c1002e08>] sysenter_do_call+0x12/0x26 [ 834.140084] ---[ end trace 11618bfb3543f791 ]--- [ 834.141308] destroy_serial(kref @da6a37b4) [ 834.141366] serial @da6a3780 Module Size Used by pl2303 16808 4294967295 usbserial 31164 1 pl2303 squashfs 20936 1 zlib_inflate 16164 1 squashfs nfs 141068 0 lockd 65768 1 nfs nfs_acl 2884 1 nfs sunrpc 170044 3 nfs,lockd,nfs_acl 8021q 19872 0 snd_pcm_oss 36096 0 snd_mixer_oss 14564 1 snd_pcm_oss xfs 483008 1 exportfs 3844 1 xfs loop 14352 2 usb_storage 49504 0 snd_intel8x0 29792 0 snd_ac97_codec 101540 1 snd_intel8x0 ac97_bus 1540 1 snd_ac97_codec nsc_ircc 16112 0 irda 101496 1 nsc_ircc snd_pcm 60524 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 18344 1 snd_pcm snd 48772 6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer ehci_hcd 33972 0 pcspkr 2276 0 i2c_i801 8500 0 uhci_hcd 21876 0 snd_page_alloc 8044 2 snd_intel8x0,snd_pcm crc_ccitt 1796 1 irda usbcore 133920 5 pl2303,usbserial,usb_storage,ehci_hcd,uhci_hcd ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-20 19:25 ` Bruno Prémont 2009-08-20 21:20 ` Alan Stern @ 2009-08-20 21:58 ` Alan Cox 2009-08-21 14:02 ` Alan Stern 1 sibling, 1 reply; 42+ messages in thread From: Alan Cox @ 2009-08-20 21:58 UTC (permalink / raw) To: Bruno Prémont Cc: Alan Stern, Greg KH, Kernel development list, USB list, Rafael J. Wysocki > > + /* For reasons that have been lost in antiquity, the TTY > > layer calls > > + * our close method even if the open call fails. Hence we > > must not > > + * drop the reference obtained by usb_serial_get_by_index(). Not lost in antiquity: The logic is this open do some opening work block on carrier HANGUP open returns error cleanup still required So the tty layer always went that way so that the awkward cases around an opening failing with a hangup just go away. For the normal drivers which basically do open: tty layer open work open hardware and set ASYNCB_INITIALIZED block for carrier close: if (!hung_up) { if initialized shutdown() } the USB layer works really hard to be completely different (in part because the old code simply didn't implement open semantics properly or hangup correctly - hence things like mgetty fail on them). The later patches I was working on were trying to get USB serial to the point where the model was that drv->open/drv->close were the hardware init/shutdown and did indeed get called in nice matching open/close pairs and not re-entered or called unserialized. Nice spot on the ASYNC v ASYNCB bug Alan btw Alan (the other one) ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use 2009-08-20 21:58 ` Alan Cox @ 2009-08-21 14:02 ` Alan Stern 0 siblings, 0 replies; 42+ messages in thread From: Alan Stern @ 2009-08-21 14:02 UTC (permalink / raw) To: Alan Cox Cc: Bruno Prémont, Greg KH, Kernel development list, USB list, Rafael J. Wysocki On Thu, 20 Aug 2009, Alan Cox wrote: > So the tty layer always went that way so that the awkward cases around an > opening failing with a hangup just go away. For the normal drivers which > basically do > > open: > tty layer open work > open hardware and set ASYNCB_INITIALIZED > block for carrier > > close: > if (!hung_up) { > if initialized > shutdown() > } > > the USB layer works really hard to be completely different (in part > because the old code simply didn't implement open semantics properly or > hangup correctly - hence things like mgetty fail on them). > > The later patches I was working on were trying to get USB serial to the > point where the model was that drv->open/drv->close were the hardware > init/shutdown and did indeed get called in nice matching open/close pairs > and not re-entered or called unserialized. That is indeed the best approach. How much is still needed to make it work? > Nice spot on the ASYNC v ASYNCB bug Alan btw Hah! Crashing with a big oops was a pretty strong hint that something was wrong. The tricky part was grovelling through the disassembly listing and figuring out why the offsets were so huge. :-) Alan Stern ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2009-08-27 2:19 UTC | newest] Thread overview: 42+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-08 17:47 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use Bruno Prémont 2009-08-09 14:02 ` Ozan Çağlayan 2009-08-09 15:00 ` Alan Stern 2009-08-10 15:18 ` Alan Stern 2009-08-10 15:44 ` Greg KH 2009-08-10 17:18 ` Bruno Prémont 2009-08-10 18:13 ` Greg KH 2009-08-10 18:35 ` Bruno Prémont 2009-08-10 18:51 ` Bruno Prémont 2009-08-10 19:29 ` Greg KH 2009-08-18 17:00 ` Bruno Prémont 2009-08-18 22:36 ` Greg KH 2009-08-18 23:16 ` Greg KH 2009-08-19 17:22 ` Bruno Prémont 2009-08-19 18:20 ` Alan Stern 2009-08-19 20:15 ` Bruno Prémont 2009-08-19 21:01 ` Alan Stern 2009-08-19 21:50 ` Alan Cox 2009-08-19 22:44 ` Alan Stern 2009-08-20 19:25 ` Bruno Prémont 2009-08-20 21:20 ` Alan Stern 2009-08-21 9:25 ` Bruno Prémont 2009-08-21 15:43 ` Alan Stern 2009-08-21 15:48 ` Alan Cox 2009-08-21 17:39 ` Alan Stern 2009-08-21 18:42 ` Alan Cox 2009-08-21 20:52 ` Alan Stern 2009-08-21 23:16 ` Alan Cox 2009-08-22 2:30 ` Alan Stern 2009-08-23 2:51 ` Alan Stern 2009-08-23 16:15 ` Alan Stern 2009-08-23 16:30 ` Bruno Prémont 2009-08-24 1:24 ` Alan Stern 2009-08-24 20:15 ` Bruno Prémont 2009-08-25 1:42 ` Alan Stern 2009-08-25 20:19 ` Bruno Prémont 2009-08-25 23:42 ` Alan Stern 2009-08-26 20:32 ` Bruno Prémont 2009-08-27 2:19 ` Alan Stern 2009-08-21 16:50 ` Bruno Prémont 2009-08-20 21:58 ` Alan Cox 2009-08-21 14:02 ` Alan Stern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox