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.
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
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"
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
@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.
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
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 ?
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.
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.
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
I can also confirm that the original rule works using the full path to hid2hci.
Same as casper here, dear developers, plz update the rules file with the full path to hid2hci on F11 and F12/rawhide .
Please test with: http://koji.fedoraproject.org/koji/buildinfo?buildID=139403
Works for me (fc11)
bluez-4.42-8.fc11.i586.rpm works for me as well
Works for me too
bluez-4.42-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bluez-4.42-9.fc11
works fine here.
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
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.