Bug 193571 - Atheros bluetooth controller not working after suspend/resume. Have to powercycle usb ports
Summary: Atheros bluetooth controller not working after suspend/resume. Have to powerc...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-29 17:24 UTC by Leif Liddy
Modified: 2017-07-08 23:22 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.9.5-200.fc25.x86_64
Subsystem:
Regression: No
Bisected commit-id:


Attachments
hciconfig (580 bytes, text/plain)
2017-02-04 13:29 UTC, Leif Liddy
Details
lshw (15.01 KB, text/plain)
2017-02-04 13:29 UTC, Leif Liddy
Details
lsmod (5.78 KB, text/plain)
2017-02-04 13:29 UTC, Leif Liddy
Details
lspci (2.24 KB, text/plain)
2017-02-04 13:30 UTC, Leif Liddy
Details
lsusb (9.19 KB, text/plain)
2017-02-04 13:30 UTC, Leif Liddy
Details
udevadm-info (145.45 KB, text/plain)
2017-02-04 13:31 UTC, Leif Liddy
Details
bluetoothctl-after-resume-from-suspend (2.24 KB, text/plain)
2017-02-04 13:32 UTC, Leif Liddy
Details
system-log-when-usb-is-reset (4.13 KB, text/plain)
2017-02-04 13:33 UTC, Leif Liddy
Details
Hack to not load firmware for qca bt. (1.37 KB, patch)
2017-07-06 04:55 UTC, Pengyu Ma
Details | Diff
btusb.c kernel-4.11 patch (657 bytes, patch)
2017-07-08 13:27 UTC, Leif Liddy
Details | Diff

Description Leif Liddy 2017-01-29 17:24:00 UTC
The Samsung ATIV Book 9 12.2 (2015) notebook has an Atheros bluetooth controller connected to usb bus. 

#lsusb
Bus 001 Device 002: ID 0cf3:e300 Atheros Communications, Inc. 

After/suspend and resume, bluetooth no longer works, and I receive tons of timeout errors on the systems logs

....
Jan 29 13:18:41 ativ.example.com kernel: Bluetooth: hci0 command 0x200c tx timeout
Jan 29 13:18:43 ativ.example.com kernel: Bluetooth: hci0 command 0x2005 tx timeout

What's odd, is that the device number (from lsusb output) changes after each suspend/resume cycle:

#lsusb  (after 1st suspend/resume cycle)
Bus 001 Device 005: ID 0cf3:e300 Atheros Communications, Inc.

However, the device it points to in sysfs remains the same:
/sys/bus/usb/devices/1-4

**I found I can prevent the device number from changing by using this modprobe config

options btusb reset=1

**However, this did not solve the suspend/resume issue. 

I did manage to find a solution to get the bluetooth controller working after a suspend/resume cycle, and that is to power cycle the usb ports with:

echo 0 > /sys/bus/usb/devices/1-4/authorized 
echo 1 > /sys/bus/usb/devices/1-4/authorized

My bluetooth mouse starts working immediately after issuing these two commands. 

I know I could write a script in  
/usr/lib/systemd/system-sleep

to cycle the ports after upon resuming from suspend. 
But my question is --is there a kernel-level fix for this issue?
Comment 1 Greg Kroah-Hartman 2017-01-30 06:44:38 UTC
On Sun, Jan 29, 2017 at 05:24:00PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=193571
> 
>             Bug ID: 193571
>            Summary: Atheros bluetooth controller not working after
>                     suspend/resume. Have to powercycle usb ports
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 4.9.5-200.fc25.x86_64

All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.
Comment 2 Leif Liddy 2017-02-04 13:29:05 UTC
Created attachment 254031 [details]
hciconfig
Comment 3 Leif Liddy 2017-02-04 13:29:34 UTC
Created attachment 254041 [details]
lshw
Comment 4 Leif Liddy 2017-02-04 13:29:51 UTC
Created attachment 254051 [details]
lsmod
Comment 5 Leif Liddy 2017-02-04 13:30:05 UTC
Created attachment 254061 [details]
lspci
Comment 6 Leif Liddy 2017-02-04 13:30:21 UTC
Created attachment 254071 [details]
lsusb
Comment 7 Leif Liddy 2017-02-04 13:31:00 UTC
Created attachment 254081 [details]
udevadm-info
Comment 8 Leif Liddy 2017-02-04 13:32:11 UTC
Created attachment 254091 [details]
bluetoothctl-after-resume-from-suspend
Comment 9 Leif Liddy 2017-02-04 13:33:19 UTC
Created attachment 254101 [details]
system-log-when-usb-is-reset
Comment 10 Sven Köhler 2017-02-23 00:24:29 UTC
I have the same issue with a Killer 1535 card in a Dell XPS 15 9560. Bluetooth works for the most part, but then it simply stops working at some point (often after resume from suspend to RAM).

lsusb of the device is almost identical to the one Leif Liddy posted (it has the same vendor/product id, even though mine has bcdUSB=2.01, not 1.10).

Also, the solution posted by Leif to reactivate the bluetooth card work for me.
A hciconfig hci0 down following by a hciconfig hci0 up doesn't work. The attempt to bring up the interface again fails with a timeout (error 110).
Comment 11 Leif Liddy 2017-02-25 03:15:40 UTC
Here's an easy method to reset the bluetooth adapter without having to know the usb address for it. **just need the vendor and product id.


#!/usr/bin/python

from usb.core import find as finddev
dev = finddev(idVendor=0x0cf3, idProduct=0xe300)
dev.reset()


**requires pyusb to run
Comment 12 Mario Ray Mahardhika 2017-04-28 19:03:33 UTC
Same issue with ASUS X455LB (Qualcomm Atheros QCA9565 / AR9565). I believe this is since 4.10.10, because previously, at the worst all I need to do (when the bluetooth doesn't come back after resuming) is:

rfkill block bluetooth
<wait a few seconds>
rfkill unblock bluetooth

With 4.10.10 and newer, only the power cycle workaround works. Thank God I see this report.
Comment 13 Pengyu Ma 2017-07-06 04:52:19 UTC
This error occurred on ThinkPad E470 after resume from S3. The error happened about 1/5 after resume.

dmesg log:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5472 at /build/linux-5vkMGy/linux-4.4.0/drivers/base/firmware_class.c:1147 _request_firmware+0x7cf/0xb00()
PM: Finishing wakeup.
Restarting tasks ...
Modules linked in: cmac msr rfcomm bbswitch(OE) bnep toshiba_acpi sparse_keymap toshiba_haps hp_accel lis3lv02d input_polldev arc4 nls_iso8859_1 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media x86_pkg_temp_thermal coretemp kvm btusb btrtl btbcm snd_hda_codec_hdmi(OE) btintel snd_hda_codec_conexant(OE) snd_hda_codec_generic(OE) irqbypass bluetooth ath10k_pci ath10k_core crct10dif_pclmul crc32_pclmul ath mac80211 aesni_intel snd_hda_intel(OE) snd_hda_codec(OE) aes_x86_64 snd_hda_core(OE) lrw cfg80211 snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event gf128mul snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer cryptd snd joydev input_leds serio_raw soundcore mei_me mei shpchp wmi tpm_crb mac_hid parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq dm_mirror dm_region_hash dm_log psmouse i915_bpo intel_ips i2c_algo_bit drm_kms_helper syscopyarea r8169 sysfillrect sysimgblt sdhci_pci mii fb_sys_fops sdhci drm ahci libahci video fjes [last unloaded: efi_runtime]
CPU: 1 PID: 5472 Comm: kworker/u17:0 Tainted: P OE 4.4.0-34-generic #53-Ubuntu
Hardware name: LENOVO 20H1Z2NGUS/20H1Z2NGUS, BIOS R0DET26W (1.02 ) 07/19/2016
Workqueue: hci0 hci_power_on [bluetooth]
 0000000000000286 00000000e397c6f6 ffff88026fe17bb0 ffffffff813f11b3
 0000000000000000 ffffffff81d37118 ffff88026fe17be8 ffffffff81081102
 ffff88026fe17ce0 00000000fffffff5 ffff88025449a840 ffff88027072b0c0
Call Trace:
 [<ffffffff813f11b3>] dump_stack+0x63/0x90
 [<ffffffff81081102>] warn_slowpath_common+0x82/0xc0
 [<ffffffff8108124a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff81567ecf>] _request_firmware+0x7cf/0xb00
 [<ffffffff81568231>] request_firmware+0x31/0x50
 [<ffffffffc0771725>] btusb_setup_qca+0x185/0x3a0 [btusb]
 [<ffffffff810b3595>] ? select_idle_sibling+0x105/0x120
 [<ffffffff810b8bd4>] ? enqueue_task_fair+0xa4/0x8b0
 [<ffffffff810aa376>] ? _sched_setscheduler+0x76/0x90
 [<ffffffffc0770958>] btusb_open+0x38/0x250 [btusb]
 [<ffffffffc06eecc2>] hci_dev_do_open+0x82/0x580 [bluetooth]
 [<ffffffff810ab29d>] ? ttwu_do_activate.constprop.90+0x5d/0x70
 [<ffffffffc06f0a60>] hci_power_on+0x40/0x1d0 [bluetooth]
 [<ffffffff810ec724>] ? lock_timer_base.isra.22+0x54/0x70
 [<ffffffff8109a2c5>] process_one_work+0x165/0x480
 [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
 [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
 [<ffffffff810a0808>] kthread+0xd8/0xf0
 [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
 [<ffffffff8182e28f>] ret_from_fork+0x3f/0x70
 [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
---[ end trace 6f12ff0bf776585f ]---
bluetooth hci0: firmware: qca/rampatch_usb_00000302.bin will not be loaded
Bluetooth: hci0: failed to request rampatch file: qca/rampatch_usb_00000302.bin (-11)
done.
Comment 14 Pengyu Ma 2017-07-06 04:55:42 UTC
Created attachment 257377 [details]
Hack to not load firmware for qca bt.

There is an vendor status got from usb controller, the driver will load the firmware or not that is on the basis of this status.

When first booting kernel the status didn't need to load any firmware for qca bluetooth, and bluetooth works fine.

After suspend and resume, the status is changed to request both rampatch and nvm firmware.

I hardcode it to NOT load firmware then bluetooth works fine.
Comment 15 Leif Liddy 2017-07-07 03:28:31 UTC
I'm glad someone figured this out! I thought it might be firmware related. I sent the following email to the bluetooth email list a few months ago, but never got any response back:

https://www.spinics.net/lists/linux-bluetooth/msg69757.html

I'll test your patch out this weekend, and will report back.
Comment 16 Leif Liddy 2017-07-08 04:13:37 UTC
This patch does not work for me. Apparently my bluetooth controller needs the firmware loaded at boot time. 

In my case, neither btusb_setup_qca_load_rampatch or btusb_setup_qca_load_nvm is run upon resume from suspend. 

I guess the solution for my issue would be to force a firmware reload upon resume, or to reset the device upon resume from suspend. 

This mechanism already exists for realtek devices:

#ifdef CONFIG_BT_HCIBTUSB_RTL
        if (id->driver_info & BTUSB_REALTEK) {
                hdev->setup = btrtl_setup_realtek;

                /* Realtek devices lose their updated firmware over suspend,
                 * but the USB hub doesn't notice any status change.
                 * Explicitly request a device reset on resume.
                 */
                set_bit(BTUSB_RESET_RESUME, &data->flags);
        }
#endif

Would anyone know how to create an equilivent patch for BTUSB_QCA_ROME devices?
I'm guessing it would look something like this:

#ifdef CONFIG_BT_HCIBTUSB_BCM
        if (id->driver_info & BTUSB_QCA_ROME) {
                hdev->setup = btusb_setup_qca;

                /* QCA Rome devices lose their updated firmware over suspend,
                 * but the USB hub doesn't notice any status change.
                 * Explicitly request a device reset on resume.
                 */
                set_bit(BTUSB_RESET_RESUME, &data->flags);
        }
#endif
Comment 17 Leif Liddy 2017-07-08 12:14:52 UTC
> When first booting kernel the status didn't need to load any firmware for qca
> bluetooth, and bluetooth works fine.

I also noticed on my laptop, that the firmware didn't get loaded and bluetooth worked --if I just rebooted (vs cold boot) 

However, from a cold boot, the firmware does get loaded. bluetooth doesn't work otherwise. 

Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000200.bin
Bluetooth: hci0: QCA: patch rome 0x200 build 0x299, firmware rome 0x200 build 0x111
Bluetooth: hci0: using NVM file: qca/nvm_usb_00000200.bin

try cold booting your laptop and see if your patch still works.
Comment 18 Leif Liddy 2017-07-08 13:27:59 UTC
Created attachment 257437 [details]
btusb.c kernel-4.11 patch
Comment 19 Leif Liddy 2017-07-08 13:30:03 UTC
this patch works for me. can you guys please test it out and let me know if it works for you?
Comment 20 Leif Liddy 2017-07-08 16:20:50 UTC
after testing my patch a bit more, I ran into another issue. while the bluetooth controller now comes online without issue, the wireless controller does not (there was no issue with this before). So it seems I've traded one issue for another. Oh well, back to the drawing board. If anyone has any suggestions, please let me know.

ath10k_pci 0000:01:00.0: firmware crashed! (uuid 897db8d2-7090-48ec-897d-e9bbd7a427a6)
ath10k_pci 0000:01:00.0: firmware register dump:
Comment 21 Leif Liddy 2017-07-08 16:34:49 UTC
sorry, take that back. looking in the system logs I see ath10k_pci firmware crashes are happening all the time, going back months.
Comment 22 Leif Liddy 2017-07-08 23:22:45 UTC
patch has been applied to bluetooth-next tree

https://www.spinics.net/lists/linux-bluetooth/msg71040.html

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