Bug 10126

Reply-To: akpm@linux-foundation.org

On Wed, 27 Feb 2008 17:11:41 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=10126
> 
>            Summary: Cambridge Silicon Radio USB bt dongle support broken
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.25-rc3
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Bluetooth
>         AssignedTo: drivers_bluetooth@kernel-bugs.osdl.org
>         ReportedBy: kelk1@comcast.net
> 
> 
> Latest working kernel version: 
> Works fine with 2.6.23.1
> 
> Earliest failing kernel version: 
> 2.6.24-rc?
> 
> Distribution: Mandriva cooker
> Hardware Environment: Dell Dimension, 1 P4 w/ HT. Dongle on uhci port.
> 
> Software Environment: 
> libusb0.1_4-0.1.12-9mdv2008.1
> bluez-utils-3.27-1mdv2008.1
> # hciconfig hci0 version
> hci0:   Type: USB
>         BD Address: 00:03:0D:00:15:47 ACL MTU: 192:8 SCO MTU: 64:8
>         HCI Ver: 1.1 (0x1) HCI Rev: 0xbc LMP Ver: 1.1 (0x1) LMP Subver: 0xbc
>         Manufacturer: Cambridge Silicon Radio (10)
> 
> Problem Description: 
> Since 2.6.24, the kernel locked the machine when I tried to use this
> bluetooth
> USB dongle.
> A new patch (http://lkml.org/lkml/2008/2/26/67) now prevents the crash, but
> the
> dongle is still unusable, usually giving a 'connection reset by peer' error
> 
> Steps to reproduce:
> # hciconfig hci0 up
> # sdptool -i hci0 browse <btaddr>
> 
> I selected bluetooth for component, but that might be a usb issue. USB itself
> seems to work fine otherwise (I have a custom app linked with libusb that
> uses
> bulk I/O).

hm, I don't think that much changed between 2.6.23 and 2.6.24 in bluetooh,
yet we have a regression.

And afaik most or all of the recent bluetooth fixes were in 2.6.25-rc3.

On Thu, Feb 28, 2008 at 9:51 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 27 Feb 2008 17:11:41 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
>
>  > http://bugzilla.kernel.org/show_bug.cgi?id=10126
>  >
>  >            Summary: Cambridge Silicon Radio USB bt dongle support broken
>  >            Product: Drivers
>  >            Version: 2.5
>  >      KernelVersion: 2.6.25-rc3
>  >           Platform: All
>  >         OS/Version: Linux
>  >               Tree: Mainline
>  >             Status: NEW
>  >           Severity: normal
>  >           Priority: P1
>  >          Component: Bluetooth
>  >         AssignedTo: drivers_bluetooth@kernel-bugs.osdl.org
>  >         ReportedBy: kelk1@comcast.net
>  >
>  >
>  > Latest working kernel version:
>  > Works fine with 2.6.23.1
>  >
>  > Earliest failing kernel version:
>  > 2.6.24-rc?
>  >
>  > Distribution: Mandriva cooker
>  > Hardware Environment: Dell Dimension, 1 P4 w/ HT. Dongle on uhci port.
>  >
>  > Software Environment:
>  > libusb0.1_4-0.1.12-9mdv2008.1
>  > bluez-utils-3.27-1mdv2008.1
>  > # hciconfig hci0 version
>  > hci0:   Type: USB
>  >         BD Address: 00:03:0D:00:15:47 ACL MTU: 192:8 SCO MTU: 64:8
>  >         HCI Ver: 1.1 (0x1) HCI Rev: 0xbc LMP Ver: 1.1 (0x1) LMP Subver:
>  0xbc
>  >         Manufacturer: Cambridge Silicon Radio (10)
>  >
>  > Problem Description:
>  > Since 2.6.24, the kernel locked the machine when I tried to use this
>  bluetooth
>  > USB dongle.
>  > A new patch (http://lkml.org/lkml/2008/2/26/67) now prevents the crash,
>  but the
>  > dongle is still unusable, usually giving a 'connection reset by peer'
>  error
>  >
>  > Steps to reproduce:
>  > # hciconfig hci0 up
>  > # sdptool -i hci0 browse <btaddr>
>  >
>  > I selected bluetooth for component, but that might be a usb issue. USB
>  itself
>  > seems to work fine otherwise (I have a custom app linked with libusb that
>  uses
>  > bulk I/O).
>
>  hm, I don't think that much changed between 2.6.23 and 2.6.24 in bluetooh,
>  yet we have a regression.
>
>  And afaik most or all of the recent bluetooth fixes were in 2.6.25-rc3.
>

Yes, it's weird. I have asked Quel Qun to send the hcidump &dmesg info
in the original reporting thread.

Created attachment 15040 [details]
Hcidump with working rfcomm connect under 2.6.23.1

dump with working 'rfcomm -i hci0 1 00:80:37:24:34:27 1', terminated with Ctrl-C

Created attachment 15041 [details]
Hcidump with non working rfcomm connect under 2.6.25-rc3

Same command fails with connection reset by peer.
Note: kernel = 2.6.25-rc3 + anti-oops 1 line patch in l2cap.c

Created attachment 15042 [details]
dmesg with 2.6.25-rc3

Output of dmesg after the rfcomm connect failed.

On Thu, Feb 28, 2008 at 10:01 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
>
> On Thu, Feb 28, 2008 at 9:51 AM, Andrew Morton
>  <akpm@linux-foundation.org> wrote:
>  > On Wed, 27 Feb 2008 17:11:41 -0800 (PST) bugme-daemon@bugzilla.kernel.org
>  wrote:
>  >
>  >  > http://bugzilla.kernel.org/show_bug.cgi?id=10126
>  >  >
>  >  >            Summary: Cambridge Silicon Radio USB bt dongle support
>  broken
>  >  >            Product: Drivers
>  >  >            Version: 2.5
>  >  >      KernelVersion: 2.6.25-rc3
>  >  >           Platform: All
>  >  >         OS/Version: Linux
>  >  >               Tree: Mainline
>  >  >             Status: NEW
>  >  >           Severity: normal
>  >  >           Priority: P1
>  >  >          Component: Bluetooth
>  >  >         AssignedTo: drivers_bluetooth@kernel-bugs.osdl.org
>  >  >         ReportedBy: kelk1@comcast.net
>  >  >
>  >  >
>  >  > Latest working kernel version:
>  >  > Works fine with 2.6.23.1
>  >  >
>  >  > Earliest failing kernel version:
>  >  > 2.6.24-rc?
>  >  >
>  >  > Distribution: Mandriva cooker
>  >  > Hardware Environment: Dell Dimension, 1 P4 w/ HT. Dongle on uhci port.
>  >  >
>  >  > Software Environment:
>  >  > libusb0.1_4-0.1.12-9mdv2008.1
>  >  > bluez-utils-3.27-1mdv2008.1
>  >  > # hciconfig hci0 version
>  >  > hci0:   Type: USB
>  >  >         BD Address: 00:03:0D:00:15:47 ACL MTU: 192:8 SCO MTU: 64:8
>  >  >         HCI Ver: 1.1 (0x1) HCI Rev: 0xbc LMP Ver: 1.1 (0x1) LMP Subver:
>  0xbc
>  >  >         Manufacturer: Cambridge Silicon Radio (10)
>  >  >
>  >  > Problem Description:
>  >  > Since 2.6.24, the kernel locked the machine when I tried to use this
>  bluetooth
>  >  > USB dongle.
>  >  > A new patch (http://lkml.org/lkml/2008/2/26/67) now prevents the crash,
>  but the
>  >  > dongle is still unusable, usually giving a 'connection reset by peer'
>  error
>  >  >
>  >  > Steps to reproduce:
>  >  > # hciconfig hci0 up
>  >  > # sdptool -i hci0 browse <btaddr>
>  >  >
>  >  > I selected bluetooth for component, but that might be a usb issue. USB
>  itself
>  >  > seems to work fine otherwise (I have a custom app linked with libusb
>  that uses
>  >  > bulk I/O).
>  >
>  >  hm, I don't think that much changed between 2.6.23 and 2.6.24 in
>  bluetooh,
>  >  yet we have a regression.
>  >
>  >  And afaik most or all of the recent bluetooth fixes were in 2.6.25-rc3.
>  >
>
>  Yes, it's weird. I have asked Quel Qun to send the hcidump &dmesg info
>  in the original reporting thread.
>

Could you apply the below debug patch and send the broken dmesg?

Thanks.

Created attachment 15079 [details]
enable l2cap debug

>Could you apply the below debug patch and send the broken dmesg?
Said to Quel Qun :) 
Actually I'm not skilled in bugzilla, the attachment can not be found in the bugzilla page, now attach it via web page.

Created attachment 15092 [details]
l2cap debug part of dmesg

Same rfcomm command

weird,
1) might caused by
hci_cmd_task: hci0 command tx timeout

2) get command_rej 
l2cap_command_rej: reason 0, info_state 2, info_ident 1, cmd->ident 18

