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
*** Bug 980938 has been marked as a duplicate of this bug. ***
kernel 3.11.0-0.rc7.git4.1.fc19.x86_64 the same problem
kernel 3.11.0-3.fc20.x86_64 the same problem
Hi Jacek, if you reproduce it on 3.11.X then the following is already included: commit 502f769662978a2fe99d0caed5e53e3006107381 Author: Shuah Khan <shuah.kh> 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
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: [30489.194056] IPv6: ADDRCONF(NETDEV_UP): p5p1: link is not ready Sep 8 12:45:39 jacek systemd: Started Suspend. Sep 8 12:45:39 jacek systemd: Requested transaction contradicts existing jobs: File exists Sep 8 12:45:39 jacek systemd: Service sleep.target is not needed anymore. Stopping. Sep 8 12:45:39 jacek systemd: Stopping Sleep. Sep 8 12:45:39 jacek systemd: Stopped target Sleep. Sep 8 12:45:39 jacek systemd: Reached target Suspend. Sep 8 12:45:39 jacek systemd-logind: Operation finished. Sep 8 12:45:39 jacek NetworkManager[666]: <info> wake requested (sleeping: yes enabled: yes) Sep 8 12:45:39 jacek NetworkManager[666]: <info> waking up and re-enabling... and my usb devices: Bus 002 Device 002: ID 5986:0145 Acer, Inc Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 002: ID 0a5c:21b4 Broadcom Corp. BCM2070 Bluetooth 2.1 + EDR Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub moreover, now I need to run modprobe -r btusb modprobe btusb twice to get my bt working There is what i see in /var/log/messages after first reloading of btusb: Sep 8 12:51:59 jacek kernel: [30869.125544] usbcore: registered new interface driver btusb Sep 8 12:51:59 jacek systemd: Starting Bluetooth. Sep 8 12:51:59 jacek systemd: Reached target Bluetooth. Sep 8 12:52:01 jacek fprintd: ** Message: No devices in use, exit Sep 8 12:52:01 jacek kernel: [30871.140266] Bluetooth: hci0 command 0x1009 tx timeout Hope it helps Jacek
the above is for fedora 19 tunning on 3.11.0-300.fc20.x86_64 kernel
*** Bug 1010649 has been marked as a duplicate of this bug. ***
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 <shuah.kh> > 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
Created attachment 804422 [details] PATCH: Regression fix revert: "Bluetooth: Add missing reset_resume dev_pm_ops"
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 ...
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 :(
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.
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
Hello Hans, reloading bluetooth.service even several times doesn't help. It is probably something wrong with the device reset. Jacek
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.
(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.
Created attachment 804989 [details] 40 lines up-to and including bluetooth on/off 40 lines up-to and including bluetooth on/off
Created attachment 804994 [details] lsusb of 8087:07da lsusb of 8087:07da
(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.
3.10.3-300.fc19 WorksForMe(tm) Tested with 60 second sleep and mouse powerdown.
(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 :|
the new kernel: 3.12.0-0.rc4.git2.1.fc19.x86_64 still has this bug
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.
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
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
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
Thank you, Hans. As always, your work is greatly appreciated.
Is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1010410?
(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.
*** Bug 1010410 has been marked as a duplicate of this bug. ***
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.)
(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.
Confirmed that update to F20 restored BT mouse suspend/resume functionality on this HP DV6-1030us with Rocketfish Apple mouse.
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
kernel 3.11 solved the problem for me
Why was there no kernel-3.11.10 build for F19 in koji?
It just hasn't been built yet. It will be.
I want to confirm, this issue is fixed in version 3.12.2-031202-generic #201311291538. BT mouse is working after suspend. Thanks.
Also working with kernel-3.11.10-200.fc19
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
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.
Regression returned with kernel-3.13.10-200.fc20, was resolved again with kernel-3.14.2-200.fc20
Problem was gone, has re-appeared with kernel 3.14.5-200.fc20.x86_64 (ThinkPad T530).
Problem re-appeared at 4.4.9-200.fc22.x86_64
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
(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