Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Thorsten Leemhuis]

[Ccing Douglas Anderson, who might have an idea]
[dropping stable from To, that is irrelevant there]

On 11/17/25 11:55, Thorsten Leemhuis wrote:
> On 11/17/25 10:42, Thorsten Leemhuis wrote:
>> On 11/17/25 02:30, incogcyberpunk@proton.me wrote:
>>> Distro: Arch Linux 
>>> Kernel: since v6.13.2
>> Lo! Thx for the report. It's unlikely that any developer will look into
>> this report[1] as 6.13.y is ancient by kernel development standards and
>> EOL for quite a while.
>>
>> Please check if the latest stable version is still affected; if it is,
>> ideally try latest mainline (6.18-rc6), too. If that is as well, it
>> would be great if you could bisect between 6.13.1 and 6.13.2.
> 
> TWIMC, IncogCyberpunk replied in private to me and wrote:
> 
> """
> Sorry, if I was not clear but, the problem persists in both the stable
> (v6.17.8) and the latest mainline (v6.18-rc6) linux kernels as of Nov 2025
> """
> 
> Please reply in public next time.

IncogCyberpunk sent another reply in private. IncogCyberpunk, please
just use "reply-to-all", I cannot forward each of your replies manually.
Anyway, here it is:

"""
The logs for the 6.18-rc6 mainline kernel are provided below Also, to
make it clear, the regression has been observed in both the stable and
the mainline kernels since the kernel 6.13.2. 

Logs for v6.18-rc6 kernel: 
https://pastebin.com/GeAzr56Z
"""

To quote from that:

"""
Nov 17 17:14:30 Incog kernel: BUG: kernel NULL pointer dereference, address: 00000000000000d0
Nov 17 17:14:30 Incog kernel: fbcon: Taking over console
Nov 17 17:14:30 Incog kernel: #PF: supervisor write access in kernel mode
Nov 17 17:14:30 Incog kernel: #PF: error_code(0x0002) - not-present page
Nov 17 17:14:30 Incog kernel: PGD 0 P4D 0 
Nov 17 17:14:30 Incog kernel: Oops: Oops: 0002 [#1] SMP NOPTI
Nov 17 17:14:30 Incog kernel: CPU: 8 UID: 0 PID: 136 Comm: kworker/u49:0 Tainted: G S                  6.18.0-rc6-1-mainline #1 PREEMPT(full)  232968b2ab8c223687b1bdd5c39590a8f510b2d3
Nov 17 17:14:30 Incog kernel: Tainted: [S]=CPU_OUT_OF_SPEC
Nov 17 17:14:30 Incog kernel: Hardware name: Acer Aspire A315-59/Callisto_ADU, BIOS V1.16 08/16/2022
Nov 17 17:14:30 Incog kernel: Workqueue: hci0 hci_power_on [bluetooth]
Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
Nov 17 17:14:30 Incog kernel: PKRU: 55555554
Nov 17 17:14:30 Incog kernel: Call Trace:
Nov 17 17:14:30 Incog kernel:  <TASK>
Nov 17 17:14:30 Incog kernel:  btusb_mtk_setup+0xa0/0x1a0 [btusb 3ead27e09a395fe31ca20705f760e78aab4d59d8]
Nov 17 17:14:30 Incog kernel:  hci_dev_open_sync+0x102/0xb80 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  ? try_to_wake_up+0x35b/0x840
Nov 17 17:14:30 Incog kernel:  hci_dev_do_open+0x23/0x60 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  hci_power_on+0x4d/0x250 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  process_one_work+0x193/0x350
Nov 17 17:14:30 Incog kernel:  worker_thread+0x2d7/0x410
Nov 17 17:14:30 Incog kernel:  ? __pfx_worker_thread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  kthread+0xfc/0x240
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ret_from_fork+0x1c2/0x1f0
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ret_from_fork_asm+0x1a/0x30
Nov 17 17:14:30 Incog kernel:  </TASK>
Nov 17 17:14:30 Incog kernel: Modules linked in: btusb intel_rapl_msr uvcvideo ghash_clmulni_intel snd_pcm_dmaengine processor_thermal_rfim iTCO_wdt mt76 btmtk processor_thermal_rapl videobuf2_vmalloc intel_pmc_bxt snd_pcm aesni_intel mei_pxp btrtl mei_hdcp iTCO_vendor_support ee1004 intel_rapl_common btbcm uvc rapl snd_timer videobuf2_memops btintel intel_cstate processor_thermal_wt_req mac80211 hid_multitouch(+) i2c_i801 spi_nor mei_me videobuf2_v4l2 acer_wmi snd i2c_smbus processor_thermal_power_floor bluetooth intel_uncore mtd videobuf2_common pcspkr wmi_bmof platform_profile libarc4 soundcore i2c_mux mei thunderbolt(+) processor_thermal_mbox igen6_edac intel_oc_wdt ov13858 i2c_hid_acpi v4l2_fwnode int3403_thermal int340x_thermal_zone v4l2_async i2c_hid intel_pmc_core videodev pmt_telemetry mc pmt_discovery intel_hid int3400_thermal pmt_class pinctrl_tigerlake acpi_thermal_rel sparse_keymap mousedev acpi_pad intel_pmc_ssram_telemetry joydev acer_wireless mac_hid cfg80211 rfkill usblp pkcs8_key_parser crypto_user ntsync dm_mod loop
Nov 17 17:14:30 Incog kernel:  nfnetlink ip_tables x_tables xe intel_vsec drm_ttm_helper drm_suballoc_helper gpu_sched nvme drm_gpuvm nvme_core nvme_keyring drm_exec nvme_auth hkdf drm_gpusvm_helper i915 i2c_algo_bit drm_buddy ttm serio_raw video intel_gtt spi_intel_pci intel_lpss_pci drm_display_helper intel_lpss spi_intel wmi vmd cec idma64
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0
Nov 17 17:14:30 Incog kernel: ---[ end trace 0000000000000000 ]---
Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
Nov 17 17:14:30 Incog kernel: PKRU: 55555554
Nov 17 17:14:30 Incog kernel: note: kworker/u49:0[136] exited with irqs disabled
"""

A very quick a rough search on lore made me wonder if e9087e828827e5
("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()")
from Douglas might be the culprit, which was indeed added to 6.13.2:
https://lore.kernel.org/all/20250205134516.957708847@linuxfoundation.org/

IncogCyberpunk, you might want to try if reverting that one helps.

Ciao, Thorsten

> And no problem, but quite a few people
> write "since v6.13.2" and only mean later 6.13 versions, that's why I asked.
> 
> You might want to provide the logs from 6.18-rc6. Then feel free to wait
> two or three days to see if a developer replies. If not, please bisect
> the problem between 6.13.1 and 6.13.2 – and then try if reverting the
> culprit in mainline fixes the problem (if it's possible to revert it
> there easily). For details, see:
> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
> 
> HTH, ciao, Thorsten
> 
>>> The bluetooth adapter would be recognized and the bluetooth worked
>>> flawlessly till v6.13.1 , but since the v6.13.2 , the bluetooth adapter
>>> doesn't get recognized by the bluetooth service and therefore the
>>> bluetooth functionality doesn't work . 
>>>
>>> I suspect the bluetooth's driver failing to load at the kernel-level. 
>>>
>>>   * The output of |bluetoothctl|​ :
>>>
>>> $: bluetoothctl
>>> Agent registered
>>> [bluetoothctl]> list
>>> [bluetoothctl]> devices
>>> No default controller available
>>> [bluetoothctl]>
>>>
>>>   * The output of |systemctl status bluetooth.service|​ :
>>>
>>> ● bluetooth.service - Bluetooth service
>>>      Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled;
>>> preset: disabled)
>>>      Active: active (running) since Sat 2025-11-15 22:57:00 +0545; 1 day
>>> 8h ago
>>>  Invocation: bddf190655fd4a4290d41cde594f2efaNov 17 17:14:30 Incog kernel: BUG: kernel NULL pointer dereference, address: 00000000000000d0
Nov 17 17:14:30 Incog kernel: fbcon: Taking over console
Nov 17 17:14:30 Incog kernel: #PF: supervisor write access in kernel mode
Nov 17 17:14:30 Incog kernel: #PF: error_code(0x0002) - not-present page
Nov 17 17:14:30 Incog kernel: PGD 0 P4D 0 
Nov 17 17:14:30 Incog kernel: Oops: Oops: 0002 [#1] SMP NOPTI
Nov 17 17:14:30 Incog kernel: CPU: 8 UID: 0 PID: 136 Comm: kworker/u49:0 Tainted: G S                  6.18.0-rc6-1-mainline #1 PREEMPT(full)  232968b2ab8c223687b1bdd5c39590a8f510b2d3
Nov 17 17:14:30 Incog kernel: Tainted: [S]=CPU_OUT_OF_SPEC
Nov 17 17:14:30 Incog kernel: Hardware name: Acer Aspire A315-59/Callisto_ADU, BIOS V1.16 08/16/2022
Nov 17 17:14:30 Incog kernel: Workqueue: hci0 hci_power_on [bluetooth]
Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
Nov 17 17:14:30 Incog kernel: PKRU: 55555554
Nov 17 17:14:30 Incog kernel: Call Trace:
Nov 17 17:14:30 Incog kernel:  <TASK>
Nov 17 17:14:30 Incog kernel:  btusb_mtk_setup+0xa0/0x1a0 [btusb 3ead27e09a395fe31ca20705f760e78aab4d59d8]
Nov 17 17:14:30 Incog kernel:  hci_dev_open_sync+0x102/0xb80 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  ? try_to_wake_up+0x35b/0x840
Nov 17 17:14:30 Incog kernel:  hci_dev_do_open+0x23/0x60 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  hci_power_on+0x4d/0x250 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
Nov 17 17:14:30 Incog kernel:  process_one_work+0x193/0x350
Nov 17 17:14:30 Incog kernel:  worker_thread+0x2d7/0x410
Nov 17 17:14:30 Incog kernel:  ? __pfx_worker_thread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  kthread+0xfc/0x240
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ret_from_fork+0x1c2/0x1f0
Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
Nov 17 17:14:30 Incog kernel:  ret_from_fork_asm+0x1a/0x30
Nov 17 17:14:30 Incog kernel:  </TASK>
Nov 17 17:14:30 Incog kernel: Modules linked in: btusb intel_rapl_msr uvcvideo ghash_clmulni_intel snd_pcm_dmaengine processor_thermal_rfim iTCO_wdt mt76 btmtk processor_thermal_rapl videobuf2_vmalloc intel_pmc_bxt snd_pcm aesni_intel mei_pxp btrtl mei_hdcp iTCO_vendor_support ee1004 intel_rapl_common btbcm uvc rapl snd_timer videobuf2_memops btintel intel_cstate processor_thermal_wt_req mac80211 hid_multitouch(+) i2c_i801 spi_nor mei_me videobuf2_v4l2 acer_wmi snd i2c_smbus processor_thermal_power_floor bluetooth intel_uncore mtd videobuf2_common pcspkr wmi_bmof platform_profile libarc4 soundcore i2c_mux mei thunderbolt(+) processor_thermal_mbox igen6_edac intel_oc_wdt ov13858 i2c_hid_acpi v4l2_fwnode int3403_thermal int340x_thermal_zone v4l2_async i2c_hid intel_pmc_core videodev pmt_telemetry mc pmt_discovery intel_hid int3400_thermal pmt_class pinctrl_tigerlake acpi_thermal_rel sparse_keymap mousedev acpi_pad intel_pmc_ssram_telemetry joydev acer_wireless mac_hid cfg80211 rfkill usblp pkcs8_key_parser crypto_user ntsync dm_mod loop
Nov 17 17:14:30 Incog kernel:  nfnetlink ip_tables x_tables xe intel_vsec drm_ttm_helper drm_suballoc_helper gpu_sched nvme drm_gpuvm nvme_core nvme_keyring drm_exec nvme_auth hkdf drm_gpusvm_helper i915 i2c_algo_bit drm_buddy ttm serio_raw video intel_gtt spi_intel_pci intel_lpss_pci drm_display_helper intel_lpss spi_intel wmi vmd cec idma64
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0
Nov 17 17:14:30 Incog kernel: ---[ end trace 0000000000000000 ]---
Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
Nov 17 17:14:30 Incog kernel: PKRU: 55555554
Nov 17 17:14:30 Incog kernel: note: kworker/u49:0[136] exited with irqs disabled
>>>        Docs: man:bluetoothd(8)
>>>    Main PID: 617 (bluetoothd)
>>>      Status: "Running"
>>>       Tasks: 1 (limit: 18701)
>>>      Memory: 2.8M (peak: 3.8M)
>>>         CPU: 38ms
>>>      CGroup: /system.slice/bluetooth.service
>>>              └─617 /usr/lib/bluetooth/bluetoothd
>>>
>>> Nov 15 22:57:00 Incog systemd[1]: Starting Bluetooth service...
>>> Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth daemon 5.84
>>> Nov 15 22:57:00 Incog systemd[1]: Started Bluetooth service.
>>> Nov 15 22:57:00 Incog bluetoothd[617]: Starting SDP server
>>> Nov 15 22:57:00 Incog bluetoothd[617]: Bluetooth management interface
>>> 1.23 initialized
>>>
>>>   * The output of |lspci|​ is attached below . 
>>>
>>>   * The logs for |journalctl -b|​ for both v6.13.1 and v6.13.2 are
>>>     attached below. 
>>>
>>>
>>> Regards,
>>> IncogCyberpunk
>>>
>>
>>
>>
> 
> 
> 

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Doug Anderson]

Hi,

On Mon, Nov 17, 2025 at 8:48 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> [Ccing Douglas Anderson, who might have an idea]
> [dropping stable from To, that is irrelevant there]
>
> On 11/17/25 11:55, Thorsten Leemhuis wrote:
> > On 11/17/25 10:42, Thorsten Leemhuis wrote:
> >> On 11/17/25 02:30, incogcyberpunk@proton.me wrote:
> >>> Distro: Arch Linux
> >>> Kernel: since v6.13.2
> >> Lo! Thx for the report. It's unlikely that any developer will look into
> >> this report[1] as 6.13.y is ancient by kernel development standards and
> >> EOL for quite a while.
> >>
> >> Please check if the latest stable version is still affected; if it is,
> >> ideally try latest mainline (6.18-rc6), too. If that is as well, it
> >> would be great if you could bisect between 6.13.1 and 6.13.2.
> >
> > TWIMC, IncogCyberpunk replied in private to me and wrote:
> >
> > """
> > Sorry, if I was not clear but, the problem persists in both the stable
> > (v6.17.8) and the latest mainline (v6.18-rc6) linux kernels as of Nov 2025
> > """
> >
> > Please reply in public next time.
>
> IncogCyberpunk sent another reply in private. IncogCyberpunk, please
> just use "reply-to-all", I cannot forward each of your replies manually.
> Anyway, here it is:
>
> """
> The logs for the 6.18-rc6 mainline kernel are provided below Also, to
> make it clear, the regression has been observed in both the stable and
> the mainline kernels since the kernel 6.13.2.
>
> Logs for v6.18-rc6 kernel:
> https://pastebin.com/GeAzr56Z
> """
>
> To quote from that:
>
> """
> Nov 17 17:14:30 Incog kernel: BUG: kernel NULL pointer dereference, address: 00000000000000d0
> Nov 17 17:14:30 Incog kernel: fbcon: Taking over console
> Nov 17 17:14:30 Incog kernel: #PF: supervisor write access in kernel mode
> Nov 17 17:14:30 Incog kernel: #PF: error_code(0x0002) - not-present page
> Nov 17 17:14:30 Incog kernel: PGD 0 P4D 0
> Nov 17 17:14:30 Incog kernel: Oops: Oops: 0002 [#1] SMP NOPTI
> Nov 17 17:14:30 Incog kernel: CPU: 8 UID: 0 PID: 136 Comm: kworker/u49:0 Tainted: G S                  6.18.0-rc6-1-mainline #1 PREEMPT(full)  232968b2ab8c223687b1bdd5c39590a8f510b2d3
> Nov 17 17:14:30 Incog kernel: Tainted: [S]=CPU_OUT_OF_SPEC
> Nov 17 17:14:30 Incog kernel: Hardware name: Acer Aspire A315-59/Callisto_ADU, BIOS V1.16 08/16/2022
> Nov 17 17:14:30 Incog kernel: Workqueue: hci0 hci_power_on [bluetooth]
> Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
> Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
> Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
> Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
> Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
> Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
> Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
> Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
> Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
> Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
> Nov 17 17:14:30 Incog kernel: PKRU: 55555554
> Nov 17 17:14:30 Incog kernel: Call Trace:
> Nov 17 17:14:30 Incog kernel:  <TASK>
> Nov 17 17:14:30 Incog kernel:  btusb_mtk_setup+0xa0/0x1a0 [btusb 3ead27e09a395fe31ca20705f760e78aab4d59d8]
> Nov 17 17:14:30 Incog kernel:  hci_dev_open_sync+0x102/0xb80 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
> Nov 17 17:14:30 Incog kernel:  ? try_to_wake_up+0x35b/0x840
> Nov 17 17:14:30 Incog kernel:  hci_dev_do_open+0x23/0x60 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
> Nov 17 17:14:30 Incog kernel:  hci_power_on+0x4d/0x250 [bluetooth e25d49b4e9236169faf4970d9c81deaa8aed0e62]
> Nov 17 17:14:30 Incog kernel:  process_one_work+0x193/0x350
> Nov 17 17:14:30 Incog kernel:  worker_thread+0x2d7/0x410
> Nov 17 17:14:30 Incog kernel:  ? __pfx_worker_thread+0x10/0x10
> Nov 17 17:14:30 Incog kernel:  kthread+0xfc/0x240
> Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
> Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
> Nov 17 17:14:30 Incog kernel:  ret_from_fork+0x1c2/0x1f0
> Nov 17 17:14:30 Incog kernel:  ? __pfx_kthread+0x10/0x10
> Nov 17 17:14:30 Incog kernel:  ret_from_fork_asm+0x1a/0x30
> Nov 17 17:14:30 Incog kernel:  </TASK>
> Nov 17 17:14:30 Incog kernel: Modules linked in: btusb intel_rapl_msr uvcvideo ghash_clmulni_intel snd_pcm_dmaengine processor_thermal_rfim iTCO_wdt mt76 btmtk processor_thermal_rapl videobuf2_vmalloc intel_pmc_bxt snd_pcm aesni_intel mei_pxp btrtl mei_hdcp iTCO_vendor_support ee1004 intel_rapl_common btbcm uvc rapl snd_timer videobuf2_memops btintel intel_cstate processor_thermal_wt_req mac80211 hid_multitouch(+) i2c_i801 spi_nor mei_me videobuf2_v4l2 acer_wmi snd i2c_smbus processor_thermal_power_floor bluetooth intel_uncore mtd videobuf2_common pcspkr wmi_bmof platform_profile libarc4 soundcore i2c_mux mei thunderbolt(+) processor_thermal_mbox igen6_edac intel_oc_wdt ov13858 i2c_hid_acpi v4l2_fwnode int3403_thermal int340x_thermal_zone v4l2_async i2c_hid intel_pmc_core videodev pmt_telemetry mc pmt_discovery intel_hid int3400_thermal pmt_class pinctrl_tigerlake acpi_thermal_rel sparse_keymap mousedev acpi_pad intel_pmc_ssram_telemetry joydev acer_wireless mac_hid cfg80211 rfkill usblp pkcs8_key_parser crypto_user ntsync dm_mod loop
> Nov 17 17:14:30 Incog kernel:  nfnetlink ip_tables x_tables xe intel_vsec drm_ttm_helper drm_suballoc_helper gpu_sched nvme drm_gpuvm nvme_core nvme_keyring drm_exec nvme_auth hkdf drm_gpusvm_helper i915 i2c_algo_bit drm_buddy ttm serio_raw video intel_gtt spi_intel_pci intel_lpss_pci drm_display_helper intel_lpss spi_intel wmi vmd cec idma64
> Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0
> Nov 17 17:14:30 Incog kernel: ---[ end trace 0000000000000000 ]---
> Nov 17 17:14:30 Incog kernel: RIP: 0010:mutex_lock+0x1c/0x30
> Nov 17 17:14:30 Incog kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53 48 89 fb 2e 2e 2e 31 c0 65 48 8b 15 de 07 d7 01 31 c0 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b1 90 90 90
> Nov 17 17:14:30 Incog kernel: RSP: 0018:ffffcf12807fbd88 EFLAGS: 00010246
> Nov 17 17:14:30 Incog kernel: RAX: 0000000000000000 RBX: 00000000000000d0 RCX: 0000000000000001
> Nov 17 17:14:30 Incog kernel: RDX: ffff8c88c61f0000 RSI: 0000000000000002 RDI: 00000000000000d0
> Nov 17 17:14:30 Incog kernel: RBP: ffff8c88c7a20028 R08: 0000000000000000 R09: 0000000000000010
> Nov 17 17:14:30 Incog kernel: R10: 0000000000000000 R11: 0000000000000404 R12: ffff8c88c9fb4000
> Nov 17 17:14:30 Incog kernel: R13: ffff8c88c61c1a05 R14: 0000000000000000 R15: ffff8c88c9fb4408
> Nov 17 17:14:30 Incog kernel: FS:  0000000000000000(0000) GS:ffff8c8cd8f02000(0000) knlGS:0000000000000000
> Nov 17 17:14:30 Incog kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Nov 17 17:14:30 Incog kernel: CR2: 00000000000000d0 CR3: 000000010b106000 CR4: 0000000000f50ef0
> Nov 17 17:14:30 Incog kernel: PKRU: 55555554
> Nov 17 17:14:30 Incog kernel: note: kworker/u49:0[136] exited with irqs disabled
> """
>
> A very quick a rough search on lore made me wonder if e9087e828827e5
> ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()")
> from Douglas might be the culprit, which was indeed added to 6.13.2:
> https://lore.kernel.org/all/20250205134516.957708847@linuxfoundation.org/
>
> IncogCyberpunk, you might want to try if reverting that one helps.

