Dell Bluetooth 370 does not work after resume from suspend
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
udev (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
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/
ACTION=="add", ENV{ID_
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
ProcVersionSign
SourcePackage: bluez
Uname: Linux 2.6.30-8-generic x86_64
Related branches
Changed in dell: | |
status: | New → Confirmed |
affects: | bluez (Ubuntu) → udev (Ubuntu) |
Changed in udev (Ubuntu): | |
status: | Incomplete → Fix Released |
Changed in somerville: | |
status: | New → Invalid |
no longer affects: | dell |
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).