Bluetooth disabled after resume

[Jean-Pierre Rupp]

On Ubuntu 13.10 a Lenovo X1 Carbon running Ubuntu 64-bit has problems to communicate with bluetooth input devices on resume from suspend. This problem happened only after upgrade to Ubuntu 13.10.

Reloading the module btusb fixes the problem (rmmod btusb; modprobe btusb). Placing the module name btusb in the MODULES parameter on /etc/default/acpi-support does not fix the problem. I had to create a script in /etc/pm/sleep.d/ to make the module reload successfully.

[Jacek (jacek-redhat-bugs)]

Description of problem:
suspend to ram and resume cycle breaks bluetooth

Version-Release number of selected component (if applicable):
kernel 3.10.2-301.fc19.x86_64

How reproducible:
always

Steps to Reproduce:
1. start laptop, use bluetooth mouse
2. suspend laptop to ram (using lid or suspend key combination)
3. wait >20 s
4. resume laptop

Actual results:
bluetooth is not present

Expected results:
bluetooth works mouse connects and works

Additional info:
to force bluetooth to work one has to run
sudo modprobe -r btusb
sudo modprobe btusb

[Jacek (jacek-redhat-bugs)]

*** Bug 980938 has been marked as a duplicate of this bug. ***

[Jacek (jacek-redhat-bugs)]

kernel 3.11.0-0.rc7.git4.1.fc19.x86_64 the same problem

[Jacek (jacek-redhat-bugs)]

kernel 3.11.0-3.fc20.x86_64

the same problem

[Michele (michele-redhat-bugs)]

Hi Jacek,

if you reproduce it on 3.11.X then the following is already included:
commit 502f769662978a2fe99d0caed5e53e3006107381
Author: Shuah Khan <email address hidden>
Date: Tue May 21 09:32:06 2013 -0600

    Bluetooth: Add missing reset_resume dev_pm_ops

so it must be something else. Do you get any messages related to btusb in /var/log/messages?

cheers,
Michele

[Jacek (jacek-redhat-bugs)]

Michele,

No nothing specific, here is what I get when I resume machine:

Sep 8 12:45:39 jacek kernel: [30486.586778] ACPI: Low-level resume complete
Sep 8 12:45:39 jacek kernel: [30486.586778] PM: Restoring platform NVS memory
Sep 8 12:45:39 jacek kernel: [30486.587038] Enabling non-boot CPUs ...
Sep 8 12:45:39 jacek kernel: [30486.587081] smpboot: Booting Node 0 Processor 1 APIC 0x1
Sep 8 12:45:39 jacek kernel: [30486.598618] CPU1 is up
Sep 8 12:45:39 jacek kernel: [30486.601790] ACPI: Waking up from system sleep state S3
Sep 8 12:45:39 jacek kernel: [30486.673111] ehci-pci 0000:00:1a.7: System wakeup disabled by ACPI
Sep 8 12:45:39 jacek kernel: [30486.673159] snd_hda_intel 0000:00:1b.0: power state changed by ACPI to D0
Sep 8 12:45:39 jacek kernel: [30486.684790] uhci_hcd 0000:00:1d.0: System wakeup disabled by ACPI
Sep 8 12:45:39 jacek kernel: [30486.684927] uhci_hcd 0000:00:1d.2: System wakeup disabled by ACPI
Sep 8 12:45:39 jacek kernel: [30486.695096] ehci-pci 0000:00:1d.7: System wakeup disabled by ACPI
Sep 8 12:45:39 jacek kernel: [30486.728552] PM: noirq resume of devices complete after 77.413 msecs
Sep 8 12:45:39 jacek kernel: [30486.728855] PM: early resume of devices complete after 0.250 msecs
Sep 8 12:45:39 jacek kernel: [30486.729272] usb usb3: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30486.729480] usb usb4: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30486.729684] usb usb5: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30486.730563] usb usb6: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30486.730768] usb usb7: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30486.730973] usb usb8: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30487.109303] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Sep 8 12:45:39 jacek kernel: [30487.111057] ata5: SATA link down (SStatus 0 SControl 300)
Sep 8 12:45:39 jacek kernel: [30487.116335] ata2.00: configured for UDMA/33
Sep 8 12:45:39 jacek kernel: [30487.118079] usb 2-3: reset high-speed USB device number 2 using ehci-pci
Sep 8 12:45:39 jacek kernel: [30487.353353] usb 7-2: reset full-speed USB device number 2 using uhci_hcd
Sep 8 12:45:39 jacek kernel: [30488.638337] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 8 12:45:39 jacek kernel: [30488.937953] ata1.00: configured for UDMA/133
Sep 8 12:45:39 jacek kernel: [30488.938165] sd 0:0:0:0: [sda] Starting disk
Sep 8 12:45:39 jacek kernel: [30488.960865] INFO @wl_cfg80211_resume : device is not ready : status (0)
Sep 8 12:45:39 jacek kernel: [30488.960914] dpm_run_callback(): wiphy_resume+0x0/0x100 [cfg80211] returns -5
Sep 8 12:45:39 jacek kernel: [30488.960917] PM: Device phy0 failed to resume: error -5
Sep 8 12:45:39 jacek kernel: [30488.960979] PM: resume of devices complete after 2232.118 msecs
Sep 8 12:45:39 jacek systemd: Time has been changed
Sep 8 12:45:39 jacek kernel: [30488.961638] Restarting tasks ... done.
Sep 8 12:45:39 jacek kernel: [30489.108303] video LNXVIDEO:01: Restoring backlight state
Sep 8 12:45:39 jacek systemd-sleep: System resumed.
Sep 8 12:45:39 jacek kernel:...

