Bug 218142
| Summary: | Bluetooth adapter fails to recognize on kernel 5.15.0-88-generic | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Zach (zacheryvig) |
| Component: | Bluetooth | Assignee: | linux-bluetooth (linux-bluetooth) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bugs-a21, oleksandr, pmenzel+bugzilla.kernel.org, zacheryvig |
| Priority: | P3 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 5.15.0-88-generic | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Output of "lspci -nn" on the Asrock x470 Taichi motherboard.
Output of "lspci -tvnn" on the Asrock x470 Taichi motherboard. |
||
|
Description
Zach
2023-11-13 19:11:45 UTC
Does it work in 6.6.1/5.5.11? Could you post dmesg for both working and not working kernels? Given Artem mentioned 6.6.1 in comment 1, this bug might apply to me as well. I have a regression going from mainline kernel 6.1.62 to 6.1.63, and also from kernel 6.6.1 to 6.6.2; I can bisect if patch authors can't locate the relevant commit. In the most recent kernels mentioned, bluetooth won't function. Hardware: ASRock "X470 Taichi" motherboard - on board chipset. lsusb: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth. dmesg: Bluetooth: hci0: Legacy ROM 2.x revision 5.0 build 25 week 20 2015 Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq Bluetooth: hci0: Intel BT fw patch 0x43 completed & activated bluez: Version 5.70, bluez firmware version 1.2 Linux kernel firmware: 20231117_7124ce3 On a working kernel (such as 6.6.1), in addition to the dmesg output above, we have this: dmesg: Bluetooth: MGMT ver 1.22 Bluetooth: hci0: Bad flag given (0x1) vs supported (0x0) On a failed kernel (such as 6.6.2), instead of the good output above, we have: dmesg: Bluetooth: hci0: Opcode 0x0c03 failed: -110 Bluetooth: hci0: Opcode 0x0c03 failed: -110 ... repeats several times as bluez attempts to communicate with hci0. I'm still not sure whether the bug I reported in comment 2, above, is the same issue as reported by Zach (the OP). But in my specific case, the culprit has been identified (via an 8-step kernel bisection) to the following: ----------------------------------------------- commit 14a51fa544225deb9ac2f1f9f3c10dedb29f5d2f Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Date: Thu Oct 19 13:29:19 2023 +0300 xhci: Loosen RPM as default policy to cover for AMD xHC 1.1 [ Upstream commit 4baf1218150985ee3ab0a27220456a1f027ea0ac ] The AMD USB host controller (1022:43f7) isn't going into PCI D3 by default without anything connected. This is because the policy that was introduced by commit a611bf473d1f ("xhci-pci: Set runtime PM as default policy on all xHC 1.2 or later devices") only covered 1.2 or later. ----------------------------------------------- Interestingly, this bug is not about bluetooth per se, but rather the USB hardware (XHCI) that handles communication with the bluetooth chipset. It would be most helpful if the OP, Zach, could chime in here about the details of his particular setup, so we can identify whether it might be this bug or some other. Thank you for bisecting the issue so quickly and reporting it to the list [1]. Could you please attach the output of `dmesg` and `lspci -nn` and `lspci -tvnn`? [1]: https://lore.kernel.org/all/ee109942-ef8e-45b9-8cb9-a98a787fe094@moonlit-rail.com/ Created attachment 305529 [details] Output of "lspci -nn" on the Asrock x470 Taichi motherboard. Happy to bisect - it was only 8 steps to get to the problem commit. :-) I'm adding the output of "lspci -nn" and "lspci -tvnn" requested by Paul in comment 4. Created attachment 305530 [details]
Output of "lspci -tvnn" on the Asrock x470 Taichi motherboard.
Does passing `btusb.enable_autosuspend=N` via a kernel cmdline help? [1] [1] https://lore.kernel.org/lkml/5993222.lOV4Wx5bFT@natalenko.name/ |