Description of problem: Sticking in a Netgear wg111 dongle into one of my F-7 boxes fails with the above error, but no when inserted into another one. Version-Release number of selected component (if applicable): kernel-2.6.21-1.3194.fc7 How reproducible: Steps to Reproduce: 1. Insert Netgear wg111 (wg111v2) usb dongle into a Dell Dimension 2400 Actual results: usb 4-5: new high speed USB device using ehci_hcd and address 3 usb 4-5: configuration #1 chosen from 1 choice ehci_hcd 0000:00:1d.7: fatal error ehci_hcd 0000:00:1d.7: HC died; cleaning up usb 4-5: USB disconnect, address 3 p54usb: reset failed! prism54usb: probe of 4-5:1.0 failed with error -108 usbcore: registered new interface driver prism54usb usb 3-1: new full speed USB device using uhci_hcd and address 2 usb 3-1: not running at top speed; connect to a high speed hub usb 3-1: configuration #1 chosen from 1 choice uhci_hcd 0000:00:1d.2: host system error, PCI problems? uhci_hcd 0000:00:1d.2: host controller halted, very bad! uhci_hcd 0000:00:1d.2: HC died; cleaning up p54usb: reset failed! prism54usb: probe of 3-1:1.0 failed with error -110 hub 3-0:1.0: hub_port_status failed (err = -19) usb 3-1: USB disconnect, address 2 BUG: warning at drivers/usb/core/driver.c:1185/usb_autopm_do_device() (Not tainted) [<c0569425>] usb_autopm_do_device+0x5c/0xbd [<c056493f>] usb_disconnect+0x105/0x123 [<c0564988>] hub_pre_reset+0x2b/0x53 [<c05652c7>] hub_thread+0xad/0xa6e [<c0436e71>] autoremove_wake_function+0x0/0x35 [<c056521a>] hub_thread+0x0/0xa6e [<c0436da8>] kthread+0xb0/0xd8 [<c0436cf8>] kthread+0x0/0xd8 [<c0405b3f>] kernel_thread_helper+0x7/0x10 ======================= Expected results: 1. When inserted into a Dell Latitude D800 running the same kernel version there is no error, and there's no crash or problem. And with the correct firmware it works perfectly. Additional info: dmesg on working machine for comparison to above is... usb 2-8: new high speed USB device using ehci_hcd and address 5 usb 2-8: configuration #1 chosen from 1 choice p54usb: cannot find firmware (isl3887usb_bare)! prism54usb: probe of 2-8:1.0 failed with error -2 lsusb on working machine is... Bus 002 Device 005: ID 0846:4240 NetGear, Inc. WG111 WiFi (v2) Bus 002 Device 001: ID 0000:0000 Bus 001 Device 018: ID 046d:c041 Logitech, Inc. Bus 001 Device 002: ID 0557:7000 ATEN International Co., Ltd Bus 001 Device 003: ID 06a3:8000 Saitek PLC Bus 001 Device 001: ID 0000:0000 lsusb on failed machine is... Bus 002 Device 001: ID 0000:0000 Bus 001 Device 018: ID 046d:c041 Logitech, Inc. Bus 001 Device 004: ID 06a3:8000 Saitek PLC Bus 001 Device 003: ID 0557:7000 ATEN International Co., Ltd Bus 001 Device 001: ID 0000:0000 and the usb_autopm_do_device message repeats
In case it's relevant, the keyboard and mouse are both usb and connected to both the above machines through a kvm.
In theory, plugging a USB device cannot cause two controllers both fail DMA accesses. Impossible, right? But I have a wild guess: the Dim 2400 has a working IOMMU. If a driver unmaps some DMA area there, the IOMMU refuses accesses by PCI master and the above happens. That would explain why both EHCI and its companion keeled over... Caolan, please attach a complete dmesg (but don't drop it into comments). I want to see if an actual IOMMU is there.
Created attachment 156269 [details] dmesg log when dongle present during boot
i got Call Trace: [<ffffffff811a2e43>] usb_autopm_do_device+0x67/0xeb [<ffffffff811a324e>] usb_suspend_both+0x216/0x22d [<ffffffff811a2eae>] usb_autopm_do_device+0xd2/0xeb [<ffffffff811a1f2d>] usb_set_configuration+0x3f5/0x428 [<ffffffff811a93df>] generic_probe+0x1a6/0x1f3 [<ffffffff8118a48a>] driver_probe_device+0xff/0x17c [<ffffffff8118a507>] __device_attach+0x0/0x5 [<ffffffff811896d2>] bus_for_each_drv+0x40/0x72 [<ffffffff8118a5a8>] device_attach+0x79/0x90 [<ffffffff8118963e>] bus_attach_device+0x2a/0x7e [<ffffffff81188399>] device_add+0x3cb/0x611 [<ffffffff8119d93f>] usb_new_device+0xab/0xf6 [<ffffffff8119e609>] hub_thread+0x7e5/0xbd9 [<ffffffff81045841>] autoremove_wake_function+0x0/0x2e [<ffffffff8119de24>] hub_thread+0x0/0xbd9 [<ffffffff810456ec>] kthread+0x47/0x73 [<ffffffff8100a988>] child_rip+0xa/0x12 [<ffffffff810456a5>] kthread+0x0/0x73 [<ffffffff8100a97e>] child_rip+0x0/0x12 with attached stick at boot time. scsi 4:0:0:0: Direct-Access Corsair VoyagerGT 1100 PQ: 0 ANSI: 0 CCS sd 4:0:0:0: [sdd] 8093696 512-byte hardware sectors (4144 MB) sd 4:0:0:0: [sdd] Write Protect is off sd 4:0:0:0: [sdd] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdd] Assuming drive cache: write through sd 4:0:0:0: [sdd] 8093696 512-byte hardware sectors (4144 MB) sd 4:0:0:0: [sdd] Write Protect is off sd 4:0:0:0: [sdd] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdd] Assuming drive cache: write through sdd: sdd1
With 2.6.22.1-20.fc7 on a Dell XPS M1210 notebook, I'm getting what appears to be the same kernel panic at the same place with nothing external attached. It is probably related to the integrated webcam that laptop has. I'll include a dmesg next.
Created attachment 159236 [details] dmesg of boot
OK, this is two-fold. I operated under assumption that we're interested how p54u crashed the controllers. That it also tripped the autosuspend traceback is not very important. So, Ronald and Thomas should not have clinged to this bug. The good news is, they do not have to do anything else. I saw a patch from Alan Stern for the suspend refcount on linux-usb-devel today.
Created attachment 159404 [details] Candidate patch 1 This fixes the main problem which Caolan ran into, and not the refcounting issue onto which other people hung in this bug.
*** Bug 245726 has been marked as a duplicate of this bug. ***
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris
As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug.