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?
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.
Created attachment 254031 [details] hciconfig
Created attachment 254041 [details] lshw
Created attachment 254051 [details] lsmod
Created attachment 254061 [details] lspci
Created attachment 254071 [details] lsusb
Created attachment 254081 [details] udevadm-info
Created attachment 254091 [details] bluetoothctl-after-resume-from-suspend
Created attachment 254101 [details] system-log-when-usb-is-reset
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).
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
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.
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.
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.
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.
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
> 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.
Created attachment 257437 [details] btusb.c kernel-4.11 patch
this patch works for me. can you guys please test it out and let me know if it works for you?
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:
sorry, take that back. looking in the system logs I see ath10k_pci firmware crashes are happening all the time, going back months.
patch has been applied to bluetooth-next tree https://www.spinics.net/lists/linux-bluetooth/msg71040.html