Bug 527350

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.