bluetooth service does not restart after a suspend to ram

[Clusty]

After a suspend to RAM my wireless mouse does not reconnect.
I have to restart the bluetooth service manually to reconnect.

The mouse is a Microsoft mouse 5000 and the laptop is a Sony Vaio sz-420N

Maybe this could be made automatically?

[phenest (steve-clark)]

I can confirm this. After resuming, the Bluetooth service needs restart manually.

Ubuntu Intrepid Alpha 5
Linux precision 2.6.27-3-generic #1 SMP Wed Sep 10 16:18:52 UTC 2008 x86_64 GNU/Linux

Dell Precision M90

[Emmet Hikory (persia)]

The bluetooth stack in intrepid recently underwent significant change. Could you retest and confirm is this is still an issue?

[Mario Limonciello (superm1)]

I can confirm that this occurs. Devices need to be switched from hid->hci mode again after suspend.

The question is whether this fix should land in pm-utils and checking for hid2hci to be available, or if we should only include it in bluez package, but hte pm-utils /usr/lib/pm-utils/sleep.d directory.

[Mario Limonciello (superm1)]

This script dropped in /usr/lib/pm-utils/sleep.d will resolve the issue after it's determined where to put it.

[Chow Loong Jin (hyperair)]

I believe this fix should be dropped into /usr/lib/pm-utils/sleep.d directory by bluez.

[Mario Limonciello (superm1)]

Here's the debdiff for doing it with pm-utils. Subscribing ubuntu-release

[Chow Loong Jin (hyperair)]

On Tue, 2008-10-21 at 20:01 +0000, Mario Limonciello wrote:
> Here's the debdiff for doing it with pm-utils. Subscribing ubuntu-
> release
>
> ** Attachment added: "pm-utils.debdiff"
> http://launchpadlibrarian.net/18779789/pm-utils.debdiff
>
> ** Changed in: bluez (Ubuntu)
> Status: Confirmed => Won't Fix
>
> ** Changed in: pm-utils (Ubuntu)
> Status: New => Confirmed
>
I believe you added the sleep hook in the wrong package. From pm-utils
source, I found a file called README.distributions, saying this:
Note for distro maintainers:

When writing sleep hooks, please consider adding any needed hooks to the
package
that requires the hooks, rather than pm-utils.

An example would be if you distro wants anacrom to run on resume -- the
optimal
fix would be to have the anacron package install a hook in
/usr/lib/pm-utils/sleep.d that wakes anacron up on resume.

This will also help package maintenance by allowing package maintainers
to
keep track of what the best way to handle any suspend/resume
functionality their
package requires insteas of leaving it up to the pm-utils maintainers to
guess
at what functionality is needed.

In other words, please put the hook in bluez, not in pm-utils.
--
Chow Loong Jin

[Steve Langasek (vorlon)]

I agree that it seems more appropriate to ship this hook in the bluez package, instead of in pm-utils.

Otherwise, the script looks reasonable to me.

[Martin Pitt (pitti)]

OK, I'm convinced. Mario, please upload bluez with that script.

[Mario Limonciello (superm1)]

fix committed to bluez bzr and submitted upstream.

[vlowther (victor-lowther)]

On Wed, 2008-10-22 at 20:59 +0000, Mario Limonciello wrote:
> fix committed to bluez bzr and submitted upstream.

One other thing that might be useful would be for hcitool (or hid2hci)
to query and save the current state of the adaptors when suspending, and
then just restore the adaptors to the saved state upon resume.

> ** Changed in: bluez (Ubuntu)
> Assignee: (unassigned) => Mario Limonciello (superm1)
> Status: Confirmed => Fix Committed
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

[Mario Limonciello (superm1)]

Unfortunately, this information can't be queried in any standard fashion
right now. These adapters don't all necessarily act like standard bluetooth
radio when in HID mode.

On Wed, Oct 22, 2008 at 19:18, vlowther <email address hidden> wrote:

> On Wed, 2008-10-22 at 20:59 +0000, Mario Limonciello wrote:
> > fix committed to bluez bzr and submitted upstream.
>
> One other thing that might be useful would be for hcitool (or hid2hci)
> to query and save the current state of the adaptors when suspending, and
> then just restore the adaptors to the saved state upon resume.
>
> > ** Changed in: bluez (Ubuntu)
> > Assignee: (unassigned) => Mario Limonciello (superm1)
> > Status: Confirmed => Fix Committed
> >
> --
> Victor Lowther
> RHCE# 805008539634727
> LPIC-2# LPI000140019
>
> --
> bluetooth service does not restart after a suspend to ram
> https://bugs.launchpad.net/bugs/268877
> You received this bug notification because you are a bug assignee.
>

--
Mario Limonciello
<email address hidden>

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 4.12-0ubuntu4