Certainly that seems plausible if the PC points to mutex_lock(). I
guess that means "btmtk_data->isopkt_intf" must be NULL? This would
probably fix you?

@@ -2714,6 +2714,11 @@ static void btusb_mtk_claim_iso_intf(struct
btusb_data *data)
        struct btmtk_data *btmtk_data = hci_get_priv(data->hdev);
        int err;

+       if (!btmtk_data->isopkt_intf) {
+               bt_dev_err(data->hdev, "Can't claim NULL iso interface");
+               return;
+       }
+

I don't personally know the driver well enough to know if that's
"safe" because we're checking w/ no locking, but it would at least be
as safe as the code was before my patch.

-Doug

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

I can confirm that reverting the commit `Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()` with the following commit details , solves this regression that has been present in both the stable and the mainline kernels since 6.13.2

Commit Details:
- Title: Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()
- commit id: 4194766ec8756f4f654d595ae49962acbac49490
- [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ]
- Author: Douglas Anderson <dianders@chromium.org>
- Date:   Wed Jan 15 19:36:36 2025 -0800

Reverting the above mentioned commit and building the latest mainline kernel without the trouble-causing commit fixes the issue and the bluetooth adapter now is properly recognized and bluetooth works flawlessly.

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Doug Anderson]

Hi,

On Wed, Nov 19, 2025 at 12:05 AM <incogcyberpunk@proton.me> wrote:
>
> I can confirm that reverting the commit `Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()` with the following commit details , solves this regression that has been present in both the stable and the mainline kernels since 6.13.2
>
> Commit Details:
> - Title: Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()
> - commit id: 4194766ec8756f4f654d595ae49962acbac49490
> - [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ]
> - Author: Douglas Anderson <dianders@chromium.org>
> - Date:   Wed Jan 15 19:36:36 2025 -0800
>
> Reverting the above mentioned commit and building the latest mainline kernel without the trouble-causing commit fixes the issue and the bluetooth adapter now is properly recognized and bluetooth works flawlessly.

