Bug 1338015 - Bluetooth stops working after resume from suspend
Summary: Bluetooth stops working after resume from suspend
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Don Zickus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-20 17:52 UTC by seeker_moc
Modified: 2016-07-24 01:36 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-24 01:36:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot showing Blueman error message (256.78 KB, image/png)
2016-05-20 17:52 UTC, seeker_moc
no flags Details

Description seeker_moc 2016-05-20 17:52:00 UTC
Created attachment 1160020 [details]
screenshot showing Blueman error message

Description of problem:

After resuming from suspend, bluetooth stops working. The Blueman applet states "Resource Not Ready.." and gives the error message shown in the attached screenshot. Attempting to restart the bluetooth via:

sudo modprobe -r btusb; sudo modprobe btusb

as mentioned in a previous bug does not fix the problem. The bluetooth device is the Intel 7265 combo wifi/bluetooth card. The wifi still works after resume. The bluetooth resumes working normally after a full restart with no other action required.

Version-Release number of selected component (if applicable):

Fedora 24 Beta. Problem was not present before upgrading from Fedora 23.

How reproducible:

Steps to Reproduce:
1. Use a bluetooth mouse (or possibly other BT device, not tested)
2. Suspend the laptop via menu option or closing lid
3. Resume laptop
4. Bluetooth no longer works. Everything else works as expected.

Actual results:
Bluetooth no longer functions following resume from suspend

Expected results:
Bluetooth continues to work as normal

Additional info:
This is my first time manually reporting a bug, please let me know if you need further information or if I didn't follow correct procedure.

Comment 1 Raphael Groner 2016-05-20 18:18:51 UTC
Thanks for your report.

Can you try with 2.0.4-2 from updates-testing? We saw some issues with dbus/systemd.

Comment 3 seeker_moc 2016-05-20 18:33:46 UTC
I downloaded that update with koji and installed (I'm not sure if that's how I'm supposed to do that, I didn't see it in dnf update). Anyway, after a reboot it broke my bluetooth altogether. When I tried to click on the Blueman applet, it said my bluetooth was disabled, and asked me to click to enable it. Doing so did not fix the problem. I'm now getting the same error as before, but fresh after a reboot where it would previously work, no need to suspend/resume to trigger the problem.

Comment 4 seeker_moc 2016-05-20 18:40:05 UTC
Rebooting again did not fix the problem. Downgrading the package back to 2.0.4-1 and rebooting restored BT initial functionally. However, confirmed that bluetooth still stops functioning after suspend/resume.

Comment 5 leigh scott 2016-05-20 20:42:02 UTC
This is more likely to be a bluez or kernel issue

Comment 6 Don Zickus 2016-05-23 14:00:19 UTC
Hi,

What version of Bluez are you running?  (yum list bluez) The latest is 5.39.

Cheers,
Don

Comment 7 seeker_moc 2016-05-23 17:46:21 UTC
Bluez 5.39-1.fc24 x86_64

Comment 8 Langdon White 2016-05-23 22:05:46 UTC
I am not sure if this is related, but when I return from suspend in gnome, I seem to be magically in "airplane mode" which turns off both bluetooth and wifi.

Comment 9 seeker_moc 2016-05-23 22:14:27 UTC
I'm also not sure if it's relevant, but I'm using Cinnamon instead of Gnome and "airplane mode" doesn't work for me in the first place. All the other media hotkey combinations do, but not that one (though I can still disable wifi through the network manager applet). Also, my wifi still works just fine after returning from suspend, it's just the bluetooth that stops (even though they're both the same card).

Comment 10 leigh scott 2016-05-24 06:10:56 UTC
(In reply to seeker_moc from comment #9)
> it's just the bluetooth that stops (even
> though they're both the same card).

They maybe on the same card but they are separate devices, the wifi is connected by PCIE slot and the bluetooth part is connected by USB.


$ lspci |grep -i intel
02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)


$ lsusb |grep -i intel
Bus 005 Device 002: ID 8087:07dc Intel Corp.

FTR my bluetooth prevents suspend when active and has done so since buying it (F22).

Comment 11 seeker_moc 2016-05-24 17:51:19 UTC
Not sure if it means anything, but I show:


$ lspci |grep -i intel
04:00.0 Network controller: Intel Corporation Wireless 7265 (rev 48)

$ lsusb |grep -i intel
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 003 Device 003: ID 8087:0a2a Intel Corp. 

I'm not sure which USB device is the Bluetooth, but I can confirm that I have 3 Intel devices both before standby when BT is working, and after resume, when BT no longer works, so it's not like the device disappears altogether.

Also, I think I mentioned this before, but this didn't happen on F23, only after I upgraded to F24 Beta.

Comment 12 leigh scott 2016-05-24 18:43:06 UTC
Try this, run

hciconfig

and use the correct device id (hci0 ?) to run


sudo hciconfig hci0 up


also post the outputs here

Comment 13 seeker_moc 2016-05-25 03:54:48 UTC
That fixed the problem. Thanks for your help. If it helps any, prior to standby hciconfig shows:

hci0:	Type: BR/EDR  Bus: USB
	BD Address: 60:57:18:2B:21:DA  ACL MTU: 1021:5  SCO MTU: 96:6
	UP RUNNING 
	RX bytes:31526 acl:1830 sco:0 events:234 errors:0
	TX bytes:2576 acl:37 sco:0 commands:148 errors:0

After standby:

hci0:	Type: BR/EDR  Bus: USB
	BD Address: 60:57:18:2B:21:DA  ACL MTU: 1021:5  SCO MTU: 96:6
	DOWN 
	RX bytes:1457 acl:0 sco:0 events:175 errors:0
	TX bytes:30825 acl:0 sco:0 commands:174 errors:0

Running "sudo hciconfig hci0 up" returns it to the "UP RUNNING" state and restores BT functionality.

Comment 14 Raphael Groner 2016-05-25 14:47:54 UTC
Thanks! hciconfig hci0 up fixed it for me, too.

Comment 15 leigh scott 2016-05-26 16:59:58 UTC
Can you test this build please?

http://koji.fedoraproject.org/koji/taskinfo?taskID=14263121

Comment 16 seeker_moc 2016-05-26 17:10:59 UTC
That blueman build does not fix this problem, however, it does fix bug 1338081.

Comment 17 Dimitris 2016-05-30 21:15:16 UTC
Possibly related to bug 1336297 on F23.  Note: that one can be reproduced without suspend/resume, and affects all BT functionality I can test here (mouse and PAN with Android phone).

Comment 18 seeker_moc 2016-06-05 01:10:21 UTC
Problem still present after updating to Bluez 5.40. Hciconfig workaround is still valid.

Comment 19 Dimitris 2016-07-24 01:27:03 UTC
Fixed here with bug 1336297 (kernel update).

Comment 20 seeker_moc 2016-07-24 01:36:44 UTC
Can confirm, fixed with kernel 4.6.3


Note You need to log in before you can comment on or make changes to this bug.