now the info_timer timeout is not triggered, so the timer should be deleted in
hci_conn_del.

For timer corruption bug it will be safer as followning :

if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_SENT)
        del_timer_sync(&conn->info_timer);

But why timeout and get command rej, marcel, do you have any clue?

Quel Qun, could you try reset before connecting?
hciconfig hci0 reset

Sorry for the delay. I had tried reset before, that did not change anything.
I have now tried several other dongles (cambridge and broadcom based), and none of them works with newer kernels.

Maybe it's not related to the dongle, but to other parts of the Bluetooth stack?

I can use 2.6.24 kernels (from Ubuntu 8.04) to connect to my Sony-Ericsson phone with "pand" (role PANU), but all later kernels I've tried (from Ubuntu 8.10 and later) fail to connect in the same way.

It sounds like the "fixes" in 2.6.25-rc3 may be the culprit.  It's really helpful to know where to look, thanks.  Sometime I'll try the vanilla kernels either side of that version.

What tools can I use to debug how the kernels are behaving differently w.r.t. Bluetooth protocol when doing a pan connection?

Thanks.

I should note, the reason I pounced on this bug is because I have similar problems with breakage occurring between those kernel versions - and I have a Cambridge Silicon Radio USB built in to my laptop.

I am testing with kernel 2.6.32-5 on IA32 based (IBM compatible) computers.

