Bug 6596
Summary: | kernel bug at unloading pl2303 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Michael (auslands-kv) |
Component: | Serial | Assignee: | Greg Kroah-Hartman (greg) |
Status: | RESOLVED CODE_FIX | ||
Severity: | blocking | CC: | stern, zaitcev |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.16 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 5089 | ||
Attachments: |
Test fix #1 - wait until scheduled work completes in disconnect
Test fix #2 (on top of #1) - move the wait where it belongs |
Description
Michael
2006-05-22 05:17:47 UTC
It might help if you didn't have USB hubs nested four deep. Also, the converter would probably work better if you plugged it directly into the computer or into a USB-1.1 hub which was attached to the computer. The ehci-hcd driver still has problems handling full-speed devices plugged into high-speed hubs; one typical symptom of this is a -28 (-ENOSPC) error code. Well, you are definately right. I disassembled my whole usb setup and connected the pl2303 directly to the usb port -> works and no kernel bug. Good to know! However, for me this is not a very usable workaround, as I need this setup. I have several usb devices that I need to switch between three computers. Some of them are USB2.0 devices. So it There are two issues here: the -28 error and the oops upon disconnect. Probably one triggers the other. Anyway, the -28 error (caused by use of a full-speed device behind a high-speed hub) is a known problem and people are working on it. There's no reason to file a bug report for it. The oops is a real error and it should be fixed. I don't know enough about the usb-serial driver to be able to help, but other USB developers do. It's not clear whether your use of nested hubs has anything to do with either problem. That is, what matters might be only the total number of hubs and not whether they are nested. Or whether the serial device is plugged into a hub vs. plugged directly into the computer. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180463 I keep thinking that I need to look closer, just need to find a moment. Oh yes, that My guess is that the problem starts with the -28 error. That causes the serial device not to be registered in the first place. Then when you unplug the pl2303 it tries to unregister the device, which causes the oops. It should be easy enough to simulate this by hacking the driver. Instead of submitting the interrupt URB, make the driver think the submission failed and then see what happens. Created attachment 8187 [details]
Test fix #1 - wait until scheduled work completes in disconnect
Michael, please test the attached patch, thanks. Unbelievable! Just a few hours after my report there is already the first fix!!!! Unfortunately, although I would like to help as much as possible, I am afraid testing the patch is far beyond by capabilities. :( I am (more or less) just an ordinary user. Kernel is a binary kernel from the Kanotix project. I have never done any kernel compiling, not at all any patching. I might find out how to do this, but I'm afraid, this will take quite a while (at least much longer than it took to create the patch. What I will do, is contact one of the developers of the kanotix project, ask him to include this patch into his latest development kernel (2.6.17) and send my the binary. Thanks, Michael These guys at Kanotix are really incredibly helpful!! Yesterday evening I asked one of the developers if he could include the patch in his next development kernel and in the morning I already had the new kernel install binary in my mail box!!! The patch works. No more kernel bug. Of course, the -28 error still occurs and the adaptor still doesn Michael, thanks for testing. I'll forward the patch for Greg, so Kanotix people won't need to continue to carry it forward in the future releases. The patch has already been merged http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2f8ad9a1b91bc6856860a2fea8b07e0c82c0ad0a Yes, however it may not be sufficient in all cases. That is because I failed to notice that real devices are torn down elsewhere. I'll attach a follow-up patch which I sent to Greg. Created attachment 8371 [details]
Test fix #2 (on top of #1) - move the wait where it belongs
This should all be fixed in 2.6.17 now. If not, please reopen. |