Bug 242638
| Summary: | prism54usb: BUG: warning at drivers/usb/core/driver.c:1185/usb_autopm_do_device | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Caolan McNamara <caolanm> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||||||
| Severity: | low | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 7 | CC: | chris.brown, giulio.martinat, linville, ma, tjb | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2008-01-09 01:06:28 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Caolan McNamara
2007-06-05 08:39:37 UTC
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. |