Dell bluetooth adapters don't return to HCI mode after suspend

I get the following dmesg when disabling the hardware switch:
[ 790.570143] iwlagn: Radio Frequency Kill Switch is On:
[ 790.570149] Kill switch must be turned off for wireless networking to work.
[ 790.792348] usb 1-1: USB disconnect, address 10
[ 790.792356] usb 1-1.1: USB disconnect, address 11
[ 790.804352] usb 1-1.2: USB disconnect, address 12
[ 793.897099] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
[ 793.897114] mac80211-phy0: failed to remove key (0, 02:10:18:01:00:01) from hardware (-5)
[ 793.897215] wlan0: disassociating by local choice (reason=3)
[ 793.927564] iwlagn: Error sending REPLY_ADD_STA: enqueue_hcmd failed: -5
[ 793.927577] mac80211-phy0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-5)

And this when enabling:
[ 835.612312] usb 1-1: new full speed USB device using uhci_hcd and address 13
[ 835.793465] usb 1-1: configuration #1 chosen from 1 choice
[ 835.796747] hub 1-1:1.0: USB hub found
[ 835.799049] hub 1-1:1.0: 3 ports detected
[ 836.083190] usb 1-1.1: new full speed USB device using uhci_hcd and address 14
[ 836.209624] usb 1-1.1: configuration #1 chosen from 1 choice
[ 836.229575] input: HID 413c:8157 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input19
[ 836.265034] generic-usb 0003:413C:8157.0008: input,hidraw1: USB HID v1.11 Keyboard [HID 413c:8157] on usb-0000:00:1a.0-1.1/input0
[ 836.347700] usb 1-1.2: new full speed USB device using uhci_hcd and address 15
[ 836.475948] usb 1-1.2: configuration #1 chosen from 1 choice
[ 836.514721] input: HID 413c:8158 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input20
[ 836.525117] generic-usb 0003:413C:8158.0009: input,hidraw2: USB HID v1.11 Mouse [HID 413c:8158] on usb-0000:00:1a.0-1.2/input0
[ 838.730578] Registered led device: iwl-phy0:radio
[ 838.730618] Registered led device: iwl-phy0:assoc
[ 838.730655] Registered led device: iwl-phy0:RX
[ 838.730690] Registered led device: iwl-phy0:TX
[ 838.747892] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 838.753048] wlan0: direct probe to AP 00:1e:2a:23:e4:c6 try 1
[ 838.911655] wlan0 direct probe responded
[ 838.911667] wlan0: authenticate with AP 00:1e:2a:23:e4:c6
[ 839.071618] wlan0: authenticated
[ 839.071629] wlan0: associate with AP 00:1e:2a:23:e4:c6
[ 839.231864] wlan0: RX AssocResp from 00:1e:2a:23:e4:c6 (capab=0x401 status=0 aid=1)
[ 839.231872] wlan0: associated
[ 839.233877] phy0: failed to restore operational channel after scan
[ 839.234341] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 839.234551] wlan0: disassociating by local choice (reason=3)
[ 849.896074] wlan0: no IPv6 routers present
[ 866.107266] wlan0: authenticate with AP 02:10:18:01:00:01
[ 866.109267] wlan0: authenticate with AP 02:10:18:01:00:01
[ 866.111478] wlan0: authenticated
[ 866.111485] wlan0: associate with AP 02:10:18:01:00:01
[ 866.114943] wlan0: RX AssocResp from 02:10:18:01:00:01 (capab=0x411 status=0 aid=3)
[ 866.114950] wlan0: associated

Now if I run hcitool scan I have this output:
Device is not available: No such device

When I do a /etc/init.d/bluetooth restart I get this dmesg:
[ 964.529392] usb 1-1.2: ...

You must issue the command sudo hid2hci to enable it again, instead of restarting the bluetooth service.
Who should do this? HAL?

Changing to udev

Sorry, you'll have to justify why you think this is a udev problem.

If a tool needs to be run on every type of device, why isn't that the default for that device type in the kernel?

Either way, since the tool is shipped with bluez - the udev rule should be shipped with bluez too

I didn't think of those things: I had a small discussion in the hal
mailing list, and they told me that it was an udev fault.

Also on the bluex mailing list they told that an udev rule is needed,
so that when the bluetooth device connects, automatically udev will
call hid2hci

Actually an udev rule already exists, but it does not work
see file /lib/udev/rules.d/62-bluez-hid2hci.rules

This actually looks like the udev rule just doesn't work on newer versions of udev. Please try this attached rule. If that works, we can see about getting this in an SRU.

