Latest working kernel version: NA Earliest failing kernel version: NA Distribution: fedora9 Hardware Environment: i686 Software Environment: Problem Description: connecting and then disconnecting Logitech QuickCam Pro 5000 leaves USB port unusable. dmesg output looks like this: sb 1-8: new high speed USB device using ehci_hcd and address 5 usb 1-8: configuration #1 chosen from 1 choice usb 1-8: New USB device found, idVendor=046d, idProduct=08c5 usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c5) input: UVC Camera (046d:08c5) as /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0/input/input5 usbcore: registered new interface driver snd-usb-audio usbcore: registered new interface driver uvcvideo USB Video Class driver (v0.1.0) ehci_hcd 0000:00:1d.7: HC died; cleaning up hub 1-0:1.0: hub_port_status failed (err = -19) hub 1-0:1.0: connect-debounce failed, port 8 disabled usb 1-8: USB disconnect, address 5 irq 21: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27-rc3 #1 [<c045663c>] __report_bad_irq+0x2e/0x6f [<c0456836>] note_interrupt+0x1b9/0x20b [<c0455e3b>] ? handle_IRQ_event+0x21/0x48 [<c0456de2>] handle_fasteoi_irq+0x8f/0xaf [<c0456d53>] ? handle_fasteoi_irq+0x0/0xaf [<c0405766>] do_IRQ+0x9a/0xc4 [<c04042ab>] common_interrupt+0x23/0x28 [<c0408374>] ? mwait_idle+0x32/0x37 [<c04029de>] cpu_idle+0xb5/0xd7 [<c060a07e>] rest_init+0x4e/0x50 ======================= handlers: [<c056ab88>] (usb_hcd_irq+0x0/0x5d) [<c056ab88>] (usb_hcd_irq+0x0/0x5d) Disabling IRQ #21 Steps to reproduce: Plug in Logitech QuickCam Pro 5000 then unplug it and try to plug another device into USB.
Note, this is a uvcvideo problem, not a gspca problem. I can reproduce this with my own uvc cam (logitech sphere). I think this is new compared to 2.6.26 and should be added to the list of regressions for 2.6.27.
I can't reproduce the issue on my x86 hardware with 2.6.27-rc7 and a Logitech Quickcam Pro for Notebooks. As this is a regression, could you bisect to locate the offending commit ?
I'll try. What was the first mainline kernel release with support for this class of camera? I should say that this camera has never worked 100%. Even with pre-mainline code, it used to freeze up frequently. When I reported it, I was told that it had the "dreaded logitech firmware bug". But it didn't used to kill USB.
The uvcvideo driver was included in 2.6.26. I'm afraid there's not much I can do about the "dreaded Logitech firmware bug" in the uvcvideo driver. Even though the root cause is a firmware bug, a host-side software fix is theoretically possible as the camera works under Windows. The problem being timing-specific, it would require a fix at the USB core or USB host controller level.
The first bisection didn't compile, so I didn't get very far: Building modules, stage 2. MODPOST 1595 modules ERROR: "totalhigh_pages" [net/sctp/sctp.ko] undefined! WARNING: modpost: Found 6 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 How do I deal with compile errors during bisection?
Good question. I suppose the answer depends on the specific error, although you could always try to checkout a couple of additional commits in the hope they will solve the problem. In this specific case you can probably disable the SCTP module in the kernel config.
24618b0cd42f936cda461bdf6144670a5c925178 is first bad commit commit 24618b0cd42f936cda461bdf6144670a5c925178 Author: Alan Stern <stern@rowland.harvard.edu> Date: Mon Apr 28 11:06:28 2008 -0400 USB: debounce before unregistering This patch (as1080) makes a significant change to the way khubd handles port connect-change and enable-change events. Both types of event are now debounced, and the debouncing is carried out _before_ an existing usb_device is unregistered, instead of afterward. This means that drivers will have to deal with longer runs of errors when a device is unplugged, but they are supposed to be prepared for that in any case. The advantage is that when an enable-change occurs (caused for example by electromagnetic interference), the debouncing period will provide time for the cause of the problem to die away. A simple port reset (added in a forthcoming patch) will then allow us to recover from the fault. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> :040000 040000 028cc82dbeae645c5fd74aaa2b3c56fa8470b906 5e46075231c9af06ac9d14d08cf392f2a6442d80 M drivers
Two patches which should fix this problem have just been merged into Linus's tree. The commits are 01c17142659c02d8cd4c67acdd8358180c5c4fb6 and b40e43fcc532fa44a375a37d592e32cd0d50fe7a.
(In reply to comment #8) > Two patches which should fix this problem have just been merged into Linus's > tree. The commits are 01c17142659c02d8cd4c67acdd8358180c5c4fb6 and > b40e43fcc532fa44a375a37d592e32cd0d50fe7a. > Ah yes! I can confirm that 2.6.26rc7git3 which includes these 2 patche sindeed fixes this.
Therefor I'm closing this one :)