Bug 172271
| Summary: | WARNING: CPU: 1 PID: 274 at drivers/base/firmware_class.c:1124 _request_firmware+0x465/0xaf0 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | wolf |
| Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
| Status: | NEW --- | ||
| Severity: | low | CC: | chris+kern, kai.heng.feng, szg00000, wolf |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.7.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
dmesg with firmware-loader debugging of two suspend/resume cycle |
||
|
Description
wolf
2016-09-19 21:36:08 UTC
Hi, I was stuck with my netbook not resuming from suspend over the night. However, just after using a bluetooth once, and suspending for 5 seconds, I'll get the same mess. Fresh boot up, suspend and resume works but: [ 97.397129] PM: resume of devices complete after 1018.677 msecs [ 97.397248] usb 1-5:1.0: rebind failed: -517 [ 97.397272] usb 1-5:1.1: rebind failed: -517 [ 97.427357] Bluetooth: hci0: read Intel version: 370810011003110e00 [ 97.427373] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1. [ 97.470484] PM: Finishing wakeup. Connect a bluetooth device, suspend and resume Bluetooth: hci0 failed to open Intel firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq(-11) Punchline: bluetooth still working after some seconds of suspend, but it locks up in the morning, suspended over the night. Created attachment 258177 [details]
dmesg
* fresh boot,
* suspend, resume,
* use bt device
* suspend resume again
Please give these two patch series a try: https://lkml.org/lkml/2017/8/22/123 https://lkml.org/lkml/2017/8/25/58 (In reply to Kai-Heng Feng from comment #3) > Please give these two patch series a try: > > https://lkml.org/lkml/2017/8/22/123 > https://lkml.org/lkml/2017/8/25/58 Hi, thanks for the work. I applied these patches on 4.9.50. The machine locks up on the way to suspend :( Actually I was hardly able to reproduce this issue as easy as before, even with the 4.9.46. It should be noted there was an update of the bluez package meanwhile ("BlueBorne" flaw). As long the firmware loading happens after "Restarting tasks ... done" we're fine but still there is a chance to brick the machine on resume (1 of 20 tries). (In reply to chr() from comment #4) > (In reply to Kai-Heng Feng from comment #3) > > Please give these two patch series a try: > > > > https://lkml.org/lkml/2017/8/22/123 > > https://lkml.org/lkml/2017/8/25/58 > > Hi, > > thanks for the work. > > I applied these patches on 4.9.50. The machine locks up on the way to > suspend :( The patches should apply to mainline. I didn't test it on 4.9. > > Actually I was hardly able to reproduce this issue as easy as before, even > with the 4.9.46. > It should be noted there was an update of the bluez package meanwhile > ("BlueBorne" flaw). This is a kernel bug, it shouldn't have anything to do with BlueZ. > > As long the firmware loading happens after "Restarting tasks ... done" we're > fine but still there is a chance to brick the machine on resume (1 of 20 > tries). Probably try it on top of mainline? Created attachment 260775 [details] dmesg with firmware-loader debugging of two suspend/resume cycle Hi! I was reading this: btusb "firmware request while host is not available" at resume https://lkml.org/lkml/2017/9/11/370 and I turned on the debugging of the firmware loader to check the caching. The firmware cache works once but on second suspend it fails. On the first resume there's an usb reset(!) and a call to fw_name_devm_release. So on the second suspend the bt-firmware isn't loaded to the cache, resume Oops. It should be solved in v4.14. |