Description of problem: I have a USB dance pad and I'm running 2.6.22.1-fc7 kernel. The pad always gets disconnected and reconnected after few seconds. Problem is similar to bug 243038, but disabling USB auto suspend did not solve the problem. Said device works in Windows XP and Ubuntu 6.06 running kernel 2.6.15. Version-Release number of selected component (if applicable): hal 0.5.9-8.fc7 kernel-2.6.22.1-fc7 I also tried to recompile the kernel with USB autosuspend disabled, the problem persists. How reproducible: Consistent, happens every time. Steps to Reproduce: 1. Plug in the dance pad 2. Look at dmesg 3. See how it gets disconnected, and then re-detected Actual results: Can't get the dance pad to work with anything because it gets disconnected after few seconds. Expected results: Dance pad should stay connected. Additional info: dmesg output follows: usb 1-7: new low speed USB device using ohci_hcd and address 3 usb 1-7: configuration #1 chosen from 1 choice input: USB Dance Pad as /class/input/input5 input: USB HID v1.00 Joystick [USB Dance Pad] on usb-0000:00:02.0-7 hub 1-0:1.0: port 7 disabled by hub (EMI?), re-enabling... usb 1-7: USB disconnect, address 3 usb 1-7: new low speed USB device using ohci_hcd and address 4 usb 1-7: configuration #1 chosen from 1 choice input: USB Dance Pad as /class/input/input6 input: USB HID v1.00 Joystick [USB Dance Pad] on usb-0000:00:02.0-7 hub 1-0:1.0: port 7 disabled by hub (EMI?), re-enabling... usb 1-7: USB disconnect, address 4 ...repeated ad nauseam lsusb when the dance pad is connected: Bus 002 Device 003: ID 05e3:0606 Genesys Logic, Inc. Bus 002 Device 001: ID 0000:0000 Bus 001 Device 008: ID 0b43:0001 Play.com, Inc. Bus 001 Device 002: ID 045e:008c Microsoft Corp. Wireless Intellimouse Explorer 2.0 Bus 001 Device 001: ID 0000:0000 lspci: 00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2) 00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1) 00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2) 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) 00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) 00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) 00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:06.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04) 01:06.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04) 01:06.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) 01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) 02:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7900 GS] (rev a1)
The kernel version is 2.6.22.1-27.fc7
Not sure what the issue is, but Pete Z, may have encountered a simmilar problem and found a workaround: http://zaitcev.livejournal.com/2006/08/16/
Hmm, I have an unpowered USB hub and connected the dance pad to it. Now ehci_hcd is handling the pad, and the disconnect interval is much shorter. I also get intermittent "maybe the cable is bad" message. I don't rule out the possibility that it is a bad device, but why would it work in Windows and 2.6.15 kernel?
Neil meant this: http://zaitcev.livejournal.com/82414.html But actually it's something else. The -71 which Rusty mentioned in the blog is a signal integrity issue detected by the controller, e.g. a bit-stuffing problem, CRC, and token reply time-out (lost reply). The EMI is detected by the hub during the connect, before the controller has a chance to send any tokens. It often really is EMI from other components on the motherboard. In a few cases we (I and the user) were able to link this to something specific, like hard drive actitivity. In other words, the -71 is usually the cable (too thin, too long), or device (sequencer crash), but EMI is rarely the device. I have no idea why 2.6.15 works. The 2.6.22.1-fc7 may be enabling something like CPUFREQ which causes the electrical noise, which 2.6.15 did not enable.
Hello Wira, 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
I'm running kernel version 2.6.22.5-76.fc7 and the problem still persists. I will try to run some older kernel versions from Fedora 6 and 7 and other distributions live CDs in a few days to provide more data (and hopefully isolate the problem). Thanks, Wira
Okay, thanks for the update Wira. I'm copying the relevant maintainer into this bug who may wish to add further information as he has done already. Cheers Chris
Sorry for the late update. I haven't tried testing other kernels yet, but I got my hands on an identical dance pad model, and the problem also exists. So I guess I can rule out faulty dance pad, unless the particular model just won't work with Fedora kernels. Wira
Hello Wira, Have you had any progress with this or does the problem still exist? Can you test with more recent kernels and possibly on another machine e.g. with a live cd?
I haven't had the chance to follow-up, but I'm going to try to load the latest Ubuntu live CD in my machine to make sure that it's not the hardware.
I loaded Gutsy Gibbons Live CD and it did NOT work (same symptom). So, this can be either my motherboard/pad combination (hardware) or the kernel itself. The next step I guess is to try older kernels and see if it works, and if it doesn't, then I'm sure it's my hardware. The pad works with my other computer running Ubuntu 6.10. I'll also try to load Gutsy there and see if the pad still works. Wira
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This seems to be hardware issue, every other computer that runs Linux that I tried works with the pads, Windows must be a little bit forgiving or something. I guess we can call this bug resolved.