Description of problem: ----------------------------------------------------------------------------------------------------- Update: After testing with 5.xx kernels I have confirmed this bug was introduced with 6.xx kernels and above. ----------------------------------------------------------------------------------------------------- After upgrading to Fedora 37 on a Lenovo X13 Gen2 AMD laptop, Bluetooth no longer works and dmesg is reporting an error due to an invalid opcode. When Bluetooth is enabled via the gome-settings app, journalctl/dmesg shows: [ 350.405092] Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00130200.bin [ 350.405095] Bluetooth: hci0: QCA: patch rome 0x130200 build 0x4610, firmware rome 0x130200 build 0x17f3 [ 351.097743] Bluetooth: hci0: using NVM file: qca/nvm_usb_00130200.bin [ 351.131242] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 351.553918] Bluetooth: hci0: unexpected cc 0x2060 length: 1 < 7 [ 351.553981] Bluetooth: hci0: Opcode 0x2060 failed: -38 [ 353.612904] Bluetooth: hci0: command tx timeout #inxi -Eazy Bluetooth: Device-1: Foxconn / Hon Hai type: USB driver: btusb v: 0.8 bus-ID: 5-4:5 chip-ID: 0489:e0d0 class-ID: e001 Report: hciconfig ID: hci0 rfk-id: 5 state: down bt-service: enabled,running rfk-block: hardware: no software: no address: <filter> Info: acl-mtu: 1024:7 sco-mtu: 120:5 link-mode: peripheral accept #rfkill list 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: no Hard blocked: no 1: hci0: Bluetooth Soft blocked: no Hard blocked: no 2: phy0: Wireless LAN Soft blocked: no Hard blocked: no Also, `systemctl status bluetooth` seems to think the service is working fine when it isn't. Version-Release number of selected component (if applicable): Fedora 37 linux-firmware-20221109-144 How reproducible: Every time, all the time. Steps to Reproduce: 1. Upgrade from Fedora 36 to 37 using the gnome-software update manager 2. Attempt to enable Bluetooth in the gnome-settings app 3. Actual results: Journalctl/dmesg shows the error information above Expected results: Bluetooth should enable without an error Additional info:
Please report: lsusb details of the bluetooth adapter running kernel version of bluez versions of kernel/linux-firmware/bluez from F-36 where it was working.
lsusb output: Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 008: ID 0489:e0d0 Foxconn / Hon Hai Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 04f2:b71c Chicony Electronics Co., Ltd Integrated RGB Camera Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Running Kernel - 6.0.9-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:36:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux bluez version - bluez-5.65-3.fc37 Since I've upgraded to F37 already I booted with an F36 live usb and bluetooth works out of the box on that, and had continued to do so until I upgraded to F37. My F36 was using 5.xx versions of the kernel if I recall correctly.
Adapter is a Qualcomm® QCNFA765
> Since I've upgraded to F37 already I booted with an F36 live usb and > bluetooth works out of the box on that, and had continued to do so until I > upgraded to F37. My F36 was using 5.xx versions of the kernel if I recall > correctly. A lot changed since the F36 GA live image and what ever updates you have when you upgraded to f37 so that's not really useful. I will need exact versions. dnf history should be able to give you more details.
> [ 350.405092] Bluetooth: hci0: using rampatch file: > qca/rampatch_usb_00130200.bin > [ 350.405095] Bluetooth: hci0: QCA: patch rome 0x130200 build 0x4610, > firmware rome 0x130200 build 0x17f3 > [ 351.097743] Bluetooth: hci0: using NVM file: qca/nvm_usb_00130200.bin The last time either of those firmware were updated was in 4th Jan 2022 so they've not changed since before Fedora 36 went GA so I doubt this is actually a firmware issue.
(In reply to Peter Robinson from comment #4) > > Since I've upgraded to F37 already I booted with an F36 live usb and > > bluetooth works out of the box on that, and had continued to do so until I > > upgraded to F37. My F36 was using 5.xx versions of the kernel if I recall > > correctly. > > A lot changed since the F36 GA live image and what ever updates you have > when you upgraded to f37 so that's not really useful. I will need exact > versions. dnf history should be able to give you more details. Exact version prior to the upgrade were: - linux-firmware-20221012-141.fc36 - bluez-5.65-1.fc36 - kernel-6.0.8-200.fc36
Actually it was kernel-5.19.8-200.fc36 prior
(In reply to Peter Robinson from comment #5) > > [ 350.405092] Bluetooth: hci0: using rampatch file: > > qca/rampatch_usb_00130200.bin > > [ 350.405095] Bluetooth: hci0: QCA: patch rome 0x130200 build 0x4610, > > firmware rome 0x130200 build 0x17f3 > > [ 351.097743] Bluetooth: hci0: using NVM file: qca/nvm_usb_00130200.bin > > The last time either of those firmware were updated was in 4th Jan 2022 so > they've not changed since before Fedora 36 went GA so I doubt this is > actually a firmware issue. So maybe a kernel or bluetooth specific issue?
> > The last time either of those firmware were updated was in 4th Jan 2022 so > > they've not changed since before Fedora 36 went GA so I doubt this is > > actually a firmware issue. > > So maybe a kernel or bluetooth specific issue? Probably, unfortunately that's not something I can triage, and that's explicitly why we need to know when it broke, linux-firmware, kernel and bluez are basically the same between an up to date F-36 and F-37 so I suspect it's probably broken on an up to date F-36 too but I can't triage it because I don't have the HW/config and hence why the difference in revs before and after upgrade matter. > Exact version prior to the upgrade were: > - linux-firmware-20221012-141.fc36 > - bluez-5.65-1.fc36 > - kernel-6.0.8-200.fc36 Do you still have the 5.19.8 kernel installed, you could try rebooting into that if so, else you could downgrade any of those and see which breaks it.
I have confirmed it's not bluez, but it is definitely kernel 6.0 and up. booting into kernels 5.17.5, 5.18.19 and 5.19.17 bluetooth works fine, as soon as I move to any version of kernel 6 starting at 6.0 the problem exists with the error/message I originally posted. How do we move this one forward, should I open a kernel bug on https://bugzilla.kernel.org/ ?
> How do we move this one forward, should I open a kernel bug on I've just reassigned it, that way the history isn't lost. Probably worth also testing the 6.1-rc8 kernel to see if that fixes it.
Mark are you aware of any issues with the "Lenovo X13 Gen2 AMD laptop" bluetooth on kernel 6.0?
OK, so I managed to track down the bug and at least make it work again in kernel 6 versions. hci_sync.c had a commit done on Sept 6th which introduced this bug - https://github.com/bluez/bluetooth-next/commit/c1631dbc00c1e432713396aaa10d8bd825822db0 removing the if block for the 'hdev->commands' section in "hci_le_read_buffer_size_sync(struct hci_dev *hdev)" and reverting it back to what it was in kernel 5.19.x and previous makes a working kernel where the bt adapter works again. It appears that the adapter in the Lenovo X13 AMD laptops doesn't support opcode 0x2060 or HCI_OP_LE_READ_BUFFER_SIZE_V2. The __hci_cmd_sync_status_sk function can also return a non-zero code as PTR_ERR(skb) which seems to be what is tripping this up. I tested this update by removing the IF block in hci_le_read_buffer_size_sync in 6.0.12 then built and booted the kernel and voila, we have bluetooth again.
(In reply to kiro15r from comment #13) > OK, so I managed to track down the bug and at least make it work again in > kernel 6 versions. > > hci_sync.c had a commit done on Sept 6th which introduced this bug - > https://github.com/bluez/bluetooth-next/commit/ > c1631dbc00c1e432713396aaa10d8bd825822db0 > > removing the if block for the 'hdev->commands' section in > "hci_le_read_buffer_size_sync(struct hci_dev *hdev)" and reverting it back > to what it was in kernel 5.19.x and previous makes a working kernel where > the bt adapter works again. > > It appears that the adapter in the Lenovo X13 AMD laptops doesn't support > opcode 0x2060 or HCI_OP_LE_READ_BUFFER_SIZE_V2. > > The __hci_cmd_sync_status_sk function can also return a non-zero code as > PTR_ERR(skb) which seems to be what is tripping this up. > > I tested this update by removing the IF block in > hci_le_read_buffer_size_sync in 6.0.12 then built and booted the kernel and > voila, we have bluetooth again. Thank you for figuring this out. Can you please send an email describing this problem to the author of: https://github.com/bluez/bluetooth-next/commit/c1631dbc00c1e432713396aaa10d8bd825822db0 So that is to: "Luiz Augusto von Dentz <luiz.von.dentz>" and please also put linux-bluetooth.org in the Cc.
(In reply to Hans de Goede from comment #14) > (In reply to kiro15r from comment #13) > > OK, so I managed to track down the bug and at least make it work again in > > kernel 6 versions. > > > > hci_sync.c had a commit done on Sept 6th which introduced this bug - > > https://github.com/bluez/bluetooth-next/commit/ > > c1631dbc00c1e432713396aaa10d8bd825822db0 > > > > removing the if block for the 'hdev->commands' section in > > "hci_le_read_buffer_size_sync(struct hci_dev *hdev)" and reverting it back > > to what it was in kernel 5.19.x and previous makes a working kernel where > > the bt adapter works again. > > > > It appears that the adapter in the Lenovo X13 AMD laptops doesn't support > > opcode 0x2060 or HCI_OP_LE_READ_BUFFER_SIZE_V2. > > > > The __hci_cmd_sync_status_sk function can also return a non-zero code as > > PTR_ERR(skb) which seems to be what is tripping this up. > > > > I tested this update by removing the IF block in > > hci_le_read_buffer_size_sync in 6.0.12 then built and booted the kernel and > > voila, we have bluetooth again. > > Thank you for figuring this out. Can you please send an email describing > this problem to the author of: > https://github.com/bluez/bluetooth-next/commit/ > c1631dbc00c1e432713396aaa10d8bd825822db0 > > So that is to: "Luiz Augusto von Dentz <luiz.von.dentz>" and > please also put linux-bluetooth.org in the Cc. Thanks, done.
I also own a QCA bluetooth chipset, and can confirm it's also busted. I, however, bisected the issue to commit slightly earlier than what was referenced (similar area, but the commit where the CIS feature was implemented): https://github.com/bluez/bluetooth-next/commit/26afbd826ee326e63a334c37fd45e82e50a615ec In this commit, some HCI initialization logic is moved around: --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -3051,6 +3057,10 @@ static int hci_init2_sync(struct hci_dev *hdev) if (hdev->dev_type == HCI_AMP) return hci_init_stage_sync(hdev, amp_init2); + err = hci_init_stage_sync(hdev, hci_init2); + if (err) + return err; + if (lmp_bredr_capable(hdev)) { err = hci_init_stage_sync(hdev, br_init2); if (err) @@ -3068,7 +3078,7 @@ static int hci_init2_sync(struct hci_dev *hdev) hci_dev_set_flag(hdev, HCI_LE_ENABLED); } - return hci_init_stage_sync(hdev, hci_init2); + return 0; } This is what I perceive to cause the breakage. Simply reverting this part of the change so that hci_init_stage_sync is called at the end of hci_init2_sync again restores functionality. It's unclear to me at this time why hci_init_stage_sync was hoisted up like this...
Looks like it's been fixed here: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=711d2d5f3b42c3e9658371089d400758cc54f307
I never saw this one as it was tagged to my redhat address that I don't really use - so apologies for the lack of reply (in future please tag mpearson) I believe this is fixed - if it's not, let me know and I'll investigate but otherwise clearing my needinfo.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.