Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #94324 > unrolled thread
| Started by | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| First post | 2026-10-03 17:20 +0200 |
| Last post | 2026-10-25 19:10 +0100 |
| Articles | 13 — 5 participants |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Salvatore Bonaccorso <carnil@debian.org> - 2026-10-03 17:20 +0200
Processed: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-10-03 17:20 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Sasha Levin <sashal@kernel.org> - 2026-10-04 18:40 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-10-12 17:40 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-10-13 11:10 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-10-23 15:50 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Sasha Levin <sashal@kernel.org> - 2026-10-24 22:30 +0200
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-10-25 19:10 +0100
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Sasha Levin <sashal@kernel.org> - 2026-10-26 00:40 +0100
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-11-02 12:20 +0100
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-11-02 12:20 +0100
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2026-10-25 19:10 +0100
Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) Thorsten Leemhuis <regressions@leemhuis.info> - 2026-10-25 19:10 +0100
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2026-10-03 17:20 +0200 |
| Subject | Bug#1149377: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) |
| Message-ID | <NK9GN-3kdQ-1@gated-at.bofh.it> |
Control: forwarded -1 https://lore.kernel.org/regressions/7179104011040.2214689.5921682013387867802@eldamar.lan
Hi
In Debian Erik Brangs reported that after the update from 6.12.107 to
6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
anymore working, the full report is found at
https://bugs.debian.org/1149377 .
| [ 38.135482] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
| [ 38.135486] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761cu_fw.bin
| [ 38.135751] snd_hda_intel 0000:08:00.1: bound 0000:08:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
| [ 38.138313] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input11
| [ 38.138410] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input12
| [ 38.138478] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input13
| [ 38.138534] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.1/sound/card1/input14
| [ 38.138657] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [ 38.138860] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [ 38.138874] bluetooth hci0: firmware: failed to load rtl_bt/rtl8761cu_fw.bin (-2)
| [ 38.138877] bluetooth hci0: Direct firmware load for rtl_bt/rtl8761cu_fw.bin failed with error -2
| [ 38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
| [ 38.194794] snd_hda_codec_realtek hdaudioC2D0: autoconfig for ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
| [ 38.194806] snd_hda_codec_realtek hdaudioC2D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
| [ 38.194809] snd_hda_codec_realtek hdaudioC2D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
| [ 38.194812] snd_hda_codec_realtek hdaudioC2D0: mono: mono_out=0x0
| [ 38.194815] snd_hda_codec_realtek hdaudioC2D0: inputs:
| [ 38.194817] snd_hda_codec_realtek hdaudioC2D0: Rear Mic=0x18
| [ 38.194820] snd_hda_codec_realtek hdaudioC2D0: Front Mic=0x19
| [ 38.194822] snd_hda_codec_realtek hdaudioC2D0: Line=0x1a
| [ 38.208365] snd_hda_codec_realtek hdaudioC0D1: autoconfig for ALC898: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
| [ 38.208384] snd_hda_codec_realtek hdaudioC0D1: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
| [ 38.208387] snd_hda_codec_realtek hdaudioC0D1: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
| [ 38.208390] snd_hda_codec_realtek hdaudioC0D1: mono: mono_out=0x0
| [ 38.208392] snd_hda_codec_realtek hdaudioC0D1: inputs:
| [ 38.208394] snd_hda_codec_realtek hdaudioC0D1: Rear Mic=0x18
| [ 38.208396] snd_hda_codec_realtek hdaudioC0D1: Front Mic=0x19
| [ 38.208398] snd_hda_codec_realtek hdaudioC0D1: Line=0x1a
| [ 38.237349] input: HD-Audio Generic Rear Mic as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input15
| [ 38.237414] input: HD-Audio Generic Front Mic as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input16
| [ 38.237517] input: HD-Audio Generic Line as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input17
| [ 38.237541] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input20
| [ 38.237619] input: HDA Creative Rear Mic as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input21
| [ 38.237651] input: HD-Audio Generic Line Out as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input18
| [ 38.237712] input: HD-Audio Generic Front Headphone as /devices/pci0000:00/0000:00:08.1/0000:0a:00.4/sound/card2/input19
| [ 38.237778] input: HDA Creative Front Mic as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input22
| [ 38.239278] input: HDA Creative Line as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input23
| [ 38.239482] input: HDA Creative Line Out Front as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input24
| [ 38.239593] input: HDA Creative Line Out Surround as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input25
| [ 38.239799] input: HDA Creative Line Out CLFE as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input26
| [ 38.241509] input: HDA Creative Front Headphone as /devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:04.0/0000:03:00.0/sound/card0/input27
| [ 38.252148] intel_rapl_common: Found RAPL domain package
| [ 38.252153] intel_rapl_common: Found RAPL domain core
| [ 38.285591] usbcore: registered new interface driver ath9k_htc
| [ 38.287837] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [ 38.287850] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [ 38.287860] usb 1-9: firmware: failed to load ath9k_htc/htc_9271-1.dev.0.fw (-2)
| [ 38.287863] usb 1-9: Direct firmware load for ath9k_htc/htc_9271-1.dev.0.fw failed with error -2
| [ 38.368469] Adding 33487868k swap on /dev/sda6. Priority:-2 extents:1 across:33487868k SS
| [ 38.748227] audit: type=1400 audit(1790704634.157:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=1418 comm="apparmor_parser"
| [ 38.748260] audit: type=1400 audit(1790704634.157:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=1413 comm="apparmor_parser"
| [ 38.748306] audit: type=1400 audit(1790704634.157:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="vscode" pid=1426 comm="apparmor_parser"
| [ 38.748347] audit: type=1400 audit(1790704634.157:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=1417 comm="apparmor_parser"
| [ 38.748381] audit: type=1400 audit(1790704634.157:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="crun" pid=1427 comm="apparmor_parser"
| [ 38.748419] audit: type=1400 audit(1790704634.157:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1420 comm="apparmor_parser"
| [ 38.748470] audit: type=1400 audit(1790704634.157:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chrome" pid=1424 comm="apparmor_parser"
| [ 38.748511] audit: type=1400 audit(1790704634.157:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1419 comm="apparmor_parser"
| [ 38.748556] audit: type=1400 audit(1790704634.157:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=1421 comm="apparmor_parser"
| [ 38.748595] audit: type=1400 audit(1790704634.157:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chromium" pid=1425 comm="apparmor_parser"
| [ 39.218164] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
| [ 39.218168] Bluetooth: BNEP filters: protocol multicast
| [ 39.218175] Bluetooth: BNEP socket layer initialized
| [ 39.363652] usb 1-9: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
| [ 39.440211] Generic FE-GE Realtek PHY r8169-0-400:00: attached PHY driver (mii_bus:phy_addr=r8169-0-400:00, irq=MAC)
| [ 39.442083] NET: Registered PF_QIPCRTR protocol family
| [ 39.614314] ath9k_htc 1-9:1.0: ath9k_htc: HTC initialized with 33 credits
| [ 39.640566] r8169 0000:04:00.0 enp4s0: Link is Down
| [ 39.845845] ath9k_htc 1-9:1.0: ath9k_htc: FW Version: 1.4
| [ 39.845849] ath9k_htc 1-9:1.0: FW RMW support: On
| [ 39.845851] ath: EEPROM regdomain: 0x809c
| [ 39.845853] ath: EEPROM indicates we should expect a country code
| [ 39.845855] ath: doing EEPROM country->regdmn map search
| [ 39.845856] ath: country maps to regdmn code: 0x52
| [ 39.845857] ath: Country alpha2 being used: CN
| [ 39.845859] ath: Regpair used: 0x52
| [ 39.849223] ieee80211 phy0: Atheros AR9271 Rev:1
| [ 39.854386] ath9k_htc 1-9:1.0 wlx30b5c211d175: renamed from wlan0
| [ 41.745845] wlx30b5c211d175: authenticate with 1c:ed:6f:bb:ed:4c (local address=30:b5:c2:11:d1:75)
| [ 41.745849] wlx30b5c211d175: send auth to 1c:ed:6f:bb:ed:4c (try 1/3)
| [ 41.807272] wlx30b5c211d175: authenticate with 1c:ed:6f:bb:ed:4c (local address=30:b5:c2:11:d1:75)
| [ 41.807275] wlx30b5c211d175: send auth to 1c:ed:6f:bb:ed:4c (try 1/3)
| [ 41.813896] wlx30b5c211d175: authenticated
| [ 41.816186] wlx30b5c211d175: associate with 1c:ed:6f:bb:ed:4c (try 1/3)
| [ 41.821911] wlx30b5c211d175: RX AssocResp from 1c:ed:6f:bb:ed:4c (capab=0x1431 status=0 aid=5)
| [ 41.828348] wlx30b5c211d175: associated
| [ 41.948210] wlx30b5c211d175: Limiting TX power to 20 (20 - 0) dBm as advertised by 1c:ed:6f:bb:ed:4c
| [ 42.675206] r8169 0000:04:00.0 enp4s0: Link is Up - 1Gbps/Full - flow control rx/tx
| [ 45.079778] kauditd_printk_skb: 119 callbacks suppressed
| [ 45.079783] audit: type=1400 audit(1790704640.485:131): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1955 comm="Xorg" capability=12 capname="net_admin"
| [ 45.272603] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
| [ 46.036834] audit: type=1400 audit(1790704641.445:132): apparmor="STATUS" operation="profile_load" profile="unconfined" name="docker-default" pid=2246 comm="apparmor_parser"
| [ 46.186122] evm: overlay not supported
| [ 46.358551] Bridge firewalling registered
| [ 46.408480] Initializing XFRM netlink socket
| [ 46.552168] audit: type=1400 audit(1790704641.957:133): apparmor="ALLOWED" operation="capable" class="cap" profile="Xorg" pid=1955 comm="Xorg" capability=12 capname="net_admin"
| [ 67.792012] Guest personality initialized and is inactive
| [ 67.792063] VMCI host device registered (name=vmci, major=10, minor=260)
| [ 67.792065] Initialized host personality
| [ 67.799049] NET: Registered PF_VSOCK protocol family
| [ 68.979467] systemd-journald[544]: Time jumped backwards, rotating.
the device now requests rtl_bt/rtl8761cu_fw.bin firwmare (assumtion the device
had previously working firwmare but with adding support for ASUS USB-BT540 for
Realtek 8761CU, tries to load the not avaialble firmware and get not
functional? I'm looping in Ben Hutchings which has much more experience on that
on our end.
#regzbot introduced: f05baf6e0680d8c10d2fbbc5953848fc3e3db957
#regzbot link: https://bugs.debian.org/1149377
Maybe the answer is simply here, Debian needs to provide the firmware from now
on in the firmware-realtek in stable?
Regards,
Salvatore
[toc] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-10-03 17:20 +0200 |
| Subject | Processed: [regression 6.12.y] After backport of 980084de4d9b ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU") bluethooth not anymore working on 0b05:1bef ASUSTek Computer, Inc. Bluetooth Controller (requests firmware) |
| Message-ID | <NK9GN-3kdQ-9@gated-at.bofh.it> |
| In reply to | #94324 |
Processing control commands: > forwarded -1 https://lore.kernel.org/regressions/7179104011040.2214689.5921682013387867802@eldamar.lan Bug #1149377 [src:linux] linux-image-6.12.111+deb13-amd64: Bluetooth no longer works after kernel upgrade Changed Bug forwarded-to-address to 'https://lore.kernel.org/regressions/7179104011040.2214689.5921682013387867802@eldamar.lan' from 'https://lore.kernel.org/regressions/9ac1c05b-e9f2-49e9-af63-9cd0e42115fc@gmail.com/'. -- 1149377: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149377 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Sasha Levin <sashal@kernel.org> |
|---|---|
| Date | 2026-10-04 18:40 +0200 |
| Message-ID | <NKxpL-3wZE-7@gated-at.bofh.it> |
| In reply to | #94324 |
> In Debian Erik Brangs reported that after the update from 6.12.107 to
> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
> anymore working, the full report is found at
> https://bugs.debian.org/1149377 .
>
> | [ 38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
The stable code matches mainline. The failure is a missing firmware file:
rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
and Debian trixie's firmware-realtek 20250410-2 does not have it.
Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
commit, send an upstream revert, or a fallback to ROM firmware when
rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
through the normal Cc: stable route once it is in mainline.
--
Thanks,
Sasha
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-10-12 17:40 +0200 |
| Message-ID | <NNqi6-561u-5@gated-at.bofh.it> |
| In reply to | #94346 |
On 10/4/26 18:29, Sasha Levin wrote:
>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>> anymore working, the full report is found at
>> https://bugs.debian.org/1149377 .
>>
>> | [ 38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
>
> The stable code matches mainline. The failure is a missing firmware file:
> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
> and Debian trixie's firmware-realtek 20250410-2 does not have it.
>
> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
> commit, send an upstream revert, or a fallback to ROM firmware when
> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
> through the normal Cc: stable route once it is in mainline.
Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
Anyone working on this?
If not: Should we revert 980084de4d9b and its backports? Or only the
backports to older stable series?
Strictly speaking it should be the former due to our policies wrt to
firmware -- but I guess most users of a more recent kernels also have a
newer firmware, so I wonder if reverting the change might do more harm
then good now.
Ciao, Thorsten
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-10-13 11:10 +0200 |
| Message-ID | <NNGGd-5eQl-5@gated-at.bofh.it> |
| In reply to | #94453 |
On 10/12/26 19:28, Salvatore Bonaccorso wrote:
> On Mon, Oct 12, 2026 at 02:00:18PM +0200, Thorsten Leemhuis wrote:
>> On 10/4/26 18:29, Sasha Levin wrote:
>>>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>>>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>>>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>>>> anymore working, the full report is found at
>>>> https://bugs.debian.org/1149377 .
>>>>
>>>> | [ 38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
>>>
>>> The stable code matches mainline. The failure is a missing firmware file:
>>> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
>>> and Debian trixie's firmware-realtek 20250410-2 does not have it.
>>>
>>> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
>>> commit, send an upstream revert, or a fallback to ROM firmware when
>>> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
>>> through the normal Cc: stable route once it is in mainline.
>>
>> Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
>> Anyone working on this?
>>
>> If not: Should we revert 980084de4d9b and its backports? Or only the
>> backports to older stable series?
>>
>> Strictly speaking it should be the former due to our policies wrt to
>> firmware -- but I guess most users of a more recent kernels also have a
>> newer firmware, so I wonder if reverting the change might do more harm
>> then good now.
>
> If my understanding is correct from a earlier fixed regression in the
> ariea, aka
> https://lore.kernel.org/regressions/0fd8c1c9-7f56-4bcb-a727-e4386d8ef094@online.de/
> should then not only 980084de4d9b ("Bluetooth: btusb: Add ASUS
> USB-BT540 for Realtek 8761CU") be reverted, but as well along
> 6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> 8761CU") and as well 4a23ce935f74 ("Bluetooth: btrtl: Add the support
> for RTL8761CUV")?
Maybe, I didn't look closer, but that's why reverting in mainline likely
really is a bad idea: it might cause a regression for users that depend
on those changes (one of which is from 6.19).
So I guess reverting some or all of those backports in "older stable
series", as Sasha suggested, might be the best -- but I guess it would
be good if someone with more knowledge in this area could provide an
opinion.
Ciao, Thorsten
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-10-23 15:50 +0200 |
| Message-ID | <NRnOF-7p0a-9@gated-at.bofh.it> |
| In reply to | #94464 |
On 10/13/26 11:03, Thorsten Leemhuis wrote:
> On 10/12/26 19:28, Salvatore Bonaccorso wrote:
>> On Mon, Oct 12, 2026 at 02:00:18PM +0200, Thorsten Leemhuis wrote:
>>> On 10/4/26 18:29, Sasha Levin wrote:
>>>>> In Debian Erik Brangs reported that after the update from 6.12.107 to
>>>>> 6.12.111, specifically with the backport of 980084de4d9b ("Bluetooth:
>>>>> btusb: Add ASUS USB-BT540 for Realtek 8761CU") Bluetooth is not
>>>>> anymore working, the full report is found at
>>>>> https://bugs.debian.org/1149377 .
>>>>> | [ 38.138881] Bluetooth: hci0: RTL: firmware file rtl_bt/rtl8761cu_fw not found
This is still unresolved. Salvatore, Erik, and/or Christoph, could you
confirm my analyses below -- and if it is ask the stable team for the
reverts?
>>>> The stable code matches mainline. The failure is a missing firmware file:
>>>> rtl_bt/rtl8761cu_fw.bin has been in linux-firmware only since 20251111,
>>>> and Debian trixie's firmware-realtek 20250410-2 does not have it.
>>>>
>>>> Marcel, Luiz: could you, or Christoph Zwerschke as the author of the ID
>>>> commit, send an upstream revert, or a fallback to ROM firmware when
>>>> rtl8761cu_fw.bin is missing? Stable will take it for 7.2, 6.18 and 6.12
>>>> through the normal Cc: stable route once it is in mainline.
>>>
>>> Hmmm, that was a week (granted: with the LPC) ago and nothing happened.
>>> Anyone working on this?
>>>
>>> If not: Should we revert 980084de4d9b and its backports? Or only the
>>> backports to older stable series?
>>>
>>> Strictly speaking it should be the former due to our policies wrt to
>>> firmware -- but I guess most users of a more recent kernels also have a
>>> newer firmware, so I wonder if reverting the change might do more harm
>>> then good now.
>>
>> If my understanding is correct from a earlier fixed regression in the
>> ariea, aka
>> https://lore.kernel.org/regressions/0fd8c1c9-7f56-4bcb-a727-e4386d8ef094@online.de/
There Christoph asked "please revert them from every tree below 6.19" --
but they afaics were only reverted for 6.6 and earlier.
"Them" meant the backports of these:
* 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
8761CU") [v7.3-rc1]
* 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU") [v7.3-rc1]
Maybe because 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for
RTL8761CUV") was included in v6.18.53, v6.12.111. Which lead to the
current situation with "firmware file rtl_bt/rtl8761cu_fw not found" in
Debian.
>> should then not only 980084de4d9b ("Bluetooth: btusb: Add ASUS
>> USB-BT540 for Realtek 8761CU") be reverted, but as well along
>> 6f0624b4427e ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
>> 8761CU") and as well 4a23ce935f74 ("Bluetooth: btrtl: Add the support
>> for RTL8761CUV")?
>
> Maybe, I didn't look closer,
I did meanwhile and agree, the backports of these should be reverted
from 6.18.y and 6.12.y:
* 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
8761CU") [v7.3-rc1]
* 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
8761CU") [v7.3-rc1]
* 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
[v6.19-rc1]
At least if the problem wasn't resolved meanwhile, but that wasn't the
case afaics -- or did I miss it? Salvatore, Erik, or Christoph? Or was
it meanwhile agree on to fix this differently, for example by including
that file in a linux-firmware update maybe?
Ciao, Thorsten
but that's why reverting in mainline likely
> really is a bad idea: it might cause a regression for users that depend
> on those changes (one of which is from 6.19).
>
> So I guess reverting some or all of those backports in "older stable
> series", as Sasha suggested, might be the best -- but I guess it would
> be good if someone with more knowledge in this area could provide an
> opinion.
[toc] | [prev] | [next] | [standalone]
| From | Sasha Levin <sashal@kernel.org> |
|---|---|
| Date | 2026-10-24 22:30 +0200 |
| Message-ID | <NRQxj-7ES5-3@gated-at.bofh.it> |
| In reply to | #94594 |
> I did meanwhile and agree, the backports of these should be reverted
> from 6.18.y and 6.12.y:
>
> * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
> 8761CU") [v7.3-rc1]
> * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> 8761CU") [v7.3-rc1]
> * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
> [v6.19-rc1]
The stable trees match mainline here, so nothing is going into stable for
this. The fix has to come from the Bluetooth maintainers or Christoph: an
upstream revert of the ID commits, or a fallback to the ROM firmware when
rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
6.12 through the normal Cc: stable route once it is in mainline.
The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
linux-firmware since 20251111, so a newer firmware-realtek package fixes this
without any kernel change.
--
Thanks,
Sasha
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-10-25 19:10 +0100 |
| Message-ID | <NSaPr-7PzO-173@gated-at.bofh.it> |
| In reply to | #94615 |
On 10/25/26 08:37, Christoph Zwerschke wrote: > On 25.10.26 07:27, Thorsten Leemhuis wrote: >> Feels wrong to me, as >> Documentation/driver-api/firmware/firmware-usage-guidelines.rst says >> "Users switching to a newer kernel should *not* have to install newer >> firmware files to keep their hardware working.". So what those three >> commits did in mainline even there could be considered a >> mistake/regression. No worries, mistakes happen. And reverting it now in >> mainline would do more damage than good. But overall it feels wrong to >> bring that mistake over to older stable series. > > I can confirm the analysis: [...] Thx for taking the time explaining this in details to us, much appreciated! > [...] > Regarding your concern that a revert in mainline would do more damage > than good: on 7.3 I also compared both variants (with and without the > ID entries) with the BT600 for HFP and LE Audio (BlueZ 5.87, PipeWire > 1.6.10). mSBC is negotiated and used even without the wide-band-speech > flag, and I found no difference between ROM and loaded firmware. So > for these two adapters I could not find any damage from reverting the > ID entries in mainline. Of course this does not rule out that the > loaded firmware contains fixes or improvements that my tests did not > cover. > [...] > If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e > (on top of bluetooth.git master, with Cc: stable). Alternatively, > btrtl could fall back to the ROM firmware when rtl8761cu_fw.bin > is missing. I didn't see any regression reports for 7.x releases about those changes, as I suspect that people that regularly switch to the latest stable or mainline releases often update their firmware package, too. So I'm still inclined to say: leave everything as it is in mainline to avoid any risk and revert only the backports of those two in 6.18.y and 6.12.y. Ciao, Thorsten
[toc] | [prev] | [next] | [standalone]
| From | Sasha Levin <sashal@kernel.org> |
|---|---|
| Date | 2026-10-26 00:40 +0100 |
| Message-ID | <NSfYJ-7Srk-3@gated-at.bofh.it> |
| In reply to | #94623 |
> > If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e > > (on top of bluetooth.git master, with Cc: stable). Alternatively, > > btrtl could fall back to the ROM firmware when rtl8761cu_fw.bin > > is missing. > I didn't see any regression reports for 7.x releases about those > changes, [...] So I'm still inclined to say: leave everything as it is > in mainline to avoid any risk and revert only the backports of those > two in 6.18.y and 6.12.y. Yup, that would be appreciated. -- Thanks, Sasha
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-11-02 12:20 +0100 |
| Message-ID | <NUYeZ-9oyt-13@gated-at.bofh.it> |
| In reply to | #94626 |
On 10/29/26 07:02, Salvatore Bonaccorso wrote: > On Sun, Oct 25, 2026 at 07:29:50PM -0400, Sasha Levin wrote: >>>> If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e >>>> (on top of bluetooth.git master, with Cc: stable). Alternatively, >>>> btrtl could fall back to the ROM firmware when rtl8761cu_fw.bin >>>> is missing. >>> I didn't see any regression reports for 7.x releases about those >>> changes, [...] So I'm still inclined to say: leave everything as it is >>> in mainline to avoid any risk and revert only the backports of those >>> two in 6.18.y and 6.12.y. >> >> Yup, that would be appreciated. > > I'm bit lost here :) Who is now going to sen the reverts for the older > stable series? Christian, you offered sending the reverts earlier, could you do this please now that we all seem to be in agreement? Ciao, Thorsten
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-11-02 12:20 +0100 |
| Message-ID | <NUYf0-9oyt-19@gated-at.bofh.it> |
| In reply to | #94726 |
On 11/2/26 12:04, Thorsten Leemhuis wrote: > On 10/29/26 07:02, Salvatore Bonaccorso wrote: >> On Sun, Oct 25, 2026 at 07:29:50PM -0400, Sasha Levin wrote: >>>>> If it helps, I can send reverts of 980084de4d9b and 6f0624b4427e >>>>> (on top of bluetooth.git master, with Cc: stable). Alternatively, >>>>> btrtl could fall back to the ROM firmware when rtl8761cu_fw.bin >>>>> is missing. >>>> I didn't see any regression reports for 7.x releases about those >>>> changes, [...] So I'm still inclined to say: leave everything as it is >>>> in mainline to avoid any risk and revert only the backports of those >>>> two in 6.18.y and 6.12.y. >>> >>> Yup, that would be appreciated. >> >> I'm bit lost here :) Who is now going to sen the reverts for the older >> stable series? > > Christian, you offered sending the reverts earlier, could you do this > please now that we all seem to be in agreement? s/Christian/Christoph/ Sorry!
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2026-10-25 19:10 +0100 |
| Message-ID | <NSaPr-7PzO-175@gated-at.bofh.it> |
| In reply to | #94615 |
On Sat, Oct 24, 2026 at 04:10:59PM -0400, Sasha Levin wrote:
> > I did meanwhile and agree, the backports of these should be reverted
> > from 6.18.y and 6.12.y:
> >
> > * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
> > 8761CU") [v7.3-rc1]
> > * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
> > 8761CU") [v7.3-rc1]
> > * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
> > [v6.19-rc1]
>
> The stable trees match mainline here, so nothing is going into stable for
> this. The fix has to come from the Bluetooth maintainers or Christoph: an
> upstream revert of the ID commits, or a fallback to the ROM firmware when
> rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
> 6.12 through the normal Cc: stable route once it is in mainline.
>
> The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
> linux-firmware since 20251111, so a newer firmware-realtek package fixes this
> without any kernel change.
That's the simplest solution, any users hitting this should also upgrade
that package as it's been out for almost a year now.
thanks,
greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Leemhuis <regressions@leemhuis.info> |
|---|---|
| Date | 2026-10-25 19:10 +0100 |
| Message-ID | <NSaPr-7PzO-177@gated-at.bofh.it> |
| In reply to | #94624 |
On 10/25/26 07:16, Greg Kroah-Hartman wrote:
> On Sat, Oct 24, 2026 at 04:10:59PM -0400, Sasha Levin wrote:
>>> I did meanwhile and agree, the backports of these should be reverted
>>> from 6.18.y and 6.12.y:
>>>
>>> * 980084de4d9b25 ("Bluetooth: btusb: Add ASUS USB-BT540 for Realtek
>>> 8761CU") [v7.3-rc1]
>>> * 6f0624b4427e38 ("Bluetooth: btusb: Add ASUS USB-BT600 for Realtek
>>> 8761CU") [v7.3-rc1]
>>> * 4a23ce935f74d1 ("Bluetooth: btrtl: Add the support for RTL8761CUV")
>>> [v6.19-rc1]
>>
>> The stable trees match mainline here, so nothing is going into stable for
>> this. The fix has to come from the Bluetooth maintainers or Christoph: an
>> upstream revert of the ID commits, or a fallback to the ROM firmware when
>> rtl8761cu_fw.bin is missing. Stable will take either one for 7.2, 6.18 and
>> 6.12 through the normal Cc: stable route once it is in mainline.
>>
>> The other way out is on the distro side. rtl_bt/rtl8761cu_fw.bin has been in
>> linux-firmware since 20251111, so a newer firmware-realtek package fixes this
>> without any kernel change.
>
> That's the simplest solution, any users hitting this should also upgrade
> that package as it's been out for almost a year now.
Feels wrong to me, as
Documentation/driver-api/firmware/firmware-usage-guidelines.rst says
"Users switching to a newer kernel should *not* have to install newer
firmware files to keep their hardware working.". So what those three
commits did in mainline even there could be considered a
mistake/regression. No worries, mistakes happen. And reverting it now in
mainline would do more damage than good. But overall it feels wrong to
bring that mistake over to older stable series.
Ciao, Thorsten
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web