Bug 213829 - Intel AX210 Bluetooth controller doesn't start from warm boot
Summary: Intel AX210 Bluetooth controller doesn't start from warm boot
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-23 11:09 UTC by Tobias Predel
Modified: 2021-10-21 02:40 UTC (History)
24 users (show)

See Also:
Kernel Version: 5.14.0-rc2
Tree: Mainline
Regression: No


Attachments
dmesg log after warm and cold boot (165.71 KB, text/plain)
2021-07-23 11:09 UTC, Tobias Predel
Details

Description Tobias Predel 2021-07-23 11:09:09 UTC
Created attachment 298013 [details]
dmesg log after warm and cold boot

Hello,

The AX 210 Bluetooth controller does not get initialized after a warm boot.
It gets initialized after a cold boot had been performed (going to the BIOS menu, doing nothing and leaving it, afterwards starting Linux).

In both cases the bluetooth USB 

See dmesg logs attached.

Regards,
Tobias Predel
Comment 1 Tobias Predel 2021-07-23 11:10:55 UTC
In both cases the bluetooth USB device is recognized on the bus.
Comment 2 kazetsukai 2021-08-12 18:19:08 UTC
Saw this behavior on 5.13.8 (.arch1-1) Rolling back to 5.12.15, the issue is not present.
Comment 3 Matt Bernhard 2021-08-14 04:23:33 UTC
I'm also seeing this issue in 5.13-10 (-arch-1). Cold booting consistently fixes it, and rolling back to 5.12.15 fixes the warm booting problem.
Comment 4 Ron M 2021-09-10 04:41:42 UTC
I have verified this issue is still present in 5.14.0 (and not present in 5.12.19)
Comment 5 Rohit 2021-09-12 23:24:25 UTC
I've experienced this issue as well since the 5.13.6 update which persists in 5.14.2. Cold booting each time allows Bluetooth to function, although the device is recognized (but not functional) with regular warm boots.
Comment 6 Guillaume Binet 2021-10-05 14:08:57 UTC
On 5.14.9 the bluetooth adapter still doesn't work. 5.12.15 from 07 Jul 2021 is the last kernel working before the regression.

I could reproduce this regression consistently on 2 machines for a quarter now...  do we know if we have anyone looking into it?
Comment 7 Marco 2021-10-11 15:04:36 UTC
Just swapped a not great wifi card with a brand new AX210 and yes, same problem on my system, dmesg log identical to the one above, if the firmware is already loaded on the card.

Can anyone from Intel take a look at this problem? Thanks.
Comment 8 slav0nic 2021-10-16 08:21:21 UTC
looks like it start working correct with latest firmware (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-0041-0041.sfi) on linux 5.14.12
Comment 9 nE0sIghT 2021-10-16 10:58:34 UTC
I can confirm that this is no longer issue in 5.14.12.
linux-firmware 20210818
Comment 10 Matt Bernhard 2021-10-17 02:47:31 UTC
Running on 5.15.0-rc5-1 and linux-firmware 20210919.d526e04-1 I'm still having this issue.
Comment 11 nE0sIghT 2021-10-17 10:46:25 UTC
(In reply to nE0sIghT from comment #9)
> I can confirm that this is no longer issue in 5.14.12.
> linux-firmware 20210818

I made more tests and bluetooth issue looks like compiler-dependend.

I checked 5.14.12 and 5.14.11 compiled with gcc 11.2.0 and doesn’t have warm boot issues.
Same kernels compiled with gcc 10.3.0 have warm boot issue.

I’m on Gentoo Linux.
Comment 12 Guillaume Binet 2021-10-17 14:00:08 UTC
(In reply to nE0sIghT from comment #11)
> I checked 5.14.12 and 5.14.11 compiled with gcc 11.2.0 and doesn’t have warm
> boot issues.
> Same kernels compiled with gcc 10.3.0 have warm boot issue.

pal ➜  ~  cat /proc/version
Linux version 5.14.12-arch1-1 (linux@archlinux) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Wed, 13 Oct 2021 16:58:16 +0000

5.14.12 with gcc 11.1.0 has the problem on my side.
Comment 13 Guillaume Binet 2021-10-17 18:05:04 UTC
I continued to investigate. The major difference between a cold boot and a warm boot is the driver trying to load a firmware.

For the science, I just disabled this behavior and it looks like the device and driver recover on a warm boot. Consider this a workaround and not a fix but at least it works for me, bluetooth is available on a warm boot.

```
pal ➜  linux-5.14.12  diff -u drivers/bluetooth/btintel.c.old drivers/bluetooth/btintel.c 
--- drivers/bluetooth/btintel.c.old     2021-10-17 13:56:23.583338189 -0400
+++ drivers/bluetooth/btintel.c 2021-10-17 14:01:16.113344330 -0400
@@ -1034,17 +1034,6 @@
                /* Skip reading firmware file version in bootloader mode */
                if (ver->fw_variant == 0x06)
                        break;
-
-               /* Skip download if firmware has the same version */
-               if (btintel_firmware_version(hdev, ver->fw_build_num,
-                                            ver->fw_build_ww, ver->fw_build_yy,
-                                            fw, boot_param)) {
-                       bt_dev_info(hdev, "Firmware already loaded");
-                       /* Return -EALREADY to indicate that the firmware has
-                        * already been loaded.
-                        */
-                       return -EALREADY;
-               }
        }
 
        /* The firmware variant determines if the device is in bootloader
@@ -1074,21 +1063,6 @@
        int err;
        u32 css_header_ver;
 
-       /* Skip reading firmware file version in bootloader mode */
-       if (ver->img_type != 0x01) {
-               /* Skip download if firmware has the same version */
-               if (btintel_firmware_version(hdev, ver->min_fw_build_nn,
-                                            ver->min_fw_build_cw,
-                                            ver->min_fw_build_yy,
-                                            fw, boot_param)) {
-                       bt_dev_info(hdev, "Firmware already loaded");
-                       /* Return -EALREADY to indicate that firmware has
-                        * already been loaded.
-                        */
-                       return -EALREADY;
-               }
-       }
-
        /* The firmware variant determines if the device is in bootloader
         * mode or is running operational firmware. The value 0x01 identifies
         * the bootloader and the value 0x03 identifies the operational
```
Comment 14 Marco 2021-10-18 12:25:10 UTC
Just tested with the latest firmware, reboot, firmware already loaded message and no response again from the bluetooth subsystem, even if it's present in the usb tree no bluetooth adapter detected from my DE.

According to the point that began to have the issue, I suspected already that the issue in the code stems from the not reupload of the firmware to the adapter, good that removing the firmware check fix the issue, but this is not the proper way to go. Intel should properly check why it doesn't work for some (I assume).

Marco.
Comment 15 Marco 2021-10-18 12:43:27 UTC
(In reply to Guillaume Binet from comment #13)
> ...

Whoops, missed the mention of a temporary hack, sorry. Anyway, I hope that someone will take a look at this, sooner or later.

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