Hopefully fixed by this commit:

https://lore.kernel.org/r/20251119085354.1.I1ae7aebc967e52c7c4be7aa65fbd81736649568a@changeid

Can you confirm and add your Tested-by in response to that patch if it works?

-Doug

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

Yes, manually updating `drivers/btusb/btusb.c` , with the below proposed patch fixes the regression issue.
The proposed patch solves the regression of `bluetooth adapter provided by btusb not being recognized in both the stable and the mainline kernel since 6.13.2`

The proposed patch: 
`
index a722446ec73d..1466e0f1865d 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2714,6 +2714,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data)
 	struct btmtk_data *btmtk_data = hci_get_priv(data->hdev);
 	int err;
 
+	if (!btmtk_data->isopkt_intf) {
+		bt_dev_err(data->hdev, "Can't claim NULL iso interface");
+		return;
+	}
+
 	/*
 	 * The function usb_driver_claim_interface() is documented to need
 	 * locks held if it's not called from a probe routine. The code here
`

I applied the patch as suggested, but now what do I have to do to get this fixed upstream and fixed in the next mainline & stable releases.

Also, could you brief a bit, on how this proposed patch containing , a NULL check for the `btmtk_data->isopkt_intf`; solves the problems introduced by the problematic commit with: [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ]


Regards,
IncogCyberpunk

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Doug Anderson]

