Bug 5753

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?