Hi, Steps to reproduce oops : 1. insert PL2303 serial converter 2. connect to it with cu (cu -l /dev/ttyUSB0 -s 115200) 3. take out PL2303 converter from the box 4. hit Enter in CU Such behaviour notices since 2.6.29.x. 2.6.28 was correct when disconnecting PL2303 device - cu simply print that line is dsconnected. Can supply any additional info. TIA
Created attachment 21868 [details] PL2303 oops
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Fri, 12 Jun 2009 08:39:35 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13516 > > Summary: Disconnecting PL2303 device while cu is connected to > it cause oops > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.29.4, 2.6.30 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > AssignedTo: greg@kroah.com > ReportedBy: harbour@sfinx.od.ua > Regression: No > > > Hi, > > Steps to reproduce oops : > > 1. insert PL2303 serial converter > 2. connect to it with cu (cu -l /dev/ttyUSB0 -s 115200) > 3. take out PL2303 converter from the box > 4. hit Enter in CU > > Such behaviour notices since 2.6.29.x. 2.6.28 was correct when disconnecting > PL2303 device - cu simply print that line is dsconnected. Can supply any > additional info. > Apparently a 2.6.28 -> 2.6.29.x regression. Could be USB, could be tty?
On Mon, 22 Jun 2009, Andrew Morton wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=13516 > > > > Summary: Disconnecting PL2303 device while cu is connected to > > it cause oops > > Hi, > > > > Steps to reproduce oops : > > > > 1. insert PL2303 serial converter > > 2. connect to it with cu (cu -l /dev/ttyUSB0 -s 115200) > > 3. take out PL2303 converter from the box > > 4. hit Enter in CU > > > > Such behaviour notices since 2.6.29.x. 2.6.28 was correct when > disconnecting > > PL2303 device - cu simply print that line is dsconnected. Can supply any > > additional info. > > > > Apparently a 2.6.28 -> 2.6.29.x regression. Could be USB, could be > tty? This has been fixed since 2.6.30 was released. The fixes will be added to the -stable trees after they have gotten more testing. The two patches needed are these: http://marc.info/?l=linux-usb&m=124395806322087&w=2 http://marc.info/?l=linux-usb&m=124395806222085&w=2 Alan Stern
(In reply to comment #4) > On Mon, 22 Jun 2009, Andrew Morton wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=13516 > > > > > > Summary: Disconnecting PL2303 device while cu is connected to > > > it cause oops [...] > > Apparently a 2.6.28 -> 2.6.29.x regression. Could be USB, could be > > tty? > > This has been fixed since 2.6.30 was released. The fixes will be added > to the -stable trees after they have gotten more testing. > > The two patches needed are these: > > http://marc.info/?l=linux-usb&m=124395806322087&w=2 > http://marc.info/?l=linux-usb&m=124395806222085&w=2 > > Alan Stern Hi! Alan, it seems I'm having similar problem with my UPS connected through pl2303 COM-to-USB adapter -- from times to times, UPS' monitoring looses UPS connection, then later on manual stopping monitoring process, kernel (2.6.29.6 x86_64) "oopses": BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8049a591>] _spin_lock_irqsave+0x1b/0x31 PGD 1e6ca4067 PUD 1e914e067 PMD 0 Oops: 0002 [#1] PREEMPT SMP last sysfs file: /sys/devices/platform/it87.656/fan3_input Call Trace: [<ffffffffa0cc55e3>] ? pl2303_close+0x5d/0x1f7 [pl2303] [<ffffffff8049a682>] ? _write_unlock_irq+0x16/0x32 [<ffffffff802af45f>] ? fasync_helper+0xcf/0xde [<ffffffffa0cbbad5>] ? serial_close+0x97/0x152 [usbserial] [<ffffffff8039d1c5>] ? tty_release_dev+0x18b/0x452 [<ffffffff802d040f>] ? locks_remove_posix+0x84/0xa8 [<ffffffff8039d49d>] ? tty_release+0x11/0x1a [<ffffffff802a5a24>] ? __fput+0xcd/0x187 [<ffffffff802a31e5>] ? filp_close+0x5f/0x6a [<ffffffff802a3292>] ? sys_close+0xa2/0xdb [<ffffffff802237db>] ? system_call_fastpath+0x16/0x1b So, to my mind, the problem looks similar to this bug #13516; would that 2 patches, you mentioned earlier, help to solve it?
(In reply to comment #5) [...] > So, to my mind, the problem looks similar to this bug #13516; would that 2 > patches, you mentioned earlier, help to solve it? Well, anyway, it doesn't clearly apply to 2.6.29.6, alas...
Does the latest 2.6.30.stable release fix this problem?
(In reply to comment #7) > Does the latest 2.6.30.stable release fix this problem? It looks pretty much like that. But it's hard to answer for sure, you know. Couldn't you produce patch set suitable for applying to 2.6.29?
2.6.29 is end of life and is no longer maintained by the community, nor any distro that I know of, sorry. What is keeping you from moving to 2.6.30.3?
Anyway, closing this out as it's now resolved.
(In reply to comment #9) > 2.6.29 is end of life and is no longer maintained by the community, nor any > distro that I know of, sorry. Meanwhile 2.6.30 "stable" is rather buggy, or, at least "raw": http://bugzilla.kernel.org/show_bug.cgi?id=13760 http://bugzilla.kernel.org/show_bug.cgi?id=13876 http://bugzilla.kernel.org/show_bug.cgi?id=13219
(In reply to comment #9) > 2.6.29 is end of life and is no longer maintained by the community, nor any > distro that I know of, sorry. > > What is keeping you from moving to 2.6.30.3? 2.6.30.4 you probably meant? See above. Actually, I'm even sometimes thinking of moving to 2.6.18-RHEL, because, it seems RHEL's guys do interpret term "stable" in its original meaning.
Yes, sorry, 2.6.30.4. If you feel RHEL is better suited to your needs, then by all means, please use it. But note that you have to get support for it from Red Hat, not us. good luck.
(In reply to comment #13) > Yes, sorry, 2.6.30.4. > > If you feel RHEL is better suited to your needs, then by all means, please > use > it. But note that you have to get support for it from Red Hat, not us. You're missing the point. I wouldn't have to get any support from Red Hat, cause if theirs version of kernel is real much more stable there's no need to bother Red Hat with. Also, I had been already using RHEL's patches already, doing my own patch applying and even some backporting: changeset: 75:cbe7e2ed801c branch: ck tag: tip user: poige@asix.localdomain date: Mon Jan 12 07:08:35 2009 +0700 summary: ck: mm-kswapd_inherit_prio-1.patch changeset: 74:d5b4737bb7f3 branch: ck user: poige@asix.localdomain date: Mon Jan 12 07:06:50 2009 +0700 summary: ck: -VM_SWAPPINESS +VM_MAPPED changeset: 73:bc9101e85543 branch: BP_2.6.24 user: poige@asix.localdomain date: Wed Jan 07 06:35:00 2009 +0700 summary: bp of 58e78475ec706f93e0cc049449ffd11fbfdadb3e changeset: 72:73567fd536e3 branch: BP_2.6.24 user: poige@asix.localdomain date: Wed Jan 07 06:34:16 2009 +0700 summary: bp of 80d352374be7ac88a23fb427d146ac9a71beff90 changeset: 71:8ec81986658a branch: BP_2.6.24 parent: 20:f5f0262953f8 user: poige@asix.localdomain date: Tue Jan 06 16:52:13 2009 +0700 summary: drivers/hwmon/it87.c backported from 2.6.24 (and so on). Everything was fine with that ... (and I even gave a "support" :-) in return, having found a bug, and its fix in more recent kernels, which Red Hat missed to backport: https://bugzilla.redhat.com/show_bug.cgi?id=478638 ) ... except one thing -- 2.6.18 is too old, even with backported patches. And you (in sense of you had using, when said "us") prefer to feel yourself injured, when faced with the real state of things with all of your "shiny new kernels" -- it's said, but true, that production grade meaning of "stable Linux kernel" still means 2.6.*18*! There's 2.6.*31*(!) almost ready... Yes, I understand, that probably, without ongoing work on new kernels, 2.6.18-RHEL wouldn't have went much ahead in terms of stability; many bug fixes are backports. That's true as well. But what would be really nice, is changing the policy of declaring stable kernels @ kernel.org's website and choosing more appropriate versions of kernel for support. As far as I know, you're maintaining 2.6.27.something as some kind of "more stable" than "stable". Well, I didn't hear of neither a person who uses it, "nor any distro that I know of, sorry". :-) 2.6.29.xx looks like more reasonable version to support and instead you're giving it an EOL. Nice?... > good luck. Greg... I even was not asking *you* personally to backport the patchset. Wouldn't you mind please?...
(In reply to comment #14) > (In reply to comment #13) [...] > for support. As far as I know, you're maintaining 2.6.27.something as some > kind > of "more stable" than "stable". Well, I didn't hear of neither a person who > uses it, "nor any distro that I know of, sorry". :-) Actually, there's even no mention of 2.6.27 @ www.kernel.org. At all.
What about http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2 Doesn't that count as a "mention"? As for distributions, Fedora 10 uses the 2.6.27 kernel. No doubt others do too.
(In reply to comment #16) > What about > > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2 > The meaning is very clearly explained with that letter to LKML: http://lkml.indiana.edu/hypermail/linux/kernel/0907.3/00322.html > Doesn't that count as a "mention"? Now you see? It doesn't state any special status of 2.6.27.x. Compare it to: http://marc.info/?l=linux-kernel&m=124899561923682&w=2 > As for distributions, Fedora 10 uses the 2.6.27 kernel. No doubt others > do too. Yet there're doubts, alas. You named only one distro yet, and I'm almost sure the only distro using 2.6.27. :-) But that's all banding words (and I'm not having fun with it, actually). Can you as the author of the changes please back-port'em to 2.6.29(.6)? I'm really watchful of 2.6.30 (reasoned, as I explained with links to bug reports)... the need to downgrade to 2.6.29 can arise at any moment.
Novell uses 2.6.27 as it's base for the SLE11 releases, so that is a long-term, supported, and "stable" kernel that you might wish to look at if you need a newer one. Or wait for RHEL6, that should be based on 2.6.31 or .32 I think.
(In reply to comment #18) > Novell uses 2.6.27 as it's base for the SLE11 releases Honestly speaking I had thought of Novell. :-) Had to mention explicitly, sorry. > so that is a long-term, supported, and "stable" kernel that you might wish to > look at if you need a newer one. Yeah, that's great. Possibly, it's really a way to go in case of new troubles with 2.6.3{0,1}...
Created attachment 22578 [details] USB serial port methods and shutdown patch for 2.6.29.6 As requested, attached is a combined patch containing the two patches mentioned in comment #3 back-ported to 2.6.29.6. It compiles okay, but beyond that I haven't tested it.
(In reply to comment #20) > Created an attachment (id=22578) [details] > USB serial port methods and shutdown patch for 2.6.29.6 > > As requested, attached is a combined patch containing the two patches > mentioned > in comment #3 back-ported to 2.6.29.6. It compiles okay, but beyond that I > haven't tested it. Thank you, Alan! Yesterday I have had another 2.6.30 crash, 2.6.27.29 isn't an option to me (alas) at least while I still have some Reiser4 partitions, so now 2.6.29.6 is being in use and your patch can make it even better. Thanks.
(In reply to comment #20) [...] > It compiles okay, but beyond that I haven't tested it. I'm compiling kernel with the patch, so testing is to begin soon. :-)
On Fri, 31 Jul 2009, bugzilla-daemon@bugzilla.kernel.org wrote: :Does the latest 2.6.30.stable release fix this problem? Can't reproduce this bug on 2.6.30.4 anymore. Rus
(In reply to comment #22) [...] > I'm compiling kernel with the patch, so testing is to begin soon. :-) [28595.112619] usb 2-8.2: USB disconnect, address 6 [28595.115209] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [28595.115247] pl2303 2-8.2:1.0: device disconnected [28595.319108] usb 2-8.2: new full speed USB device using ehci_hcd and address 10 [28595.415885] usb 2-8.2: configuration #1 chosen from 1 choice [28595.416023] pl2303 2-8.2:1.0: pl2303 converter detected [28595.417757] usb 2-8.2: pl2303 converter now attached to ttyUSB1 -- Alan, threre'no "oopses" anymore. Thank you!
You're welcome. Enjoy the new code!