This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 527350 - Bluetooth isn't working any more
Bluetooth isn't working any more
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-06 00:46 EDT by Arnaud Kleinveld
Modified: 2009-11-05 19:07 EST (History)
9 users (show)

See Also:
Fixed In Version: 4.42-9.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-05 19:07:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Arnaud Kleinveld 2009-10-06 00:46:29 EDT
Description of problem:
Bluetooth isn't working any more. The adapter is not recognised. Messages that appeared in the messages log about recognising the Dell Bluetooth Module are not showing any more.

Version-Release number of selected component (if applicable):
bluez-4.42-6.fc11.i586

How reproducible:
Restart computer and bluetooth will not be available

Steps to Reproduce:
1. Restart computer
2. Open Gnome bluetooth manager and list devices
3. Or check messages log and notice missing usb & bluetooth detection
  
Actual results:
No bluetooth devices available in bluetooth manager. All messages below from expected results are missing

Expected results:
Recognising the USB Dell Wireless 365 Bluetooth Module as it has done before. Messages log when it was still working:

Oct  4 08:46:12 localhost kernel: usb 3-1.3: new full speed USB device using uhci_hcd and address 13
Oct  4 08:46:12 localhost kernel: usb 3-1.3: New USB device found, idVendor=413c, idProduct=8160
Oct  4 08:46:12 localhost kernel: usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct  4 08:46:12 localhost kernel: usb 3-1.3: Product: Dell Wireless 365 Bluetooth Module
Oct  4 08:46:12 localhost kernel: usb 3-1.3: Manufacturer: Dell Computer Corp
Oct  4 08:46:12 localhost kernel: usb 3-1.3: configuration #1 chosen from 1 choice
Oct  4 08:46:12 localhost bluetoothd[1678]: HCI dev 0 registered
Oct  4 08:46:12 localhost bluetoothd[1678]: HCI dev 0 up
Oct  4 08:46:12 localhost bluetoothd[1678]: Starting security manager 0
Oct  4 08:46:12 localhost bluetoothd[1678]: probe failed with driver input-headset for device /org/bluez/1678/hci0/dev_00_25_CF_C1_C8_F1
Oct  4 08:46:12 localhost bluetoothd[1678]: Adapter /org/bluez/1678/hci0 has been enabled

Additional info:
Not sure if it's related but just before the last time it was still working I updated the system. And bluetooth component were updated as well.

Oct  4 23:12:29 localhost yum: Updated: system-config-lvm-1.1.10-1.fc11.noarch
Oct  4 23:12:30 localhost yum: Updated: bluez-libs-4.42-6.fc11.i586
Oct  4 23:12:32 localhost yum: Updated: libchewing-0.3.2-16.fc11.i586
Oct  4 23:12:32 localhost yum: Updated: bluez-cups-4.42-6.fc11.i586
Oct  4 23:13:01 localhost yum: Updated: gnome-settings-daemon-2.26.1-11.fc11.i586
Oct  4 23:13:04 localhost yum: Updated: bouncycastle-1.43-6.fc11.i586
Oct  4 23:13:05 localhost yum: Updated: totem-gstreamer-2.26.3-5.fc11.i586
Oct  4 23:13:06 localhost yum: Updated: samba-winbind-3.4.2-0.42.fc11.i586
Oct  4 23:13:23 localhost yum: Updated: totem-2.26.3-5.fc11.i586
Oct  4 23:13:24 localhost yum: Updated: gnome-bluetooth-libs-2.27.8-3.fc11.i586
Oct  4 23:13:26 localhost yum: Updated: samba-common-3.4.2-0.42.fc11.i586
Oct  4 23:13:27 localhost yum: Updated: totem-nautilus-2.26.3-5.fc11.i586
Oct  4 23:13:27 localhost yum: Updated: libsmbclient-3.4.2-0.42.fc11.i586
Oct  4 23:13:28 localhost yum: Updated: totem-mozplugin-2.26.3-5.fc11.i586
Oct  4 23:13:41 localhost yum: Updated: gnome-bluetooth-2.27.8-3.fc11.i586

I thought it might be the usb connector because I do not see the device with lsusb so I checked if the device was well connected by removing the device physically and putting it back on the motherboard. Unfortunately no results.
Comment 1 Casper Biering 2009-10-07 05:12:37 EDT
I have the exact same problem, which also started occurring after a system upgrade, that included packages:
bluez-4.42-5.fc11.i586 -> bluez-4.42-6.fc11.i586
bluez-libs-4.42-5.fc11.i586 -> bluez-libs-4.42-6.fc11.i586

I was able to find and install the 4.42-4 packages, which made bluetooth working correctly again.

Using the new version (4.42-6), dmesg is missing the following lines:
usb 3-1.3: new full speed USB device using uhci_hcd and address 5
usb 3-1.3: New USB device found, idVendor=413c, idProduct=8156
usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1.3: Product: Dell Wireless 370 Bluetooth Mini-card
usb 3-1.3: Manufacturer: Dell Computer Corp
usb 3-1.3: configuration #1 chosen from 1 choice
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: Generic Bluetooth USB driver ver 0.5
usbcore: registered new interface driver btusb
Comment 2 Casper Biering 2009-10-08 04:43:05 EDT
Found the problem.

