Ubuntu
udev package

Dell Bluetooth 370 does not work after resume from suspend

Bug #385934 reported by Kai Jauch
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Karmic by Jonathan Rascher

Bug Description

Binary package hint: bluez

The Dell BT 370 does not 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.

ProblemType: Bug
Architecture: amd64
Date: Thu Jun 11 16:10:02 2009
DistroRelease: Ubuntu 9.10
Package: bluez 4.40-0ubuntu1
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-8.9-generic
SourcePackage: bluez
Uname: Linux 2.6.30-8-generic x86_64

Revision history for this message
Kai Jauch (kaijauch) wrote :
Revision history for this message
Mario Limonciello (superm1) wrote :

Thanks for filing a new bug.
So previously we were solving this problem by a pm-utils hack to run hid2hci on resume from S3. Can't do that anymore with the udev rules dynamically filling in the data. So we either needto:
 1) prod the killswitch in the kernel
 2) prod the killswitch in userspace
 3) find a way to have the kernel replay the plugin event.

I think the root of the problem is that the kernel thinks that the device was plugged in throughout the entire suspend, but it really wasn't. (I may be wrong here).

Changed in bluez (Ubuntu):
status: New → Confirmed
Mario Limonciello (superm1)
Changed in dell:
status: New → Confirmed
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

Sorry, so this is no more an udev problem? how is it supposed to work after I enable the hardware killswitch?

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 385934] Re: Dell Bluetooth 370 does not work after resume from suspend

Don't have a solution yet for after S3. The solution might end up in
bluez, maybe udev, maybe the kernel.
It should be working fine however by udev after pressing the killswitch.

Nicolò Chieffo wrote:
> Sorry, so this is no more an udev problem? how is it supposed to work
> after I enable the hardware killswitch?
>
>

--
Mario Limonciello
*Dell | Linux Engineering*
<email address hidden>

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 385934] Re: Dell Bluetooth 370 does not work after resume from suspend

I'm more worried about the killswitch, not S3. also because if
killswitch works you can use it after resume (it's usually the first
thing you do if bt does not work: you switch it off and on to see if
it gets fixed)

Revision history for this message
Kai Jauch (kaijauch) wrote :

Enabling and then disabling the killswitch still works as a workaround to get bluetooth to work again. The problem itself however hasn't changed.
Tested with bluez 4.47-0ubuntu2 and linux-image-2.6.31-5-generic 2.6.31-5.24.

Revision history for this message
Mario Limonciello (superm1) wrote : Re: [Bug 385934] Re: Dell Bluetooth 370 does not work after resume from suspend

So there are two more bits that should be landing that should fix this:

linux-image-2.6.31-6 has a kernel patch that fixes a race condition for
switching the device modes.
udev-146 introduces some logic to rerun hid2hci after resume

Kai Jauch wrote:
> Enabling and then disabling the killswitch still works as a workaround to get bluetooth to work again. The problem itself however hasn't changed.
> Tested with bluez 4.47-0ubuntu2 and linux-image-2.6.31-5-generic 2.6.31-5.24.
>
>

--
Mario Limonciello
*Dell | Linux Engineering*
<email address hidden>

Mario Limonciello (superm1)
affects: bluez (Ubuntu) → udev (Ubuntu)
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Hi Mario,

Could you confirm what udev pieces are remaining? We were already using udev 146, and are now using a GIT HEAD pre-147 - should that have everything?

Changed in udev (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Tony Espy (awe) wrote :

Changing the Status in Dell project to Invalid, as this project is used to track non-public hardware enablement work.

Changed in dell:
status: Confirmed → Invalid
Mario Limonciello (superm1)
Changed in udev (Ubuntu):
status: Incomplete → Fix Released
Timothy R. Chavez (timrchavez)
Changed in somerville:
status: New → Invalid
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

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/1305941

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.