I am still getting timeout errors here.

My bluetooth adapter model is as follows:

NANO TINY USB 2.0 BLUETOOTH ADAPTER DONGLE EDR WIRELESS
Part number 500792110001
Barcode 2000000529837

# hciconfig -a                                                      
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
        UP RUNNING
        RX bytes:330 acl:0 sco:0 events:8 errors:0
        TX bytes:24 acl:0 sco:0 commands:16 errors:8
        Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT
Can't read local name on hci0: Connection timed out (110)

# dmesg
[127422.591465] hci_cmd_task: hci0 command tx timeout

# lsusb
Bus 003 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

I have just tested this with the experimental kernel version 2.6.36-rc5, and the timeout error still occurs:

hciconfig -a hci0                                                  
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
        UP RUNNING 
        RX bytes:59 acl:0 sco:0 events:5 errors:0
        TX bytes:15 acl:0 sco:0 commands:7 errors:2
        Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: 
        Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)

After giving up on bluetooth for 2 years, I decided last week to try once more to fix my problem.

It turns out that the remote device I was trying to connect to was not fully compliant with v1.2, and rejected as 'not understood' the request about extended features instead of returning 0 (meaning not supporting any extended feature).

< ACL data: handle 40 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
> ACL data: handle 40 flags 0x02 dlen 10
    L2CAP(s): Command rej: reason 0
      Command not understood

I do not know _why_, but with this condition, I could establish an rfcomm link once and disconnect, but could never connect again. The only way to reconnect was to reset the remote device.

We fixed the remote firmware and now that it returns 0, I am able to disconnect and reconnect at will. That was last week, using a 2.6.35.6-desktop-1mnb (Mandriva) kernel.

As far as I am concerned, my problem is fixed, but the kernel could probably address this situation and handle the rejection more nicely.