It works!

Accepted bluez into jaunty-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package bluez - 4.37-0ubuntu1

---------------
bluez (4.37-0ubuntu1) karmic; urgency=low

  * New upstream version (LP: #367056)
  * debian/hid2hci.rules:
    - Update rule to work properly with newer version of udev. (LP: #330934)
  * debian/rules:
    - ALSA conf that gets installed is now called bluetooth.conf.

 -- Mario Limonciello <email address hidden> Tue, 28 Apr 2009 09:40:54 -0500

Will we see this fixed in Jaunty ? It looks like it only made it into the karmic branch.

@Jerone:
It's in -proposed for the SRU process. Speaking of which, I just did an install on some hardware with a dell BT 370. I added -proposed, and verified it works to flip the SW on and off.

This bug was fixed in the package bluez - 4.32-0ubuntu4.1

---------------
bluez (4.32-0ubuntu4.1) jaunty-proposed; urgency=low

  * debian/hid2hci.rules:
    - Update rule to work properly with newer version of udev. (LP: #330934)

 -- Mario Limonciello <email address hidden> Thu, 23 Apr 2009 10:43:48 -0500

I have a Vostro 1400 (the bluetooth module is a 355). Even I have the bluez (4.32-0ubuntu4.1) I still have problems when the system wakes up from suspend.
The BT module worked without any problem under the 8.10...

Chris

The 355 is not affected by this fix or the same root cause.
Can you please open a different bug to track down that issue?

On 05/15/2009, Chris S <email address hidden> wrote:
> I have a Vostro 1400 (the bluetooth module is a 355). Even I have the bluez
> (4.32-0ubuntu4.1) I still have problems when the system wakes up from
> suspend.
> The BT module worked without any problem under the 8.10...
>
> Chris
>
> --
> Dell bluetooth adapters don't return to HCI mode after suspend
> https://bugs.launchpad.net/bugs/330934
> You received this bug notification because you are a member of The Dell
> Team, which is subscribed to Dell Ubuntu Project.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

The Dell BT 370 still doesn't work after resume from suspend on karmic:
$ hcitool scan
Device is not available: No such device

/lib/udev/rules.d/62-bluez.rules contains:
ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_CLASS}=="mouse", ATTRS{bmAttributes}=="e0", KERNEL=="mouse*", RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"

Doing it manually works:
$ sudo hid2hci --method dell -v 413c -p 8158 --mode hci
Attempting to switch device 413c:8158 to HCI mode was successful

Enabling and disabling the killswitch after resuming from suspend also sets the bluetooth module to the right mode.

bluez 4.40-0ubuntu1
udev 142-2

For karmic this is a new bug actually. It was fixed differently for hardy and intrepid. Karmic introduced a different hid2hci and killswitch interface.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Kai Jauch
Sent: Thursday, June 11, 2009 5:57 AM
To: <email address hidden>
Subject: [Bug 330934] Re: Dell bluetooth adapters don't return to HCI modeafter suspend

The Dell BT 370 still doesn't work after resume from suspend on karmic:
$ hcitool scan
Device is not available: No such device

/lib/udev/rules.d/62-bluez.rules contains:
ACTION=="add", ENV{ID_VENDOR}=="413c", ENV{ID_CLASS}=="mouse", ATTRS{bmAttributes}=="e0", KERNEL=="mouse*", RUN+="/usr/sbin/hid2hci --method dell -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"

Doing it manually works:
$ sudo hid2hci --method dell -v 413c -p 8158 --mode hci
Attempting to switch device 413c:8158 to HCI mode was successful

Enabling and disabling the killswitch after resuming from suspend also
sets the bluetooth module to the right mode.

bluez 4.40-0ubuntu1
udev 142-2

--
Dell bluetooth adapters don't return to HCI mode after suspend
https://bugs.launchpad.net/bugs/330934
You received this bug notification because you are a member of The Dell
Team, which is subscribed to Dell Ubuntu Project.

I'm confirming
I want to say that hid2hci was moved to /lib/udev/hid2hci and 62-bluez.rules to 62-hid2hci.rules
can this be the problem?

it's not jaunty, it's karmic, how can I change it?

please track this in bug 385934. this is a different bug than it was in jaunty (lots of new variables - dell_laptop kernel module, hid2hci in udev, no more hid2hci in pm-utils etc)

Resetting statuses, as this was reopened without comment. "cherry chelsea", when reopening bugs, you must provide a reason.

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://bugs.launchpad.net/bugs/1305927