Hi,

On Wed, Nov 19, 2025 at 4:43 PM <incogcyberpunk@proton.me> wrote:
>
> Yes, manually updating `drivers/btusb/btusb.c` , with the below proposed patch fixes the regression issue.
> The proposed patch solves the regression of `bluetooth adapter provided by btusb not being recognized in both the stable and the mainline kernel since 6.13.2`
>
> The proposed patch:
> `
> index a722446ec73d..1466e0f1865d 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -2714,6 +2714,11 @@ static void btusb_mtk_claim_iso_intf(struct btusb_data *data)
>         struct btmtk_data *btmtk_data = hci_get_priv(data->hdev);
>         int err;
>
> +       if (!btmtk_data->isopkt_intf) {
> +               bt_dev_err(data->hdev, "Can't claim NULL iso interface");
> +               return;
> +       }
> +
>         /*
>          * The function usb_driver_claim_interface() is documented to need
>          * locks held if it's not called from a probe routine. The code here
> `
>
> I applied the patch as suggested, but now what do I have to do to get this fixed upstream and fixed in the next mainline & stable releases.

Excellent. The best way to get the fix landed is to respond to the
post I made at:

https://lore.kernel.org/r/20251119085354.1.I1ae7aebc967e52c7c4be7aa65fbd81736649568a@changeid