I have just tested this again. This time with the experimental kernel version 2.6.37-rc5. The timeout error still occurs, so it looks like THE KERNEL IS STILL BROKEN:

hciconfig -a                                                                 
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
        UP RUNNING 
        RX bytes:413 acl:0 sco:0 events:18 errors:0
        TX bytes:67 acl:0 sco:0 commands:21 errors:4
        Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: RSWITCH HOLD SNIFF PARK 
        Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)

Mark.

FWIW reset does not work either:

hciconfig hci0 reset
Can't init device hci0: Connection timed out (110)

Mark.

I have just tested this again with experimental kernel version 2.6.38-rc6:

This time, no initial timeout occurs with hciconfig:

hciconfig -a hci0

hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
        DOWN 
        RX bytes:342 acl:0 sco:0 events:10 errors:0
        TX bytes:33 acl:0 sco:0 commands:11 errors:1
        Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
        Link policy: 
        Link mode: SLAVE ACCEPT

However, when an attempt is made to switch the device into operational mode, the timeout error reappears:

hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

I guess that this is still broken.

Here is some output from dmesg:

[ 4687.820084] usb 3-2: new full speed USB device using uhci_hcd and address 28
[ 4687.972291] usb 3-2: New USB device found, idVendor=0a12, idProduct=0001
[ 4687.972301] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 5533.236067] usb 3-2: reset full speed USB device using uhci_hcd and address 28
[ 5533.382757] btusb 3-2:1.0: no reset_resume for driver btusb?
[ 5533.382766] btusb 3-2:1.1: no reset_resume for driver btusb?

I have just tested this again with experimental kernel 2.6.39-rc4-486 (Debian 2.6.39~rc4-1~experimental.1). The problem is still occuring with that kernel build:

# hciconfig -a
hci0: Type: BR/EDR Bus: USB
        BD Address: 00:1F:81:00:01:1C ACL MTU: 1021:4 SCO MTU: 180:1
        DOWN
        RX bytes:68 acl:0 sco:0 events:6 errors:0
        TX bytes:18 acl:0 sco:0 commands:36 errors:30
        Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy:
        Link mode: SLAVE ACCEPT

# hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

Mark.

Having the same issue with Fedora 14. 
I'm getting a lot of "hci_cmd_task: hci0 command tx timeout" errors in dmesg. If I'm patient, I can get the device to work, though. After a couple of "hciconfig hci0 reset" the Gnome bluetooth-icon shows up and I can connect my Bluetooth keyboard. It seems like there must be a certain amount of time between requests to the bluetooth dongle, if I try to connect the keyboard right after the icon shows up, it produces a timeout. If I wait a couple of minutes and click connect, I get a "Introduce PIN for pairing" from the KDE bluetooth bluedevil service (I'm using both applets to get it working) window and about 50% of the requests lead to a successful connect of my keyboard. If it is connected correctly it works flawlessly until the next reboot.
Here is a log of that behavior:

[ 9006.666054] usb 1-1.1.1: new full speed USB device using ehci_hcd and address 12
[ 9006.755985] usb 1-1.1.1: New USB device found, idVendor=0a12, idProduct=0001
[ 9006.755991] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 9265.040728] bluedevil-reque[15541]: segfault at 28 ip 000000374506b89d sp 00007fffce4e1980 error 4 in libkdeui.so.5.6.0[3744e00000+42f000]
[ 9269.425240] input: Logitech Elite Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:0/input18
[ 9269.425537] generic-bluetooth 0005:046D:B301.0006: input,hidraw4: BLUETOOTH HID v23.02 Keyboard [Logitech Elite Keyboard] on 00:1F:81:00:08:3

Notice the USB ids of that log, they show the id of the Cambridge Silicon Bluetooth dongle.

I have three different USB devices here, each of them equipped with the same chip (I was hoping to get one with another chipset to get rid of that...), all showing the same behavior (including the successful connects if you are patient).


Here is some more debug output:
# lsusb|grep Cambridge
Bus 001 Device 011: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

# uname -a
Linux dw-cbayer 2.6.35.12-90.fc14.x86_64 #1 SMP Fri Apr 22 16:01:29 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