---------------
bluez (4.12-0ubuntu4) intrepid; urgency=low

  * Add hid2hci.patch to enable hid2hci to be ran after
    suspending a machine. (LP: #268877)
  * debian/rules:
    - Install new script from above patch.
  * Add logitech_5500_ids.patch for enabling hid2hci on
    more logitech devices. (LP: #272352)

 -- Mario Limonciello <email address hidden> Wed, 22 Oct 2008 16:01:59 -0500

[Martin G Miller (mgmiller)]

I am running Ubuntu 8.10 32 bit.

I have a Logitech Dinovo Edge bluetooth keyboard/trackpad that used to work correctly after suspend resume until the latest update to package bluez 4.12-0ubuntu5. Now I must unplug and replug the bluetooth dongle to get it to work again following a resume from s3 sleep.

I also had to change /etc/default/bluetooth to read "HID2HCI_ENABLED=0" or I have nothing at all on bootup.

[Martin G Miller (mgmiller)]

After examing the patch above, I see it is setting HID2HCI back to 1 or enabled. This disables my keyboard/trackpad and the only way I can get it to work on boot or resume is if I have this setting disabled. Apparently, the Logitch dinovo edge dongle does not work in HCI mode. Is there some way an exception can be written into this patch or bluez can be updated to reflect this fact for the dinovo edge?

I will try either removing the patch or editing it to HID2HCI=0

[Martin G Miller (mgmiller)]

If I change this command in your patch:

 if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
  /usr/sbin/hid2hci --tohci

to read:

if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
  /usr/sbin/hid2hci --tohid

I have my bluetooth keyboard back after resume from standy.

Apparently, even though it is testing for HCI_ENABLED = 1 as the "if" part of the command, it is executing even when HID2HCI_ENABLED=0 is set in /etc/default/bluetooth

[Mario Limonciello (superm1)]

After entering hci mode, try to pair your keyboard using the bluez
gnome ui. The computer won't know about IT otherwise.

On 11/15/2008, Martin G Miller <email address hidden> wrote:
> If I change this command in your patch:
>
> if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
> /usr/sbin/hid2hci --tohci
>
> to read:
>
> if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
> /usr/sbin/hid2hci --tohid
>
> I have my bluetooth keyboard back after resume from standy.
>
> Apparently, even though it is testing for HCI_ENABLED = 1 as the "if"
> part of the command, it is executing even when HID2HCI_ENABLED=0 is set
> in /etc/default/bluetooth
>
> --
> bluetooth service does not restart after a suspend to ram
> https://bugs.launchpad.net/bugs/268877
> You received this bug notification because you are a bug assignee.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

[Chow Loong Jin (hyperair)]

On Sat, 2008-11-15 at 23:12 +0000, Martin G Miller wrote:
> If I change this command in your patch:
>
> if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
> /usr/sbin/hid2hci --tohci
>
> to read:
>
> if [ "$HID2HCI_ENABLED" = "1" ] && [ -x /usr/sbin/hid2hci ]; then
> /usr/sbin/hid2hci --tohid
>
> I have my bluetooth keyboard back after resume from standy.
>
> Apparently, even though it is testing for HCI_ENABLED = 1 as the "if"
> part of the command, it is executing even when HID2HCI_ENABLED=0 is set
> in /etc/default/bluetooth
>
This is pretty surprising. I've tried the following:
1. Set HID2HCI_ENABLED=0 in /etc/default/bluetooth, and then manually
run
PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci

This results in no error message.

2. Set HID2HCI_ENABLED=1 in /etc/default/bluetooth, and the manually run
PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci

This results in the error message "No devices in HID mode found".

This indicates that the hook is working properly. Perhaps
your /etc/default/bluetooth file is malformed?
--
Chow Loong Jin

[Martin G Miller (mgmiller)]

Mario Limonciello wrote:
"After entering hci mode, try to pair your keyboard using the bluez
gnome ui. The computer won't know about IT otherwise."

If I have bluetooth set to HCI, the utility does not detect the keyboard dongle. Pressing the pairing button does not work. I have to unplug the dongle and plug it back it to get it to function.

The only way I can do anything if it's set to HCI is to use a PS/2 keyboard mouse to run the GUI. This defeats the purpose of having the bluetooth mouse. Especially for a HTPC which is 15 feet away.

Chow Loong Jin wrote:
"Perhaps your /etc/default/bluetooth file is malformed?"

Here is the contents of this file:
# Defaults for bluez

# start bluetooth on boot?
# compatibility note: If this variable is not found bluetooth will
# start
BLUETOOTH_ENABLED=1

# This setting will switch HID devices (e.g mouse/keyboad) to HCI mode, that is
# you will have bluetooth functionality from your dongle instead of only HID.
# Note that not every bluetooth dongle is capable of switching back to HID
# mode, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355497
HID2HCI_ENABLED=0
HID2HCI_UNDO=1

Notice the HID2HCI_ENABLED=0, this is the only way I can get the keyboard recognized on boot or resume from S3 sleep. My dongle needs to stay HID or it won't work.

What is the purpose for the last line in the file? "HID2HCI_UNDO=1"

[Martin G Miller (mgmiller)]

Chow Loong Jin wrote:
"1. Set HID2HCI_ENABLED=0 in /etc/default/bluetooth, and then manually
run
PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci

This results in no error message."

This would not give an error message as it has just switched the device from HID to HCI mode.

Then, if you do:
"2. Set HID2HCI_ENABLED=1 in /etc/default/bluetooth, and the manually run
PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci

This results in the error message "No devices in HID mode found"."

This confirms that the HCI mode is still enabled from the previous command, which should not be the case.

Is there any way to determine the status of the device before and after issuing the commands? That way you could boot with HID2HCI_ENABLED=0 set and test to see that it is in fact in HID mode. Then run the command:
"PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci"
and again test to see what mode the device is in. I believe it is changing to HCI even though it shouldn't be.

[Chow Loong Jin (hyperair)]

On Sun, 2008-11-16 at 13:40 +0000, Martin G Miller wrote:
> Chow Loong Jin wrote:
> "1. Set HID2HCI_ENABLED=0 in /etc/default/bluetooth, and then manually
> run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in no error message."
>
> This would not give an error message as it has just switched the device
> from HID to HCI mode.
>
It would for me because I don't have any bluetooth devices.
> Then, if you do:
> "2. Set HID2HCI_ENABLED=1 in /etc/default/bluetooth, and the manually run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in the error message "No devices in HID mode found"."
>
> This confirms that the HCI mode is still enabled from the previous
> command, which should not be the case.
Basically running the command complains because I do not have any
bluetooth devices. Well I do, but it's not enabled, and doesn't show up
in lsusb. If it complains (on my system), that means the command is run.
If it doesn't, it isn't run. Simple as that.
>
> Is there any way to determine the status of the device before and after issuing the commands? That way you could boot with HID2HCI_ENABLED=0 set and test to see that it is in fact in HID mode. Then run the command:
> "PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions /usr/lib/pm-utils/sleep.d/48hid2hci"
> and again test to see what mode the device is in. I believe it is changing to HCI even though it shouldn't be.
>
You could test the hook by modifying the /usr/sbin/hid2hci --tohci to
have an echo in front. Then see if it's printed when you run the
PM_FUNCTIONS... command. I highly doubt it's the hook that's causing the
problem.

--
Chow Loong Jin

[Mario Limonciello (superm1)]

I'm wondering if your device needs a reset quirk and that's why HCI mode
isn't working with it.

Try creating a file /etc/modprobe.d/btusb with the following contents:

options btusb reset=1

Unplug the dongle, rmmod btusb plug it in again, and then get the device
back into HCI mode using hid2hci again. See if you are able to pair in the
UI now. If so, that requires an extra kernel quirk.

On Sun, Nov 16, 2008 at 07:40, Martin G Miller <email address hidden>wrote:

> Chow Loong Jin wrote:
> "1. Set HID2HCI_ENABLED=0 in /etc/default/bluetooth, and then manually
> run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in no error message."
>
> This would not give an error message as it has just switched the device
> from HID to HCI mode.
>
> Then, if you do:
> "2. Set HID2HCI_ENABLED=1 in /etc/default/bluetooth, and the manually run
> PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci
>
> This results in the error message "No devices in HID mode found"."
>
> This confirms that the HCI mode is still enabled from the previous
> command, which should not be the case.
>
>
> Is there any way to determine the status of the device before and after
> issuing the commands? That way you could boot with HID2HCI_ENABLED=0 set
> and test to see that it is in fact in HID mode. Then run the command:
> "PM_FUNCTIONS=/usr/lib/pm-utils/pm-functions
> /usr/lib/pm-utils/sleep.d/48hid2hci"
> and again test to see what mode the device is in. I believe it is changing
> to HCI even though it shouldn't be.
>
> --
> bluetooth service does not restart after a suspend to ram
> https://bugs.launchpad.net/bugs/268877
> You received this bug notification because you are a bug assignee.
>

--
Mario Limonciello
<email address hidden>

[Martin G Miller (mgmiller)]

I tried what you said. rmmod btusb resulted in "ERROR: Module btusb does not exist in /proc/modules" Even though the file was there and it was set as executable.

The device was not visible in the UI. On resume from standby, it was also non functional until I unplugged and replugged the dongle. I have removed the file /etc/modprobe.d/btusb to get normal function back.

At the same time as I am experiencing this bug, I also have another that started in the last few days where I can only go in and out of standby once per session. On the 2nd attempt at standby the system freezes with a black screen and blinking cursor, requiring a hard shut off at the tower.

Both of these problems seemed to happen at the same time, with updates in the last few days.

I am going to try a 64 bit install to see if there is any difference.