...and add your "Tested-by" tag. With that, the Bluetooth maintainers
(if they're happy with the patch) will land it and it can start
working its way to stable.


> Also, could you brief a bit, on how this proposed patch containing , a NULL check for the `btmtk_data->isopkt_intf`; solves the problems introduced by the problematic commit with: [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ]

Check out the commit message on the patch I posted. I explained why
the NULL check fixes the problem there. If that's unclear, I can try
rewording.


-Doug

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

Excellant , i will reply to the lore so that further progress from the Bluetooth maintainers can take place.

Also ,
 Yes .Simply because this is an unknown territory for me, i had a hard time understanding the problems just from the commit patch message.

I would be grateful if I could understand how the `btmtk_data->isopkt_intf` being NULL caused a crash due to the commit in 6.13.2 and what it means to say `Prior to that
commit we'd pass the NULL pointer directly to
usb_driver_claim_interface() which would detect it and return an
error, which was handled.`.
How was the pointer passed directly such that the device_lock mutex , worked in an undesired manner to lock the adapter and turn it on.

Sorry, for the trouble and the redundancy.

Regards,
IncogCyberpunk

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Doug Anderson]

Hi,


On Wed, Nov 19, 2025 at 5:04 PM <incogcyberpunk@proton.me> wrote:
>
> Excellant , i will reply to the lore so that further progress from the Bluetooth maintainers can take place.
>
> Also ,
>  Yes .Simply because this is an unknown territory for me, i had a hard time understanding the problems just from the commit patch message.
>
> I would be grateful if I could understand how the `btmtk_data->isopkt_intf` being NULL caused a crash due to the commit in 6.13.2 and what it means to say `Prior to that
> commit we'd pass the NULL pointer directly to
> usb_driver_claim_interface() which would detect it and return an
> error, which was handled.`.
> How was the pointer passed directly such that the device_lock mutex , worked in an undesired manner to lock the adapter and turn it on.

In 6.13.1, the following could happen:

1. We'd be running btusb_mtk_setup()

2. In btusb_mtk_setup(), we'd run:
  btmtk_data->isopkt_intf = usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)

3. If usb_ifnum_to_if() returned NULL, "btmtk_data->isopkt_intf" would be NULL.

4. Next, btusb_mtk_setup() would call btusb_mtk_claim_iso_intf().

5. btusb_mtk_claim_iso_intf() would pass "btmtk_data->isopkt_intf"
(NULL) to usb_driver_claim_interface() as "iface".

6. usb_driver_claim_interface() would see that its parameter "iface"
is NULL and would return an error.

7. btusb_mtk_claim_iso_intf() would notice the error, print "Failed to
claim iso interface: %d", and return.


