Feisty: Bluetooth does not until 'hciconfig hci0 reset'
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | linux-source-2.6.20 (Ubuntu) |
Medium
|
Unassigned | ||
Bug Description
Binary package hint: bluez-gnome
I just got a new laptop and Bluetooth does not work at all, not even after installing the BT firmware files from Bluez's website. The bluez-gnome applet is installed and it is told to be discoverable, and yet none of my devices can query my Feisty laptop. And when I tried from the command line "hcitool inq" it timed out!! The bluetooth service is up and running btw without errors! It is very weird, but as it stands right now, I can't use Bluetooth at all.
Here is what lsusb gives me:
Bus 002 Device 004: ID 413c:8126 Dell Computer Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x413c Dell Computer Corp.
idProduct 0x8126
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigura
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 216
bNumInterfaces 4
bConfigurat
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 3
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Interrupt
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Isochronous
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 1
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 1
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 0
bInterfac
bInterfac
bInterfac
iInterface 0
can't get device qualifier: Operation not permitted
can't get debug descriptor: Operation not permitted
cannot read device status, Operation not permitted (1)
| Eugenia Loli-Queru (eloli) wrote : | #1 |
| Eugenia Loli-Queru (eloli) wrote : | #2 |
BTW, the DELL bluetooth module is the one called "Dell 355". The hci_usb module is loaded btw. I really need Bluetooth fixed on my Feisty! It was the reason I bought the laptop. Others have reported success with the dell 355 card.
| Eugenia Loli-Queru (eloli) wrote : | #3 |
After hours of searching I found that this FIXES the problem:
hciconfig hci0 reset
Please ADD a similar command on the Bluetooth Service script!! Without it, the Dell 355 module does not work!
I found the solution here, other people had the same problem:
http://
| Paul Sladen (sladen) wrote : | #4 |
Hi, thanks for you reports people. Does this only occur post suspend/resume or suspend/hibernate, or is the requirement to run 'sudo hciconfig hci0 reset' still there on cold boot up?
| Changed in bluez-gnome: | |
| importance: | Undecided → Medium |
| status: | Unconfirmed → Needs Info |
| Stephan Buys (stephan-buys) wrote : | #5 |
I can confirm that for me this issue exists on a cold boot-up, with Feisty (up to date to 19/3/2007)
| Eugenia Loli-Queru (eloli) wrote : | #6 |
After a cold boot the problem is there. It seems to happen on non-usb bluetooth cards. USB bt dongles seem to get proper initialization by the kernel, but anything else doesn't seem to. From what I saw online, the problem did not occur on older kernels for the same kind of BT model.
| Tollef Fog Heen (tfheen) wrote : | #7 |
Looks like a kernel bug to me
| Changed in linux-source-2.6.20: | |
| status: | Needs Info → Confirmed |
| Efrain Valles (effie-jayx) wrote : | #8 |
I can confirm this bug. I am using a USB dongle (TARGUS MOD# ACB10US).
After I boot. I have to reset the dongle using hciconfig hci0 reset to get it to scan and send or receive files.
I am running feisty and I remember I had to do the same thing on Dapper
hci0: Type: USB
BD Address: 00:16:38:BF:E6:A2 ACL MTU: 1017:8 SCO MTU: 64:8
UP RUNNING
RX bytes:117 acl:0 sco:0 events:16 errors:0
TX bytes:315 acl:0 sco:0 commands:16 errors:0
If I scan
using hcitool
my bluetooth does not even flick a light
Scanning ...
Inquiry failed: Connection timed out
after
I reset hci0
valles@hal2:~$ hcitool scan
Scanning ...
| Ben Collins (ben-collins) wrote : | #9 |
Bug is going to need some dmesg output from latest kernel, and possibly from older kernel (if in fact it did work before).
| Changed in linux-source-2.6.20: | |
| assignee: | nobody → ben-collins |
| status: | Confirmed → Needs Info |
| zeddock (zeddock) wrote : | #10 |
Please tell me how I can help you with that information?
zeddock
| zeddock (zeddock) wrote : Re: [Bug 92111] Re: Feisty: Bluetooth does not until 'hciconfig hci0 reset' | #11 |
I did the reset and still it times out on a scan
zeddock
On 4/10/07, Ben Collins <email address hidden> wrote:
>
> Bug is going to need some dmesg output from latest kernel, and possibly
> from older kernel (if in fact it did work before).
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: (unassigned) => Ben Collins
> Status: Confirmed => Needs Info
>
> --
> Feisty: Bluetooth does not until 'hciconfig hci0 reset'
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
| Ben Collins (ben-collins) wrote : | #12 |
Attach using the web interface (do not paste into comment) the output from these commands:
dmesg > dmesg.txt
Do this for 2.6.20-14, and an older kernel if you have one where this works without problems.
| Eugenia Loli-Queru (eloli) wrote : | #13 |
DMSEG included. I don't have an older kernel to give you though, because this is a brand new laptop. I never had Ubuntu on it before.
| zeddock (jim-leaders) wrote : | #14 |
I have not gotten it to work at all.
zeddock
| Changed in linux-source-2.6.20: | |
| status: | Needs Info → Confirmed |
| zeddock (jim-leaders) wrote : | #15 |
I still am unable to have devices use bluetooth on feisty. I just did another update so attached is the dmseg.
| Changed in linux-source-2.6.20: | |
| assignee: | ben-collins → timg-tpi |
| status: | Confirmed → In Progress |
| rez (rezwanul-kabir) wrote : | #16 |
I have a Dell E1505 with 355 module and I can confirm the issue seen here.
"hcitool scan" fails to scan for BT devices unless
"hciconfig hci0 reset" is run after each reboot.
Setting this workaround in /etc/rc.local will fix the issue.
However, similar workarounds needs to be added during resume from s2ram and/or s2disk as well to activate the adapter.
| Eugenia Loli-Queru (eloli) wrote : | #17 |
Ben, are you working on this bug? It is pretty serious (while not a showstopper).
| zeddock (jim-leaders) wrote : | #18 |
My bluetooth does not work regardless of hciconfig hci0 reset.
So should I file yet another bug on it or what?
Thanx!
zeddock
Eugenia Loli-Queru wrote:
> Ben, are you working on this bug? It is pretty serious (while not a
> showstopper).
>
>
| Eugenia Loli-Queru (eloli) wrote : | #19 |
If Bluetooth is UP and "hcitool scan" timeouts for you, then no, it would be the same bug. If you can scan BT devices without timeouts and you just can't send files and stuff, then yes.
| Tim Gardner (timg-tpi) wrote : | #20 |
A fix has been accepted into the Feisty kernel source that resets the Broadcom device 0x413c:0x8126 when it is initially probed. In the meantime you can test it:
cd /lib/modules/
sudo mv hci_usb.ko hci_usb.ko.old
sudo wget -O hci_usb.ko http://
Its probably easiest to just reboot at this point.
| zeddock (jim-leaders) wrote : | #21 |
Well, it does not say it timed out, but it says it is scanning and then
I get a prompt without any other info.... plus there is no difference if
I apply the suggested procedure to reset.
Whatcha think?
zeddock
Eugenia Loli-Queru wrote:
> If Bluetooth is UP and "hcitool scan" timeouts for you, then no, it
> would be the same bug. If you can scan BT devices without timeouts and
> you just can't send files and stuff, then yes.
>
>
| Eugenia Loli-Queru (eloli) wrote : | #22 |
Zeddock, are you sure you have put your phone or whatever device you want to pair with, to PAIRING mode *and* DISCOVERABLE? If not, please search the forums and google for tutorials. I think your problem is not the same as the one we have here.
Tim, I will test your new module later tonight or tomorrow when I get a chance.
| Tim Gardner (timg-tpi) wrote : | #23 |
The way I tested this was the other way around. I used my cell phone to scan for a bluetooth source on the laptop. Before the fix it found nothing, after the fix it did. I left it at that since it appears to have fixed the startup reset problem.
| zeddock (jim-leaders) wrote : | #24 |
I am not sure since I am new to linux. However, I have done this many
times on MS Windows XP and twice with Xandros, so my guess is that I am
performing the processes correctly.
If you have suggestions or a step-by-step which would help to isolate
what is happening moreso, please let me know.
zeddock
PS. I am going to give Tim's approach a try later, too.
Eugenia Loli-Queru wrote:
> Zeddock, are you sure you have put your phone or whatever device you
> want to pair with, to PAIRING mode *and* DISCOVERABLE? If not, please
> search the forums and google for tutorials. I think your problem is not
> the same as the one we have here.
>
> Tim, I will test your new module later tonight or tomorrow when I get a
> chance.
>
>
| Eugenia Loli-Queru (eloli) wrote : | #25 |
Tim, YES, your patched module FIXES the problem. Now I can scan without a timeout. Please commit the fixes.
| rez (rezwanul-kabir) wrote : | #26 |
The patched driver solves the problem for me as well..
| Changed in linux-source-2.6.20: | |
| status: | In Progress → Fix Committed |
| Changed in linux-source-2.6.20: | |
| assignee: | timg-tpi → ubuntu-kernel-team |
| status: | Fix Committed → Fix Released |
| Changed in redfish: | |
| status: | Unconfirmed → Fix Released |
| Amit Bhutani (amit.bhutani) wrote : | #27 |
Is this patched module in Gutsy T4?
| Tim Gardner (timg-tpi) wrote : | #28 |
Yes - this patch is in Gutsy T4. The patch was submitted upstream.
Gutsy: drivers/
/* Dell laptop with Broadcom chip */
{ USB_DEVICE(0x413c, 0x8126), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
unsubscribe
Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https:/
| Changed in somerville: | |
| status: | New → Fix Released |
| no longer affects: | dell |
| Timothy R. Chavez (timrchavez) wrote : | #31 |
The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https:/
| no longer affects: | somerville |
Some more info from my devices: (not sure which one is the Wifi one and which one is the BT)
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 68/900 us ( 8%), #Int= 4, #Iso= 2
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.20-10-generic uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 3
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0a5c ProdID=4500 Rev= 1.00
S: Manufacturer=
S: Product=BCM2045B2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms
T: Bus=02 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=413c ProdID=8126 Rev= 1.00
S: Manufacturer=
S: Product=BCM2045
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 32 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 32 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
T: Bus=02 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0a5c ProdID=4502 Rev= 1.00
S: Manufacturer=
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
T: Bus=02 Lev=02 Prnt=03 Port=02 Cnt=03 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0a5c ProdID=4503 Rev= 1.00
S: Manufacturer=
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 ...