New: Regression: Intel Bluetooth (btintel/hci0) fails firmware boot on 7.0.12, works on 6.17.10 (Dell Inspiron 3501, AX201)

https://bugzilla.kernel.org/show_bug.cgi?id=221840

            Bug ID: 221840
           Summary: Regression: Intel Bluetooth (btintel/hci0) fails
                    firmware boot on 7.0.12, works on 6.17.10 (Dell
                    Inspiron 3501, AX201)
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Created attachment 310581
--> https://bugzilla.kernel.org/attachment.cgi?id=310581&action=edit
dmesg comparison: working kernel 6.17.10 vs broken kernel 7.0.12

Overview:

Intel Bluetooth AX201 CNVi companion radio ("Jefferson Peak", USB ID 8087:0aaa) fails to complete firmware boot handshake on kernel 7.0.12.

After firmware download completes, hci0 fails during "Waiting for device to boot", enters a USB reset loop, and never recovers until rebooting into kernel 6.17.10.

The same hardware, firmware, and BlueZ userspace work correctly on kernel 6.17.10. The regression appears to be kernel-related.

Steps to Reproduce:

(1) Boot the machine into kernel 7.0.12+kali-amd64.

(2) Wait for boot to complete. No user action is needed -- Bluetooth initializes automatically at boot.

(3) Check dmesg for hci0 messages, or run bluetoothctl show.

Expected Results:

hci0 completes firmware boot (~15ms) and the controller powers on normally.

Actual Results:

hci0 times out during "Waiting for device to boot", enters a permanent USB reset loop, and the controller disappears from lsusb/rfkill entirely. Recovery requires rebooting into a different (working) kernel.

System:

Machine: Dell Inspiron 3501

CPU: Intel Core i5-1135G7 (Tiger Lake-UP3)

BIOS: 1.44.0

Wireless: Intel Wi-Fi 6 AX201 (CNVio2), PCI ID 00:14.3, driver iwlwifi

Bluetooth: Intel Bluetooth 9460/9560 "Jefferson Peak", USB ID 8087:0aaa, driver btusb/btintel

Firmware: intel/ibt-19-0-0.sfi, firmware revision 83-7.26

Distribution: Kali Linux rolling

BlueZ: tested with BlueZ 5.85-4 and 5.87-1. Issue reproduces identically on both versions.

Kernel versions tested:

GOOD -- 6.17.10+kali-amd64 (6.17.10-1kali1): Bluetooth initializes correctly ("Device booted in 14813 usecs"), controller works normally. Full dmesg excerpt attached as dmesg-working-6.17.10.txt.

BAD -- 7.0.12+kali-amd64 (7.0.12-2kali1): firmware download completes, but device boot fails and the controller enters a permanent reset loop. Full dmesg excerpt attached as dmesg-broken-7.0.12.txt.

Timing:

Firmware loading time is essentially identical between the two kernels (1839645 usecs on 6.17.10 vs 1847614 usecs on 7.0.12). The regression happens after firmware loading, specifically during the device boot phase that follows it.

Possible affected areas (speculation, not confirmed):

btusb driver changes, or btintel firmware boot handling, or USB interrupt handling, or USB endpoint timing, or timeout handling changes between these kernel versions.

Ruled out -- not a BlueZ/userspace issue:

Tested with BlueZ 5.85-4 and 5.87-1, same result on both, so this is not a userspace regression.

Ruled out -- not a firmware issue:

The exact same firmware file works correctly on kernel 6.17.10, so the firmware itself is not at fault.

Ruled out -- not USB power management:

Tested with USB autosuspend fully disabled (btusb module parameter, a udev rule, and a TLP USB_DENYLIST entry). No change in behaviour.

Ruled out -- not rfkill:

The controller is confirmed unblocked (rfkill list shows soft/hard blocked: no) both before and during the failure.

Ruled out -- not hardware failure:

The same laptop, same physical adapter, works correctly every time on kernel 6.17.10 and fails every time on kernel 7.0.12.

Ruled out -- not a USB topology issue:

Unbinding and rebinding the xHCI PCI controller while running the broken kernel does not recover the device; it re-enters the same boot-timeout loop.

Additional Information:

Kernel 6.19.14+kali-amd64 is also installed on this system but has not yet been tested; will update this report once tested, to narrow the regression range further. Two dmesg excerpts are attached separately (dmesg-working-6.17.10.txt and dmesg-broken-7.0.12.txt) rather than pasted inline, since multi-line log output gets reflowed/collapsed by the comment box otherwise. Happy to test intermediate kernel versions or apply candidate patches -- both a working and a broken kernel are readily available on this exact hardware right now.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221840

Artem S. Tashkinov ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #1 from Artem S. Tashkinov ([email protected]) --- This kernel release is not supported.

Can you reproduce the issue using 7.1.6 or 7.2-rc6 **with** the latest firmware?

Also, are you dual-booting with Windows?

If you do, make sure you have disabled hybrid shutdown off in Windows.

To disable hybrid shutdown (Fast Startup) in Windows, open the Control Panel, go to Power Options, click "Choose what the power buttons do," unlock the settings, and uncheck "Turn on fast startup." Alternatively, disable hibernation via admin command prompt using powercfg /hibernate off

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221840

--- Comment #2 from [email protected] ---
(In reply to Artem S. Tashkinov from comment #1)

No dual-boot — this machine runs Kali only, so Fast Startup/hybrid shutdown doesn't apply here. Will test on 7.1.6 and/or 7.2-rc6 with latest firmware and report back.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.