[Jacek (jacek-redhat-bugs)]

the above is for fedora 19 tunning on 3.11.0-300.fc20.x86_64 kernel

[Hans (hans-redhat-bugs)]

*** Bug 1010649 has been marked as a duplicate of this bug. ***

[Hans (hans-redhat-bugs)]

Hi all,

I just hit the same problem, and I've managed to fix it for my case (Dell E6430 laptop with integrated bluetooth).

(In reply to Michele Baldessari from comment #4)
> Hi Jacek,
>
> if you reproduce it on 3.11.X then the following is already included:
> commit 502f769662978a2fe99d0caed5e53e3006107381
> Author: Shuah Khan <email address hidden>
> Date: Tue May 21 09:32:06 2013 -0600
>
> Bluetooth: Add missing reset_resume dev_pm_ops
>
> so it must be something else. Do you get any messages related to btusb in
> /var/log/messages?

Hi Michele, small world :)

I believe that, that commit is actually the culprit causing the btusb suspend resume issues various people are seeing. Still a very useful comment, once I saw the comment, I reverted that commit and the problem was gone :) See the commit message of the patch I've submitted upstream for this as for why the original commit is a bad idea and reverting it fixes things at least for me.

Jacek, are you 100% sure you saw this with 3.10.2-301.fc19.x86_64 ? That does not stroke with my theory that the above commit is the cause. You dmesg which says:
Sep 8 12:45:39 jacek kernel: [30486.730768] usb usb7: root hub lost power or was reset
Sep 8 12:45:39 jacek kernel: [30487.353353] usb 7-2: reset full-speed USB device number 2 using uhci_hcd

and lsusb:
Bus 007 Device 002: ID 0a5c:21b4 Broadcom Corp. BCM2070 Bluetooth 2.1 + EDR

Strongly correlate with what was wrong in my case and my theory for this.

To all, who are seeing this, can you please try installing this (somewhat older) kernel:
http://koji.fedoraproject.org/koji/buildinfo?buildID=438054

And see if it fixes things, to install this use ie:
sudo rpm -ivh --oldpackage kernel-3.10.3-300.fc19.x86_64.rpm

This should fix things, reboot into this kernel and do a suspend + resume and then do:
dmesg | grep reset_resume, you should then see messages like this one:

[ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb?
[ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?"

And your bluetooth should still work.

I'll attach the patch I send upstream for this.

Regards,

Hans

[Hans (hans-redhat-bugs)]

Created attachment 804422
PATCH: Regression fix revert: "Bluetooth: Add missing reset_resume dev_pm_ops"

[Hans (hans-redhat-bugs)]

Justin, sorry to needinfo you, but I think it would be good for the patch I've attached to get added to the current Fedora kernel builds, and I don't know any other way to get this bug to stand out in the large mass of kernel bugs ...

[Jacek (jacek-redhat-bugs)]

Hello Hans,

There is something wrong with your theory I'm afraid.

I have been just following your procedure to get things working and reverted kernel to 3.10.3. as you suggested.

I rebooted the system

$uname -a
Linux jacek 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

and run suspend/resume cycle.

Here is what I found in the dmesg
[ 438.624397] usb 7-2: reset full-speed USB device number 2 using uhci_hcd
[ 438.761172] btusb 7-2:1.0: no reset_resume for driver btusb?
[ 438.761177] btusb 7-2:1.1: no reset_resume for driver btusb?

[ 442.303134] Bluetooth: hci0 command 0x1009 tx timeout

Unfortunately my btusb does not want to resume. Last working were 3.9 kernels.

Meanwhile I made a dirty workaround. I created

/usr/lib/systemd/system-sleep/remove-btusb.sh

file containing:

#!/bin/bash
[ "$1" = "post" ] && /usr/sbin/modprobe btusb ; /usr/sbin/modprobe -r btusb ; /usr/bin/sleep 1 ; /usr/sbin/modprobe btusb
[ "$1" = "pre" ] && exec /usr/sbin/modprobe -r btusb
exit 0

It works only when I remove and insert btusb module twice during resume/suspend :(

[Jacek (jacek-redhat-bugs)]

The above it true for Fedora 19 running all kernels starting from 3.10 line up to
kernel-3.12.0-0.rc2.git3.1.fc19.x86_64 which I'm using right now.

[Hans (hans-redhat-bugs)]

Hi,

(In reply to Jacek Pawlyta from comment #12)
> The above it true for Fedora 19 running all kernels starting from 3.10 line
> up to
> kernel-3.12.0-0.rc2.git3.1.fc19.x86_64 which I'm using right now.

Bummer, so it seems that 3.10 has another btusb suspend/resume regression, since 3.11 definitely breaks it on my laptop, and my patch fixes it on my laptop. I was hoping it would also fix yours, but if 3.10 is broken for you then it likely won't.

This is a bit weird though, since without the reset_resume a full reset + driver reload is done on resume, so you should have a pristine state on resume.

Maybe it is a bluez problem? Have you tried doing a "systemctl restart bluetooth.service" after resume ?

Regards,

Hans

[Jacek (jacek-redhat-bugs)]

Hello Hans,

reloading bluetooth.service even several times doesn't help.
It is probably something wrong with the device reset.

Jacek

[Berend (berend-redhat-bugs)]

Quickest repeatable get-it-up-again for me after resume:

- GnomeShell -> Bluetooth -> off.
- GnomeShell -> Bluetooth -> on.
- GnomeShell -> Bluetooth -> Mouse -> on.

NOTE: that I have to switch the individual devices on again. Bluetooth -> off appears to turn all devices off, but Bluetooth -> on doesn't trigger them back on.

Turning just the device off and back on does not help.

I don't believe this runs rmmod btusb. This does trigger systemd bluetooth.target stop and start.

kernel 3.11.1-200.fc19 (I've got older ones downloaded and installed, I'll try some more)

Intel 8087:07da Bluetooth USB in a Samsung 900X.

[Hans (hans-redhat-bugs)]

(In reply to Berend De Schouwer from comment #15)
> Quickest repeatable get-it-up-again for me after resume:
>
> - GnomeShell -> Bluetooth -> off.
> - GnomeShell -> Bluetooth -> on.
> - GnomeShell -> Bluetooth -> Mouse -> on.
>
> NOTE: that I have to switch the individual devices on again. Bluetooth ->
> off appears to turn all devices off, but Bluetooth -> on doesn't trigger
> them back on.
>
> Turning just the device off and back on does not help.
>
> I don't believe this runs rmmod btusb. This does trigger systemd
> bluetooth.target stop and start.
>
> kernel 3.11.1-200.fc19 (I've got older ones downloaded and installed, I'll
> try some more)
>
> Intel 8087:07da Bluetooth USB in a Samsung 900X.

Hmm, that is not a dual role (hid/hci) controller AFAIK. Still the problem could be the reset_resume thing, can you try using a 3.10 kernel, ie:

http://koji.fedoraproject.org/koji/buildinfo?buildID=438054

And see if it fixes things, to install this use ie:
sudo rpm -ivh --oldpackage kernel-3.10.3-300.fc19.x86_64.rpm

Also a dmesg | tail -n 40 output from after toggling the bluetooth on/off would be useful. Turning bluetooth off will run "rfkill block bluetooth" under the hood, and on some laptop's the firmware rfkill interface will power of the entire usb device when that happens, in effect simulating a rmmod.

[Berend (berend-redhat-bugs)]

Created attachment 804989
40 lines up-to and including bluetooth on/off

40 lines up-to and including bluetooth on/off

[Berend (berend-redhat-bugs)]

Created attachment 804994
lsusb of 8087:07da

lsusb of 8087:07da

[Hans (hans-redhat-bugs)]

(In reply to Berend De Schouwer from comment #17)
> Created attachment 804989 [details]
> 40 lines up-to and including bluetooth on/off
>
> 40 lines up-to and including bluetooth on/off

As I suspected turning bluetooth on/off drops the device from the usb-bus, and then it gets fully re-initialized. I suspect / hope downgrading to a 3.10 kernel will fix the issue for you, in which case you like are being hit by the suspend_resume issue too.

[Berend (berend-redhat-bugs)]

3.10.3-300.fc19 WorksForMe(tm)

Tested with 60 second sleep and mouse powerdown.

[Hans (hans-redhat-bugs)]

(In reply to Berend De Schouwer from comment #20)
> 3.10.3-300.fc19 WorksForMe(tm)
>
> Tested with 60 second sleep and mouse powerdown.

Good to hear, then you are very likely being hit by the problems caused by 3.11 adding an (incomplete) reset_resume handler too. Bummer that Jacek's problem seems to be different :|

[Jacek (jacek-redhat-bugs)]

the new kernel: 3.12.0-0.rc4.git2.1.fc19.x86_64

still has this bug

[George (george-redhat-bugs)]

Hi Hans,

I hit this problem on my laptop with Intel N-2230 BGN WiFi + bluetooth card, linux 3.11.x .
It seems that the upcoming (3.12) kernel also has this issue.

I tested your patch on my archlinux setup and I can confirm that it works for me.
arch forum thread: https://bbs.archlinux.org/viewtopic.php?id=170970
arch bug report: https://bugs.archlinux.org/task/37320
Unfortunately I had no luck finding any useful info on my distro forums and bug tracker so I'm posting here as it seems to be a more friendly place.

This is as far as I could track the issue and your patch
http://thread.gmane.org/gmane.linux.kernel.stable/65406/focus=66112
but I see no further developments.

Is there any chance your patch gets merged upstream?

Best regards,
G.

[Hans (hans-redhat-bugs)]

Hi,

(In reply to George from comment #23)
> Hi Hans,
>
> Is there any chance your patch gets merged upstream?

I've gotten confirmation from upstream that my patch has been accepted upstream, so I expect it to show up in the upstream kernels eventually.

Regards,

Hans

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[christopher pijarski (kpijarski)]

jean-pierre what was the script? does it just unload the module before the computer goes to sleep? i am having exactly the same problem, and with bluetoot mouse & keyboard this is really annoying... thanks!

[Jean-Pierre Rupp (xenog)]

This script reloads the Bluetooth module at wake-up time. I don't think this is a defintive solution for this problem, since the module is supposed to be reloaded by the power manager through other means, but that fails to activate Bluetooth for some reason.

[Rolf Reintjes (rolf-reintjes)]

I have the same problem.

I close my Lenovo Thinkpad R61i notebook with Ubuntu 13.10 and cinnamon and it enters standby. When I open the notebook, the system wakes up but my bluetooth mouse Logitech M555b does not work.

This is my workaround:

edit:

/etc/default/acpi-support

with

STOP_SERVICES="bluetooth"

and edit:

/usr/lib/pm-utils/defaults

with

SUSPEND_MODULES="btusb"

the workaround works fine.

[Rolf Reintjes (rolf-reintjes)]

May be this is the same bug:

https://bugzilla.redhat.com/show_bug.cgi?id=988481

[Russell Faull (rfaull)]

Is this bug confined to Lenovo? I have a Lenovo T400 with 13.10 and suffered the same problem until I used Jean-Pierre's script #3 (Thanks). Using the Fn/F5 combination several time will bring back Bluetooth, but it's clumsy. Earlier Ubuntu releases work fine.

[Rolf Reintjes (rolf-reintjes)]

Here https://bugzilla.redhat.com/show_bug.cgi?id=988481#c8 also a Dell notebook has the problem.

[Russell Faull (rfaull)]

Rolf, thanks for pointing that out. I should have read your post before suggesting a hardware (Lenovo-related) issue.

[Jeremy (jeremy-redhat-bugs)]

Hi Hans,

Kernel 3.11.8 was released on Wednesday, still with no sign that your patch made it in. It has been two weeks since your last inquiry on the kernel usb list with no response. Is this a governance issue for the stable kernel tree? As you yourself have pointed out, this bug is affecting many people. The 3.11 kernel has been broken in this way since its release. Your patch has been available for over six weeks. How do we ensure inclusion of the patch in the next 3.11 and 3.12 releases?

Thanks,
Jeremy

[Hans (hans-redhat-bugs)]

Hi Jeremy,

The patch has finally found its way into Linus' tree, once Linus releases 3.13-rc1 it will get added to the
stable series for 3.11 and 3.12.

Regards,

Hans

[Jeremy (jeremy-redhat-bugs)]

Thank you, Hans. As always, your work is greatly appreciated.

[PG (nedamdam)]

Jean-Pierre thanks so much! Can't imagine how much I was googling for more days till I landed here. All other solutions dead ends...
The rmmod btusb; modprobe btusb works fine.
Also T400 13.10 64bit 3.12 kernel here . Since I have no idea about Linux yet, tried the 3.13 (12) kernel that did not help either.
And the FN F5 combo doesn't bring my BT back. Or maybe I did that wrong....

Once it got stuck completely, I could not restart it. Shutting down the computer did not help either.
Or BT on/off. Till it somehow crashed and started again. I was about to re-install the whole system...

[MNLipp (mnl)]

I can confirm the problem for T530.

[W.C. (w.c.-redhat-bugs)]

Is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1010410?

[Hans (hans-redhat-bugs)]

(In reply to W.C. Epperson from comment #28)
> Is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1010410?

Yes, thanks for noticing that.

This is fixed in the new stable kernels released 2 days ago: 3.12.2 & 3.11.10 . An update to these should hopefully become available soon.

[Hans (hans-redhat-bugs)]

*** Bug 1010410 has been marked as a duplicate of this bug. ***

[Garry (garry-redhat-bugs)]

I couldn't find a Fedora 19 build for this kernel so I installed kernel-3.11.10-300.fc20.x86_64 and it fixes the problem for me on the Dell XPS-13. (I reported bug 1010410.)

[W.C. (w.c.-redhat-bugs)]

(In reply to Hans de Goede from comment #29)
> (In reply to W.C. Epperson from comment #28)
> > Is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1010410?
>
> Yes, thanks for noticing that.
>
> This is fixed in the new stable kernels released 2 days ago: 3.12.2 &
> 3.11.10 . An update to these should hopefully become available soon.

Thank YOU for fixing this. I can upgrade to F20 to resolve.

And then wait for the next suspend/resume bluetooth mouse regression. These have been happening intermittently since around F15. Now that the lid events don't seem to be firing pm-suspend any more (logs don't get written, hooks don't get run), they've become increasing more difficult to hack through.

[W.C. (w.c.-redhat-bugs)]

Confirmed that update to F20 restored BT mouse suspend/resume functionality on this HP DV6-1030us with Rocketfish Apple mouse.

[Jacek (jacek-redhat-bugs)]

I'm very sorry to say this, but kernel-3.11.10 does not fix the bug for me,
the only solution working for me to get the btusb up after suspend/resume is to add a file removebtusb.sh containing:

#!/bin/sh.
case $1 in.
   pre).
    /usr/sbin/modprobe -r btusb
    ;;
   post).
    /usr/sbin/modprobe -r btusb.
    /usr/sbin/modprobe btusb
    /usr/sbin/modprobe -r btusb.
    /usr/sbin/modprobe btusb
    ;;
esac

into /usr/lib/systemd/system-sleep/ directory

[RudraB (rudrab-redhat-bugs)]

kernel 3.11 solved the problem for me

[Jeremy (jeremy-redhat-bugs)]

Why was there no kernel-3.11.10 build for F19 in koji?

[Josh (josh-redhat-bugs)]

It just hasn't been built yet. It will be.

[tomasi (tomasi-redhat-bugs)]

I want to confirm, this issue is fixed in version 3.12.2-031202-generic #201311291538.
BT mouse is working after suspend.
Thanks.

[Jeremy (jeremy-redhat-bugs)]

Also working with kernel-3.11.10-200.fc19

[Fedora (fedora-redhat-bugs)]

kernel-3.11.10-200.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2013-22669/kernel-3.11.10-200.fc19

[Fedora (fedora-redhat-bugs)]

kernel-3.11.10-200.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.

[W.C. (w.c.-redhat-bugs)]

Regression returned with kernel-3.13.10-200.fc20, was resolved again with kernel-3.14.2-200.fc20

[Michael (michael-redhat-bugs)]

Problem was gone, has re-appeared with kernel 3.14.5-200.fc20.x86_64 (ThinkPad T530).

[penalvch (penalvch)]

Jean-Pierre Rupp, thank you for reporting this bug to Ubuntu. Saucy reached EOL on July 17, 2014.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases

Is this reproducible in the latest release of Ubuntu via http://cdimage.ubuntu.com/daily-live/current/ ?

If so, please execute the following via a terminal in order for the necessary debugging information to be attached:
apport-collect 1242310

[Murz (murznn)]

I can confirm that this issue is reproducible on Ubuntu 14.04, 14.10 and 15.04 with Lenovo X230 notebook: when notebook resume from suspend, Bluetooth is unavailable.

[penalvch (penalvch)]

Murz, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

[W.C. (w.c.-redhat-bugs)]

Problem re-appeared at 4.4.9-200.fc22.x86_64

[Hans (hans-redhat-bugs)]

Hi,

(In reply to W.C. Epperson from comment #44)
> Problem re-appeared at 4.4.9-200.fc22.x86_64

This likely is a different problem, the the btusb driver still does not have a .reset_resume handler (as it should), which was the original problem.

Regards,

Hans

[W.C. (w.c.-redhat-bugs)]

(In reply to Hans de Goede from comment #45)
> Hi,
>
> (In reply to W.C. Epperson from comment #44)
> > Problem re-appeared at 4.4.9-200.fc22.x86_64
>
> This likely is a different problem, the the btusb driver still does not have
> a .reset_resume handler (as it should), which was the original problem.
>
> Regards,
>
> Hans

Point taken. I should have said "behavior" not "problem".

Thanks,
Jake

[penalvch (penalvch)]

OR using EOL release, and no response for years.