Distribution: Debian testing/unstable Hardware Environment: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB Cambridge Silicon Radio, Ltd Bluetooth Dongle Quanta MW1 laptop Problem Description: For about 25-40 minutes after startup, my laptop will repeatedly report the following error as it tries to initialize my CSR bluetooth dongle: kernel: hub 5-0:1.0: connect-debounce failed, port 8 disabled Then the device will suddenly be recognized and work properly. I don't think it's a hardware problem, because XP seems to handle it just fine on startup. I've configured the kernel with usb debug info, and I'll be attaching the text of syslog, lsusb -v, and lspci -v
Created attachment 6848 [details] syslog usb-debug info
Created attachment 6849 [details] lsusb output
Created attachment 6850 [details] lspci output
Begin forwarded message: Date: Fri, 16 Dec 2005 09:44:19 -0800 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 5753] New: Problem initializing CSR bluetooth through usb http://bugzilla.kernel.org/show_bug.cgi?id=5753 Summary: Problem initializing CSR bluetooth through usb Kernel Version: 2.6.15-rc5 Status: NEW Severity: normal Owner: greg@kroah.com Submitter: kinsayder@hotmail.com Distribution: Debian testing/unstable Hardware Environment: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB Cambridge Silicon Radio, Ltd Bluetooth Dongle Quanta MW1 laptop Problem Description: For about 25-40 minutes after startup, my laptop will repeatedly report the following error as it tries to initialize my CSR bluetooth dongle: kernel: hub 5-0:1.0: connect-debounce failed, port 8 disabled Then the device will suddenly be recognized and work properly. I don't think it's a hardware problem, because XP seems to handle it just fine on startup. I've configured the kernel with usb debug info, and I'll be attaching the text of syslog, lsusb -v, and lspci -v ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Judging from your log file, it sure does look like a hardware problem. In fact, it looks just like a loose connection.
Hmm. OK. I though it was working fine under XP. But give me a few days to plug it back in and double check if it is indeed just a connection problem.
Sorry about the delay. I can confirm that the problem is NOT hardware. I booted into Windows XP, and the bluetooth was immediately recognized. It found the Palm Pilot I was testing it with, connected to it, and the Pilot made its little chirpy noises to signify the connection. I then powered off and rebooted into Linux. As I reported above, I repeatedly got the "hub 1-0:1.0: connect-debounce failed, port 8 disabled" message. After about 25 minutes, the bluetooth dongle was suddenly discovered. The laptop could then connect to the Palm Pilot. So I powered off again, rebooted in Windows and got instant recognition again. Powered off again, rebooted in Linux again, and got the "connect-debounce" messages again. And I just checked: the same problem still appears in kernel 2.6.16-rc4 Please let me know if there's anything else you'd like me to try.
I've got to admit, your symptoms are very strange. It still seems hardware related; maybe Windows doesn't use the hardware in quite the same way as Linux. What happens if you "rmmod ehci-hcd" before plugging in the dongle? What happens if you plug the dongle into a different computer running Linux 2.6?
I recompiled without ehci. On bootup I still get the same messages. if I "rmmod uhci_hcd" the messages stop; if I modprobe it, they start back up again. I'm afraid that trying it out in a different laptop is impractical, but I'll see what I can do. It's an internal bluetooth. I think I was unclear about that or maybe I misused the terminology. I'd appreciate any other suggestions.
They couldn't have been exactly the same messages. For instance, the lines like: Dec 15 22:05:45 localhost kernel: ehci_hcd 0000:00:1d.7: GetStatus port 8 status 001002 POWER sig=se0 CSC are produced by ehci-hcd and so wouldn't be present. FYI, this message means that the signal on the USB data bus is "se0" (single-ended 0: both D+ and D- signals are at low voltage), which indicates the dongle isn't pulling the D+ line to a positive voltage. All full-speed devices are supposed to pull D+ high to indicate that they are connected; failure to do this indicates that the device has disconnected or is broken. Can you post an extract from the debugging log for the test where ehci-hcd wasn't loaded?
Created attachment 7417 [details] uhci debug extract
Thanks. I don't know what can be done to fix this. Somehow the dongle has to be told to stop disconnecting itself. But if the only way to communicate with it is via USB, and the problem is that it keeps disconnecting from the USB bus... We're stuck. And no, I have no idea why it works okay under Windows. If you can figure that out, I'll try to implement it for Linux.
Well, just as a little experiment I went into hub.c and redefined HUB_DEBOUNCE_STABLE to 0. On reboot, the bluetooth dongle was recognized and I was able to connect to the Palm Pilot. Does this give any clues about how to do a real fix?
Unfortunately it doesn't. That debounce period is there for a reason; we can't just get rid of it. I don't recall hearing of any devices besides yours having trouble with it. At least now you know a way to work around the problem. That's better than nothing!
Okey doke. Thanks for all your help. I have one final idea that I hope will work... I ran a usb sniffer: http://benoit.papillault.free.fr/usbsnoop/ and had it log XP's communication with the bluetooth. Would you like me to submit it as an attachment (~46k), or is there another Win XP usb sniffer you'd recommend?
I don't think it will help. By the time we're able to communicate with the device, the problem is already over. It's really a question of seeing the communication with the hub or controller the device is plugged into. Is there any way you can sniff that?
I might be a bit closer to what you need. I downloaded this: http://www.hhdsoftware.com/usbmon.html and ran two instances, one to sniff the usb hub and the other to sniff the bluetooth. When I clicked "restart device" for the bluetooth I got log info for both devices. Would you like to see the logfiles?
Sure, attach them to this bug report if they're in a readable form.
Created attachment 7491 [details] sniffer logs
Two things stand out in the hub log. First, the system constantly sends Get-Device-Status to the hub (every 20 ms or so). It's hard to imagine what the reason could be or if that is at all related to your problem. Second, the debounce interval appears to be 50 ms rather than 100 ms. It's hard to say for certain because of the granularity of the time stamps in the log. Anyway, you could try setting the interval to 50 ms for the Linux driver. In drivers/usb/core/hub.c, find the line that says: #define HUB_DEBOUNCE_STABLE 100 and change the 100 to 50. Maybe that will help. Note that the USB specification states that this interval must be at least 100 ms and it must restart if there is a disconnect (section 7.1.7.3, description of delta-t3). Apparently Windows (and perhaps also your bluetooth dongle) is in violation of the spec.
Any updates on the problem, did the fix work for you? Alan, what's your verdict: is this issue resolved? needs some sort of blacklisting?
If I remember right, changing it to 50 didn't work. I wasn't using the bluetooth dongle anyway, so I took it out and nearly forgot that I had one. I'll test again with the latest 2.6.22-rc, but I may not be able to get to it until late this week or early next.
The fix did not work. Using 2.6.22-rc5 I tried HUB_DEBOUNCE_STABLE at 100, 50, 25, 10, 0. 0 was the only value that initialized the bluetooth on startup. With all the other values, I got: hub 4-0:1.0: connect-debounce failed, port 2 disabled
I suppose we could make the debounce interval configurable through sysfs. No other ideas suggest themselves...
Any updates on this problem? Thanks.
May be this soft coul help - http://www.eltima.com/products/usb-test-software/ I use it for bedugging usb protocol. It support only windows but you can use wmware to deal with it.
Any updates?