# hciconfig 
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1F:81:00:08:30  ACL MTU: 1021:4  SCO MTU: 180:1
        UP RUNNING PSCAN 
        RX bytes:26383 acl:1366 sco:0 events:137 errors:0
        TX bytes:706 acl:14 sco:0 commands:45 errors:4

Forgot to mention: my bluez-version:

Name        : bluez
Arch        : x86_64
Version     : 4.77
Release     : 1.fc14

Btw. if someone is interested in debugging (and solving) this issue I am very willing to donate my defunct bluetooth usb keys. I will mail them out to anyone for free if you get this thing to work.

The same is happening to me in Debian squeeze with different device:

Linux 2.6.32-5-amd64


# lsusb | grep Broad
Bus 005 Device 003: ID 0a5c:2021 Broadcom Corp.

# hciconfig -a hci0
hci0:	Type: BR/EDR  Bus: USB
	BD Address: 00:1A:7D:0A:60:D3  ACL MTU: 377:10  SCO MTU: 16:0
	UP RUNNING 
	RX bytes:664 acl:0 sco:0 events:18 errors:0
	TX bytes:77 acl:0 sco:0 commands:20 errors:0
	Features: 0xff 0xff 0x0d 0x38 0x08 0x08 0x00 0x00
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: 
	Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)

# dmesg | tail -n1
[19113.451914] hci_cmd_task: hci0 command tx timeout

A few days ago I updated to Fedora kernel 2.6.35.13-91.fc14.x86_64. Now it does not work anymore, no matter how hard I try or how patient I am. I'm getting hci_cmd_task: hci0 command tx timeout all the time, no connect attempt works anymore.

Opening up one of my dongles with a screwdriver, there is a marking on the board "AS3620QA1". This appears to be a code for Accel Semiconductor, so the Nano Tiny devices that are causing an error may not be made by Cambridge Silicon Radio after all, even though the devices list as Cambridge Silicon Radio.

Mark.

If anyone wants to try and create a working driver for dongles containing  AS3620QA series chipsets, I can stick one in the post.

Tried with different dongle with Broadcom Chipset:

[25894.595473] usb 1-1.1.1.3: new full speed USB device using ehci_hcd and address 15
[25894.673381] usb 1-1.1.1.3: New USB device found, idVendor=0a5c, idProduct=2148
[25894.673384] usb 1-1.1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[25894.673391] usb 1-1.1.1.3: Product: BCM92046DG-CL1ROM
[25894.673394] usb 1-1.1.1.3: Manufacturer: Broadcom Corp
[25894.673397] usb 1-1.1.1.3: SerialNumber: 000272A784D2

lsusb gives this:
[...]
Bus 001 Device 015: ID 0a5c:2148 Broadcom Corp. 
Bus 001 Device 014: ID 0a5c:4503 Broadcom Corp. 
Bus 001 Device 013: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface Subclass)
Bus 001 Device 012: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
[...]

This dongle works out of the box here.

Yeah, I was thinking of buying another dongle. I saw some BlueNEXT dongles at a good price on Amazon. I wonder if they work. It doesn't say what chipset they are. Reviews told me to buy Cambridge Silicon Radio, which is why I bought this last batch, but it turns out they are not really CSR. Some people seem to have problems with Broadcom based dongles, so it is interesting that yours work fine. I wonder if there are different versions of the chip, or maybe there have been some fixes since the problems were reported.

I would prefer adapters that have inbuilt firmware, rather than requiring swirmware images to be uploaded from the host, and they must work with open source drivers.

I have a broadcom and cambridge adapters, I cannot make the broadcom work anymore, but I found a work around the cambridge one. I think my issue is with the USB.

With the module ehci_hcd no bluetooth dongle works, but I think this one enables correct power to the USB.

So if I load the ehci_hcd module, then unload it, and use uhci_hcd only, the Cambridge adapter, after few resets and re-plugging I get it to work.

*** Bug 19832 has been marked as a duplicate of this bug. ***

*** Bug 42750 has been marked as a duplicate of this bug. ***

*** Bug 18932 has been marked as a duplicate of this bug. ***