Bug 10126 - Cambridge Silicon Radio USB bt dongle support broken
Cambridge Silicon Radio USB bt dongle support broken
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Bluetooth
All Linux
: P1 normal
Assigned To: drivers_bluetooth@kernel-bugs.osdl.org
:
: dio 19832 42750 (view as bug list)
Depends on:
Blocks: 9243
  Show dependency treegraph
 
Reported: 2008-02-27 17:11 UTC by Quel Qun
Modified: 2015-02-19 15:11 UTC (History)
16 users (show)

See Also:
Kernel Version: 3.0
Tree: Mainline
Regression: Yes


Attachments
Hcidump with working rfcomm connect under 2.6.23.1 (1.47 KB, application/octet-stream)
2008-02-27 18:20 UTC, Quel Qun
Details
Hcidump with non working rfcomm connect under 2.6.25-rc3 (1.39 KB, application/octet-stream)
2008-02-27 18:22 UTC, Quel Qun
Details
dmesg with 2.6.25-rc3 (21.35 KB, text/plain)
2008-02-27 18:25 UTC, Quel Qun
Details
enable l2cap debug (1.04 KB, patch)
2008-02-28 21:35 UTC, Dave Young
Details | Diff
l2cap debug part of dmesg (2.30 KB, text/plain)
2008-02-29 08:44 UTC, Quel Qun
Details

Description Quel Qun 2008-02-27 17:11:40 UTC
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).
Comment 1 Anonymous Emailer 2008-02-27 17:53:03 UTC
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.

Comment 2 Dave Young 2008-02-27 18:02:32 UTC
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.

Comment 3 Quel Qun 2008-02-27 18:20:28 UTC
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
Comment 4 Quel Qun 2008-02-27 18:22:49 UTC
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
Comment 5 Quel Qun 2008-02-27 18:25:44 UTC
Created attachment 15042 [details]
dmesg with 2.6.25-rc3

Output of dmesg after the rfcomm connect failed.
Comment 6 Dave Young 2008-02-28 21:24:20 UTC
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.
Comment 7 Dave Young 2008-02-28 21:35:20 UTC
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.
Comment 8 Quel Qun 2008-02-29 08:44:40 UTC
Created attachment 15092 [details]
l2cap debug part of dmesg

Same rfcomm command
Comment 9 Dave Young 2008-03-02 18:27:40 UTC
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?
Comment 10 Dave Young 2008-03-03 22:05:25 UTC
Quel Qun, could you try reset before connecting?
hciconfig hci0 reset
Comment 11 Quel Qun 2008-04-03 15:17:17 UTC
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.
Comment 12 Jamie Lokier 2009-01-27 10:53:32 UTC
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.
Comment 13 Jamie Lokier 2009-01-27 10:55:45 UTC
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.
Comment 14 Mark Hobley 2010-07-16 22:52:07 UTC
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)
Comment 15 Mark Hobley 2010-10-04 20:55:45 UTC
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)
Comment 16 Quel Qun 2010-10-04 22:46:15 UTC
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.
Comment 17 Mark Hobley 2010-12-11 21:30:49 UTC
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.
Comment 18 Mark Hobley 2010-12-11 21:33:22 UTC
FWIW reset does not work either:

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

Mark.
Comment 19 Mark Hobley 2011-02-27 06:40:30 UTC
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?
Comment 20 Mark Hobley 2011-05-02 19:02:01 UTC
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.
Comment 21 Christian Bayer 2011-05-04 15:35:49 UTC
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
Comment 22 Christian Bayer 2011-05-04 15:39:29 UTC
Forgot to mention: my bluez-version:

Name        : bluez
Arch        : x86_64
Version     : 4.77
Release     : 1.fc14
Comment 23 Christian Bayer 2011-05-04 18:31:13 UTC
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.
Comment 24 Juan Augusto ossi 2011-05-14 01:32:10 UTC
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
Comment 25 Christian Bayer 2011-06-01 13:19:53 UTC
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.
Comment 26 Mark Hobley 2011-06-21 23:09:08 UTC
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.
Comment 27 Mark Hobley 2011-06-22 12:38:39 UTC
If anyone wants to try and create a working driver for dongles containing  AS3620QA series chipsets, I can stick one in the post.
Comment 28 Christian Bayer 2011-06-27 19:15:26 UTC
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.
Comment 29 Mark Hobley 2011-06-27 22:03:40 UTC
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.
Comment 30 Juan Augusto ossi 2011-06-27 22:38:45 UTC
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.
Comment 31 Alan 2012-08-13 16:52:06 UTC
*** Bug 19832 has been marked as a duplicate of this bug. ***
Comment 32 Alan 2012-08-30 14:32:33 UTC
*** Bug 42750 has been marked as a duplicate of this bug. ***
Comment 33 Alan 2013-12-10 22:09:42 UTC
*** Bug 18932 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.