In the file /etc/udev/rules.d/bluetooth-hid2hci.rules, replace the lines

ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
    RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"

with

ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_MODEL}=="8154" RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"
ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_MODEL}=="8158" RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"
ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_MODEL}=="8162" RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"
Comment 3 Arnaud Kleinveld 2009-10-11 03:27:35 EDT
I guess that would maybe work if my system would see the usb device first but if I do a lsusb the device id 8160 doesn't show.

Also if I run the hid2hci command manually it returns with:
Device 413c:8160 not found on USB bus
Comment 4 Casper Biering 2009-10-11 15:23:47 EDT
@Arnaud

The device 413c:8160 should apear AFTER you have run the commands:
hid2hci --method dell -v 413c -p 8154
hid2hci --method dell -v 413c -p 8158
hid2hci --method dell -v 413c -p 8162

The above udev rules just call the appropiate hid2hci command when it sees the "trigger" device, which "turns on" bluetooth.
Comment 5 Arnaud Kleinveld 2009-10-11 21:53:23 EDT
Thanks Casper. That works for me.

The command 'hid2hci --method dell -v 413c -p 8162' created the 8160 device which is my missing bluetooth device.

Leaves ne now with bluetooth bug 526142
Comment 6 Laurent Almeras 2009-10-24 14:18:30 EDT
I had the same problem with the same solution (but my productId is 8158).

After a few try, I notice that the rule in /etc/udev/rules.d/bluetooth-hid2hci.rules is right but the RUN command is false. So changing the followinf line :

ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
    RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"

by

ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
    RUN+="/usr/sbin/hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"

I notice also that all the other rules are right (they use full hid2hci path)
Is there anyone who can fix the bluez package ?
Comment 7 Arnaud Kleinveld 2009-10-25 07:38:16 EDT
I have changed the RUN command in bluetooth-hid2hci.rules as you say but it doesn't solve my problem. I still have to run hid2hci manually to get the device enabled.
Comment 8 Laurent Almeras 2009-10-25 09:08:37 EDT
On my side, the following command shows that the line I modify in bluetooth-hid2hci.conf enables the switch at boot :

$ udevadm test /sys/bus/usb/devices/3-1.2\:1.0
...
udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
udev_rules_apply_to_event: RUN 'socket:/var/run/devkit/udev_socket' /etc/udev/rules.d/98-devkit.rules:3
udev_rules_apply_to_event: RUN '/usr/sbin/hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci' /etc/udev/rules.d/bluetooth-hid2hci.rules:12
udevadm_test: run: '/sbin/modprobe -b usb:v413Cp8158d0100dc00dsc00dp00ic03isc01ip02'
udevadm_test: run: 'socket:@/org/freedesktop/hal/udev_event'
udevadm_test: run: 'socket:/var/run/devkit/udev_socket'
udevadm_test: run: '/usr/sbin/hid2hci --method dell -v 413c -p 8158 --mode hci'


(
line 12 in bluetooth-hic2hci.conf is
ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
    RUN+="/usr/sbin/hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
)

If you can find the right usb device path, you can try to see if the udev rule is applied or not.
You can also check if the file content of <path>/bInterfaceClass, <path>/bInterfaceSubClass, <path>/bInterfaceProtocol and <path>/bDeviceClass match the udev rule.
Comment 9 Arnaud Kleinveld 2009-10-27 21:22:15 EDT
Actually it does work now by having changed the RUN rule to the full path of hid2hci. The Dell rule indeed does match. Thanks for the extensive instructions. I'm only left with the issue that I have to run the rule manually when it comes back from suspend, bug 526142
Comment 10 Casper Biering 2009-10-28 06:24:12 EDT
I can also confirm that the original rule works using the full path to hid2hci.
Comment 11 Mohamed M. Hagag 2009-10-31 06:06:02 EDT
Same as casper here, dear developers, plz update the rules file with the full path to hid2hci on F11 and F12/rawhide .
Comment 12 Bastien Nocera 2009-11-02 14:48:35 EST
Please test with:
http://koji.fedoraproject.org/koji/buildinfo?buildID=139403
Comment 13 Laurent Almeras 2009-11-02 16:16:58 EST
Works for me (fc11)
Comment 14 Casper Biering 2009-11-02 17:18:27 EST
bluez-4.42-8.fc11.i586.rpm works for me as well
Comment 15 Arnaud Kleinveld 2009-11-03 03:33:32 EST
Works for me too
Comment 16 Fedora Update System 2009-11-03 05:03:50 EST
bluez-4.42-9.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/bluez-4.42-9.fc11
Comment 17 Mohamed M. Hagag 2009-11-03 09:51:34 EST
works fine here.
Comment 18 Fedora Update System 2009-11-04 07:13:02 EST
bluez-4.42-9.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bluez'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10931
Comment 19 Fedora Update System 2009-11-05 19:07:15 EST
bluez-4.42-9.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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