Bug 5164
| Summary: | pl2303 when unplugged while device is open leaks semaphore | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Andi Kleen (andi-bz) |
| Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | akpm, stern |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
My guess is that the semaphore isn't "leaked", but instead the disconnect routine either crashes or hangs while holding the semaphore. What does your stack dump show for the khubd thread? Has there been any progress chasing this bug? Does it still occur in the latest kernels? Please test 2.6.14-rc3 or later. If it still happens, please reopen this bug. Note, I can't duplicate this at all on 2.6.14-rc3. This is on i386 though... Am marking closed. If you still have this problem on the 2.6.16 kernel, please reopen it and let us know. |
Most recent kernel where this bug did not occur: Distribution: suse 9.3 Hardware Environment:athlon64 / x86-64 VIA chipset OHCI Software Environment: Problem Description: Steps to reproduce: I had a serialconnection open to a pl2303 ttyUSB0 device. Then the USB cable was unplugged. The serial connection was closed as expected, but afterwards lsusb hangs. Plugging in the cable again also doesn't make the device available again. Backtrace of lsusb: lsusb D ffff810065046b30 0 22153 26510 22152 (NOTLB) ffff8100522fdde8 0000000000000082 0000000000000d19 ffff810065046b30 ffffffff803f3780 ffff81000d0fbae8 ffff8100721152a8 6db6db6db6db6db7 0000000000000001 ffff81002c4a1030 Call Trace:<ffffffff8033598e>{__down+222} <ffffffff80130280>{default_wake_function+0} <ffffffff80336ca3>{__down_failed+53} <ffffffff883d1183>{:usbcore:.text.lock.usb+15} <ffffffff883db4c8>{:usbcore:usbdev_read+72} <ffffffff80178a44>{filp_open+68} <ffffffff801797c5>{vfs_read+229} <ffffffff80179fa3>{sys_read+83} <ffffffff8010e91a>{system_call+126}