In 6.13.2 after commit e9087e828827 ("Bluetooth: btusb: mediatek: Add
locks for usb_driver_claim_interface()"), we'd add in this step after
step 4:

4.5 btusb_mtk_claim_iso_intf() would call:
  device_lock(&btmtk_data->isopkt_intf->dev);

If "btmtk_data->isopkt_intf" is NULL, this is the same as
"&(NULL->dev)", so we'd pass a number that's very close to NULL in as
the dev pointer. Then device_lock() would try to dereference that and
crash.

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

On Thursday, November 20th, 2025 at 12:16 PM <dianders@chromium.org> wrote: 
> In 6.13.1, the following could happen:
> 
> 1. We'd be running btusb_mtk_setup()
> 
> 2. In btusb_mtk_setup(), we'd run:
>   btmtk_data->isopkt_intf = usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
> 
> 3. If usb_ifnum_to_if() returned NULL, "btmtk_data->isopkt_intf" would be NULL.
> 
> 4. Next, btusb_mtk_setup() would call btusb_mtk_claim_iso_intf().
> 
> 5. btusb_mtk_claim_iso_intf() would pass "btmtk_data->isopkt_intf"
> (NULL) to usb_driver_claim_interface() as "iface".
> 
> 6. usb_driver_claim_interface() would see that its parameter "iface"
> is NULL and would return an error.
> 
> 7. btusb_mtk_claim_iso_intf() would notice the error, print "Failed to
> claim iso interface: %d", and return.
> 
> 
> In 6.13.2 after commit e9087e828827 ("Bluetooth: btusb: mediatek: Add
> locks for usb_driver_claim_interface()"), we'd add in this step after
> step 4:
> 
> 4.5 btusb_mtk_claim_iso_intf() would call:
>   device_lock(&btmtk_data->isopkt_intf->dev);
> 
> If "btmtk_data->isopkt_intf" is NULL, this is the same as
> "&(NULL->dev)", so we'd pass a number that's very close to NULL in as
> the dev pointer. Then device_lock() would try to dereference that and
> crash.


Sorry for the lack of knowledge on my part, but could you provide insights as how the bluetooth was functioning wihout errors in 6.13.1 :

1. Is it because there was no device_lock() checks in 6.13.1 and is because of the newly added `device_lock()` added on 6.13.2 ? 
2. Is it because there was `device_lock()` in 6.13.1 that despite being provided a NULL pointer,`device_lock()` could dereference and the bluetooth adapter would turn on BUT in 6.13.2 , `device_lock()` would be provided a number close to NULL which could not be dereferenced and hence the bluetooth adapter wouldn't turn on ?

Hope it's not much trouble for you.

Regards,
IncogCyberpunk

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Doug Anderson]

Hi,

On Thu, Nov 20, 2025 at 2:14 AM <incogcyberpunk@proton.me> wrote:
>
>
> On Thursday, November 20th, 2025 at 12:16 PM <dianders@chromium.org> wrote:
> > In 6.13.1, the following could happen:
> >
> > 1. We'd be running btusb_mtk_setup()
> >
> > 2. In btusb_mtk_setup(), we'd run:
> >   btmtk_data->isopkt_intf = usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)
> >
> > 3. If usb_ifnum_to_if() returned NULL, "btmtk_data->isopkt_intf" would be NULL.
> >
> > 4. Next, btusb_mtk_setup() would call btusb_mtk_claim_iso_intf().
> >
> > 5. btusb_mtk_claim_iso_intf() would pass "btmtk_data->isopkt_intf"
> > (NULL) to usb_driver_claim_interface() as "iface".
> >
> > 6. usb_driver_claim_interface() would see that its parameter "iface"
> > is NULL and would return an error.
> >
> > 7. btusb_mtk_claim_iso_intf() would notice the error, print "Failed to
> > claim iso interface: %d", and return.
> >
> >
> > In 6.13.2 after commit e9087e828827 ("Bluetooth: btusb: mediatek: Add
> > locks for usb_driver_claim_interface()"), we'd add in this step after
> > step 4:
> >
> > 4.5 btusb_mtk_claim_iso_intf() would call:
> >   device_lock(&btmtk_data->isopkt_intf->dev);
> >
> > If "btmtk_data->isopkt_intf" is NULL, this is the same as
> > "&(NULL->dev)", so we'd pass a number that's very close to NULL in as
> > the dev pointer. Then device_lock() would try to dereference that and
> > crash.
>
>
> Sorry for the lack of knowledge on my part, but could you provide insights as how the bluetooth was functioning wihout errors in 6.13.1 :
>
> 1. Is it because there was no device_lock() checks in 6.13.1 and is because of the newly added `device_lock()` added on 6.13.2 ?
> 2. Is it because there was `device_lock()` in 6.13.1 that despite being provided a NULL pointer,`device_lock()` could dereference and the bluetooth adapter would turn on BUT in 6.13.2 , `device_lock()` would be provided a number close to NULL which could not be dereferenced and hence the bluetooth adapter wouldn't turn on ?

Right. There was no "device_lock()" checks in 6.13.1. The lack of
"device_lock()" caused a different kind of crash (sometimes), which is
why I added it. ...but I missed that we need to check for NULL before
calling device_lock().

-Doug

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[incogcyberpunk]

So, now does this patch for the regression gets merged upstream for the next mainline and stable releases ? 


Regards, 
IncogCyberpunk 

Re: [REGRESSION] Bluetooth adapter provided by `btusb` not recognized since v6.13.2

[Greg KH]

On Thu, Nov 20, 2025 at 04:35:27PM +0000, incogcyberpunk@proton.me wrote:
> So, now does this patch for the regression gets merged upstream for the next mainline and stable releases ? 

Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

for how this happens.