Bug 213829

In both cases the bluetooth USB device is recognized on the bus.

Saw this behavior on 5.13.8 (.arch1-1) Rolling back to 5.12.15, the issue is not present.

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.

I have verified this issue is still present in 5.14.0 (and not present in 5.12.19)

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.

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?

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.

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

I can confirm that this is no longer issue in 5.14.12.
linux-firmware 20210818

Running on 5.15.0-rc5-1 and linux-firmware 20210919.d526e04-1 I'm still having this issue.

(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.

(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.

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
```

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.

(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.

After updating to 5.14.15, it got even worse, now it will literally drop the connection with my mouse after 10 seconds and it will stop responding to any command until a complete shutdown, all I get in the logs is a command timeout, it will literally stop responding to my host.

[  358.869054] Bluetooth: hci0: command 0x0804 tx timeout
[  361.045200] Bluetooth: hci0: command 0x041f tx timeout
[  363.093133] Bluetooth: hci0: command 0x0406 tx timeout

[ 1436.437038] Bluetooth: hci0: command 0x0c03 tx timeout
[ 1444.437291] Bluetooth: hci0: HCI reset during shutdown failed

This even after a cold start.

Anyone with the same problem here?

(In reply to Marco from comment #16)
> After updating to 5.14.15, it got even worse, now it will literally drop the
> connection with my mouse after 10 seconds and it will stop responding to any
> command until a complete shutdown, all I get in the logs is a command
> timeout, it will literally stop responding to my host.
> 
> [  358.869054] Bluetooth: hci0: command 0x0804 tx timeout
> [  361.045200] Bluetooth: hci0: command 0x041f tx timeout
> [  363.093133] Bluetooth: hci0: command 0x0406 tx timeout
> 
> [ 1436.437038] Bluetooth: hci0: command 0x0c03 tx timeout
> [ 1444.437291] Bluetooth: hci0: HCI reset during shutdown failed
> 
> This even after a cold start.
> 
> Anyone with the same problem here?

This was fixed after a reinstall of linux-firmware, sorry, the problem after a reboot is still there, though.

Can confirm the issue still exists with 5.14.15.

This should be fixed with https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btintel.c?id=35191a0fe986bacf69bd842de81119dca7970f11

I tried it with 5.15 and didn't see the problem.

(In reply to Tedd An from comment #19)
> This should be fixed with
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> drivers/bluetooth/btintel.c?id=35191a0fe986bacf69bd842de81119dca7970f11
> 
> I tried it with 5.15 and didn't see the problem.

Sorry it is not.

Testing with the framework laptop on 
testing/linux 5.15.1.arch1-2

Steps to reproduce: 1. go to the bios and save settings, it starts bt correctly. 2. Just reboot with for example the reboot command or come out of hibernation etc... it fails as usual.

(In reply to nE0sIghT from comment #11)
> (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.

Still confirm that after upgrading gcc to 11.2.0 this issue gone for me. I'm now on 5.14.17.

5.15.2-arch1-1 still suffers from the issue. I can't even get a list of devices after a cold boot...

Could you try with the latest firmware from linux-firmware.git?
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

Copy the intel/*.sfi to /lib/firmware/intel/ and cold boot.

It will help to rule out if it is fw issue or not.

(In reply to Tedd An from comment #23)
> Could you try with the latest firmware from linux-firmware.git?
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> 
> Copy the intel/*.sfi to /lib/firmware/intel/ and cold boot.
> 
> It will help to rule out if it is fw issue or not.

I just tried. I installed the latest linux-firmware-git package that pulled latest.

On cold boot I had `bluetoothctl list` hang after boot. Then after restarting the bluetooth service, it showed the device but still refused to even do a basic scan.

`Failed to start discovery: org.bluez.Error.NotReady`

Then after doing another quick cold boot (stayed off only a few seconds), no device was listed at all. =\

(In reply to Josh Ellithorpe from comment #24)
> (In reply to Tedd An from comment #23)
> > Could you try with the latest firmware from linux-firmware.git?
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> > 
> > Copy the intel/*.sfi to /lib/firmware/intel/ and cold boot.
> > 
> > It will help to rule out if it is fw issue or not.
> 
> I just tried. I installed the latest linux-firmware-git package that pulled
> latest.
> 
> On cold boot I had `bluetoothctl list` hang after boot. Then after
> restarting the bluetooth service, it showed the device but still refused to
> even do a basic scan.
> 
> `Failed to start discovery: org.bluez.Error.NotReady`
> 
> Then after doing another quick cold boot (stayed off only a few seconds), no
> device was listed at all. =\

Same thing here, just tested with the latest 5.15 that supposedly should contains the aforementioned fix above:

With the current firmware in linux-firmware, the issue is still the same after a reboot. With the latest firmware (just downloaded ibt-0041-0041.ddc and sfi, but if the wireless portion is needed, I can add that too) and that made things even weirder and weirder. After a cold boot, the adapter was working as standard. Rebooted and the device was disabled by default (my machine is configured to auto enable the bluetooth at boot), but after disabling and reenabling the radio from my DE, the bluetooth reconnected to my mouse for the first time since I've got this adapter under Linux. After another reboot, the radio completely disappeared (not even detected from my DE). I don't really know where the problem resides, but I'm happy that someone is trying to see to the bottom of this.

Marco.

Alright, talking with Intel directly, this patch seems to fix it for 5.15.2:

https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-kiran.k@intel.com/

I have a bunch of other regressions like GPU hangs with 5.15 but at least I see the controller showing up consistently warm reboot after warm reboot.

Can anyone else confirm it works?

(In reply to Guillaume Binet from comment #26)
> Alright, talking with Intel directly, this patch seems to fix it for 5.15.2:
> 
> https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-
> kiran.k@intel.com/
> 
> I have a bunch of other regressions like GPU hangs with 5.15 but at least I
> see the controller showing up consistently warm reboot after warm reboot.
> 
> Can anyone else confirm it works?

Nope, running 5.15.2 and now bluetooth disappears after a reboot. This hasn't fixed the problem for me, it just changed behaviour.

I can confirm that the patch is present, I do see the message added for that patch:

...
[ 2470.756299] Bluetooth: hci0: Timed out waiting for suspend events
[ 2470.756315] Bluetooth: hci0: Suspend timeout bit: 6
[ 2470.756345] Bluetooth: hci0: Suspend notifier action (3) failed: -110
[13556.607173] Bluetooth: hci0: Firmware timestamp 2021.39 buildtype 1 build 31878
[13556.611182] Bluetooth: hci0: No device address configured
[13556.611197] Bluetooth: hci0: Found device firmware: intel/ibt-0041-0041.sfi
[13556.611306] Bluetooth: hci0: Boot Address: 0x100800
[13556.611308] Bluetooth: hci0: Firmware Version: 134-39.21
[13556.611310] Bluetooth: hci0: Firmware already loaded
...

But there is no bluetooth adapter available from both my DE nor from bluetoothctl info command.

The message above with the aforementioned errors are simply after a sleep-wake cycle of my system, bluetooth is dead as before.

(In reply to Marco from comment #27)
> (In reply to Guillaume Binet from comment #26)
> > Alright, talking with Intel directly, this patch seems to fix it for
> 5.15.2:
> > 
> >
> https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-
> > kiran.k@intel.com/
> > 
> > I have a bunch of other regressions like GPU hangs with 5.15 but at least I
> > see the controller showing up consistently warm reboot after warm reboot.
> > 
> > Can anyone else confirm it works?
> 
> Nope, running 5.15.2 and now bluetooth disappears after a reboot. This
> hasn't fixed the problem for me, it just changed behaviour.
> 
> I can confirm that the patch is present, I do see the message added for that
> patch:
> ....
> [13556.611182] Bluetooth: hci0: No device address configured
> [13556.611197] Bluetooth: hci0: Found device firmware:
> ...
> 
> But there is no bluetooth adapter available from both my DE nor from
> bluetoothctl info command.

The log "No device address configured" was present even before this patch.
https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-kiran.k@intel.com/

Now its getting printed conditionally based on the mode of the controller. Are your sure that this patch is present in your test? As of now I can see this patch merged only in maintainer tree but not in 5.15-rc2

Thanks,
Kiran

(In reply to Kiran from comment #29)
> 
> (In reply to Marco from comment #27)
> > (In reply to Guillaume Binet from comment #26)
> > > Alright, talking with Intel directly, this patch seems to fix it for
> > 5.15.2:
> > > 
> > >
> >
> https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-
> > > kiran.k@intel.com/
> > > 
> > > I have a bunch of other regressions like GPU hangs with 5.15 but at least
> I
> > > see the controller showing up consistently warm reboot after warm reboot.
> > > 
> > > Can anyone else confirm it works?
> > 
> > Nope, running 5.15.2 and now bluetooth disappears after a reboot. This
> > hasn't fixed the problem for me, it just changed behaviour.
> > 
> > I can confirm that the patch is present, I do see the message added for
> that
> > patch:
> > ....
> > [13556.611182] Bluetooth: hci0: No device address configured
> > [13556.611197] Bluetooth: hci0: Found device firmware:
> > ...
> > 
> > But there is no bluetooth adapter available from both my DE nor from
> > bluetoothctl info command.
> 
> The log "No device address configured" was present even before this patch.
> https://patchwork.kernel.org/project/bluetooth/patch/20211013080511.23945-1-
> kiran.k@intel.com/
> 
> Now its getting printed conditionally based on the mode of the controller.
> Are your sure that this patch is present in your test? As of now I can see
> this patch merged only in maintainer tree but not in 5.15-rc2
> 
> Thanks,
> Kiran

I'm sorry, Kiran, you were 100% right, even the stock kernel hasn't yet included that patch. After compiling 5.15.2 plus the above mentioned patch, I can definitively confirm that on my system the issue is completely fixed. Rebooted 5 times, each time the bluetooth was working correctly. Finally this bug is fixed, I hope it will be merged soon, at least on the 5.15 series.

Thanks a lot for your work,

Marco.

I really hope this patch merges soon as well. What is the best way to be notified when it lands?

PSA: Just tried with 5.15.3, still not good (I am not sure which version the patch it targeted for).

At least for Arch Linux user, this is now included in linux-zen (>=) 5.15.4.zen1-1 kernel

See: https://github.com/zen-kernel/zen-kernel/commit/b7320bcb94e0736064e8e39b9e7466e38fb4a161

And I can also confirm that it fixes the problem.

(In reply to Fabian from comment #33)
> At least for Arch Linux user, this is now included in linux-zen (>=)
> 5.15.4.zen1-1 kernel
> 
> See:
> https://github.com/zen-kernel/zen-kernel/commit/
> b7320bcb94e0736064e8e39b9e7466e38fb4a161
> 
> And I can also confirm that it fixes the problem.

Same here, zen has cherry picked that commit in 5.15.4 and Bluetooth now works perfectly fine here.

Marco.

Created attachment 299669 [details]
attachment-12796-0.html

I confirm Bluetooth working now after reboot/warm boot in Linux 5.15.4.

My sincere thanks to the Intel developers for fixing this issue!
Great work!

Regards,
Tobias

<bugzilla-daemon@bugzilla.kernel.org> schrieb am Mo., 22. Nov. 2021, 14:35:

> https://bugzilla.kernel.org/show_bug.cgi?id=213829
>
> --- Comment #34 from Marco (rodomar705@protonmail.com) ---
> (In reply to Fabian from comment #33)
> > At least for Arch Linux user, this is now included in linux-zen (>=)
> > 5.15.4.zen1-1 kernel
> >
> > See:
> > https://github.com/zen-kernel/zen-kernel/commit/
> > b7320bcb94e0736064e8e39b9e7466e38fb4a161
> >
> > And I can also confirm that it fixes the problem.
>
> Same here, zen has cherry picked that commit in 5.15.4 and Bluetooth now
> works
> perfectly fine here.
>
> Marco.
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You reported the bug.

(In reply to Tobias Predel from comment #35)
> 
> I confirm Bluetooth working now after reboot/warm boot in Linux 5.15.4.

In a mainline kernel without a cherry-picked patch?

(In reply to Paul Bryan from comment #36)
> In a mainline kernel without a cherry-picked patch?

It's not in 5.15.4 or any other mainline kernel. Currently zen-only.

It is fixed in Arch Linux though.
I'm using 5.15.4.arch1-1, not the zen kernel.

See https://github.com/archlinux/linux/commit/236027c0ae73217898ac8249e44394cc1026dada

Let's hope it will soon land in the mainline kernel too.

I faced a similar issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000403) on Debian unstable, but only with v5.15.3. When I built v5.15.4 of the kernel, it went away.

> It is fixed in Arch Linux though.
> I'm using 5.15.4.arch1-1, not the zen kernel.
> 
> See
> https://github.com/archlinux/linux/commit/
> 236027c0ae73217898ac8249e44394cc1026dada

Applying this patch on 5.15.3 didn't resolve this for me, but simply moving to 5.15.4 did.

> 
> Let's hope it will soon land in the mainline kernel too.

I confirm that it's working with 5.15.5-arch1-1

While under 5.15.6, and after accidentally left the latest bluetooth firmware on linux-firmware from all the previous tests, the reboot works, but after 10 to 15 seconds of boot time when my mouse get connected correctly the adapter completely dies and become completely unresponsive, the device stops completely responding to any input from my DE. Logs attached.

After a reboot sometimes the adapter come back to life for the aforementioned 15 to 30 seconds before dies again. Other times the actual adapter disappears from the system.

Initially I thought that this bug has come back, but after replacing the latest firmware and seeing that the driver told me that it was already uploaded to the adapter, I then downloaded linux-firmware and replaced the firmware blobs everything seems to work correctly again.

I hope that some changes are missing for this new firmware in the linux kernel, otherwise AFAICS this will break my setup again.

Created attachment 299915 [details]
Latest firmware on 5.15.6

(In reply to Marco from comment #41)

> Initially I thought that this bug has come back, but after replacing the
> latest firmware and seeing that the driver told me that it was already
> uploaded to the adapter, I then downloaded linux-firmware and replaced the
> firmware blobs everything seems to work correctly again.

Redowloaded the latest released version from the repo, not the latest master files, just to be clear here.

(In reply to Marco from comment #41)
> While under 5.15.6, and after accidentally left the latest bluetooth
> firmware on linux-firmware from all the previous tests, the reboot works,
> but after 10 to 15 seconds of boot time when my mouse get connected
> correctly the adapter completely dies and become completely unresponsive,
> the device stops completely responding to any input from my DE. Logs
> attached.
> 
> After a reboot sometimes the adapter come back to life for the
> aforementioned 15 to 30 seconds before dies again. Other times the actual
> adapter disappears from the system.
> 
> Initially I thought that this bug has come back, but after replacing the
> latest firmware and seeing that the driver told me that it was already
> uploaded to the adapter, I then downloaded linux-firmware and replaced the
> firmware blobs everything seems to work correctly again.
> 
> I hope that some changes are missing for this new firmware in the linux
> kernel, otherwise AFAICS this will break my setup again.

Disregard this, I've tried with the original adapter and the bug is still identical.

Apparently my AMD APU laptop has some issues with USB devices after a while, but only with the internal USB bus on the M.2 port and not with the external USB ports.

I've checked for firmware updates for this platform, but I've already the latest version. I've checked the AGESA version and it seems to still be stuck to 1.0.0.8, according to the SMU version number (I know of the dreaded USB reset bus under load, but this happens even on idle, so I don't really know).

Weird,

Marco.

Well, after the 5.15.8 update of yesterday, the random disconnects seems to be gone. Usually the adapter stopped working after around one hour until I put it to sleep and wake it up again. Now it's basically passed 10 hours without any issues. Weird, but good for me I guess. Hope to see this patch merged soon.

After having been fixed for 5.15 series, the issue seems to reappear on 
linux mainline 5.16, at least on rc 7.

Bluetooth only works after cold boot, but not after warm boot.

Can anyone look into this?
Thanks in advance!

bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> schrieb / wrote / a écrit / je pisao / је писао: 

> https://bugzilla.kernel.org/show_bug.cgi?id=213829
> 
> Tedd An (tedd.an@intel.com) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |tedd.an@intel.com
> 
> --- Comment #19 from Tedd An (tedd.an@intel.com) ---
> This should be fixed with
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btintel.c?id=35191a0fe986bacf69bd842de81119dca7970f11
> 
> I tried it with 5.15 and didn't see the problem.
> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You reported the bug.

@Tobias (In reply to Tobias Predel from comment #46)
> After having been fixed for 5.15 series, the issue seems to reappear on 
> linux mainline 5.16, at least on rc 7.

As far as I know, this issue hasn't been fixed in the mainline kernel. Distro(s) are cherry-picking patches to address it.

(In reply to Paul Bryan from comment #47)
>
> As far as I know, this issue hasn't been fixed in the mainline kernel.
> Distro(s) are cherry-picking patches to address it.

It's fixed upstream since 5.15.5 or 6

On 5.15.12 arch if i do a reboot i get no bluetooth. The PC needs to be shutdown and then turned on again for it to work.

And even when its working it is a bit wonky. I get it to throw errors in the journal and stop working. Hopefully a firmware update in the next kernel will fix that.

(In reply to Apostolos B. from comment #49)
> On 5.15.12 arch if i do a reboot i get no bluetooth. The PC needs to be
> shutdown and then turned on again for it to work.

I cant recreate this. 5.15.12 (in linux and linux-zen) both work just fine after reboot.

> 
> And even when its working it is a bit wonky. I get it to throw errors in the
> journal and stop working. Hopefully a firmware update in the next kernel
> will fix that.

It's working very reliable for me. That said I'm using it only for mice and game-controller.

What kind of errors?

Same here, can't see any issues after a reboot.

About the errors, I mentioned this a few posts above #41, but this happens on another Bluetooth adapter version, so I'm not really sure where the problem lies here.

AFA I can remember, since 5.15.8/9 I haven't seen this issue back, so I'm not really sure if it's the same problem (randomly stop working, the whole Bluetooth device stop responding to the Linux kernel).

Marco.

> What kind of errors?

Some like that:

Ιαν 05 18:20:53 mainland bluetoothd[25908]: Loading LTKs timed out for hci0
Ιαν 05 18:20:53 mainland kernel: Bluetooth: hci0: command 0x0c52 tx timeout
Ιαν 05 18:20:55 mainland kernel: Bluetooth: hci0: command 0x0c24 tx timeout
Ιαν 05 18:20:57 mainland kernel: Bluetooth: hci0: command 0x0c1a tx timeout
Ιαν 05 18:20:59 mainland kernel: Bluetooth: hci0: command 0x0405 tx timeout
Ιαν 05 18:20:59 mainland kernel: Bluetooth: hci0: No way to reset. Ignoring and continuing
Ιαν 05 18:21:36 mainland kernel: Bluetooth: hci0: command 0x0408 tx timeout
Ιαν 05 18:21:36 mainland kernel: Bluetooth: hci0: No way to reset. Ignoring and continuing

I think those are the ones that are logged when i cant use the mouse any more and need to shutdown completely.

Might be usb related since afai understand the bluetooth adapter is connected via USB.

(In reply to Apostolos B. from comment #52)
> > What kind of errors?
> 
> Some like that:
> 
> Ιαν 05 18:20:53 mainland bluetoothd[25908]: Loading LTKs timed out for hci0
> Ιαν 05 18:20:53 mainland kernel: Bluetooth: hci0: command 0x0c52 tx timeout
> Ιαν 05 18:20:55 mainland kernel: Bluetooth: hci0: command 0x0c24 tx timeout
> Ιαν 05 18:20:57 mainland kernel: Bluetooth: hci0: command 0x0c1a tx timeout
> Ιαν 05 18:20:59 mainland kernel: Bluetooth: hci0: command 0x0405 tx timeout
> Ιαν 05 18:20:59 mainland kernel: Bluetooth: hci0: No way to reset. Ignoring
> and continuing
> Ιαν 05 18:21:36 mainland kernel: Bluetooth: hci0: command 0x0408 tx timeout
> Ιαν 05 18:21:36 mainland kernel: Bluetooth: hci0: No way to reset. Ignoring
> and continuing
> 
> I think those are the ones that are logged when i cant use the mouse any
> more and need to shutdown completely.
> 
> Might be usb related since afai understand the bluetooth adapter is
> connected via USB.

Same issues as mine, are you on a Ryzen or Intel?

As far as I have previously debugged, I wasn't unable to pinpoint the cause, since it was happening randomly also on a Realtek radio, so it was either the Bluetooth driver or an actual platform issue (but the external USB ports was still working correctly, therefore I had never been able to find the root cause).

Marco.

Its an intel based laptop. Samsung Galaxy Book Pro 13 to be exact. Since you said the usb port works correctly then its a BT issue probably. I cant verify that myself though since its internal in my case.

Anyway. Hopefully a future update will fix that.

Looking into the logs i also get:
Ιαν 06 01:08:24 mainland bluetoothd[448]: Failed to set mode: Blocked through rfkill (0x12)
Ιαν 06 01:08:31 mainland bluetoothd[448]: src/profile.c:record_cb() Unable to get Hands-Free Voice gateway SDP record: Host is down

But i am not sure what is related to it.

(In reply to Apostolos B. from comment #54)
> Its an intel based laptop. Samsung Galaxy Book Pro 13 to be exact. Since you
> said the usb port works correctly then its a BT issue probably. I cant
> verify that myself though since its internal in my case.
> 
> Anyway. Hopefully a future update will fix that.

Yea, since you are on a completely different platform at this point i'll suspect this is probably a generic Bluetooth driver issue.

Hope that this will be fixed sooner or later.

An update to 5.15.13 kind of fixed this. It starts when rebooted but its slower than a cold start. Ie when i start my DE BT is there for the cold start but appears after a little while for the reboot case.

As for the loss of bluetooth bug what i found out after looking a bit more into the logs was that i get this:

kernel: usb 3-10: Failed to suspend device, error -110