Your output gives us some information: your rtl8852bu_config.bin is only 6 bytes, which is too small to be valid calibration data and rtl8852bu_config.bin.xz symlinks to rtl8761bu_config.bin.xz, which is an entirely different chip that what you have.
What we don’t know is if this is a linux-firmware bug, realtek-firmware bug, or something else entirely and we still need more info.
First, we need to check with package actually owns the config files:
Thanks you are right, but running rpm -V realtek-firmware | grep rtl8852bu returned still nothing. I guess that means the status of my firmware file is fine.
The size of the file is only 6 bytes. I see the same here. rtl8761bu_config.bin.xz is a symbolic link to rtl8761bu_config.bin.xz:
(base) [gnw3]~/work/realtek% ls -l /usr/lib/firmware/rtl_bt/rtl8852bu_config.bin.xz
lrwxrwxrwx. 1 root root 23 May 18 21:00 /usr/lib/firmware/rtl_bt/rtl8852bu_config.bin.xz -> rtl8761bu_config.bin.xz
(base) [gnw3]~/work/realtek% ls -l /usr/lib/firmware/rtl_bt/rtl8761bu_config.bin.xz
-rw-r--r--. 1 root root 68 May 18 21:00 /usr/lib/firmware/rtl_bt/rtl8761bu_config.bin.xz
I looked for the same file in linux-firmware-20260411-19.5.el10_1.src.rpm from alma linux. After unpacking the rpm file I got linux-firmware-20260411.tar:
Interesting and that’s good context from @gnwiii, who’s using the same chipset.
So, realtek-firmware owns the .xz file and the symlink target decompresses to 6 bytes, which means the RTL8761BU config is also 6 bytes. My guess is that 6 byte file is a valid “empty config” that just tells the system to use chip defaults without overrides. Overall, it looks like all that’s correct.
We’re back to square one in some ways because we still haven’t been able to answer why the chip rejects its own defaults and produces a null MAC.
If you’re willing to keep trying, I’d be interested to see what the 6 bytes actually are:
xxd /usr/lib/firmware/rtl_bt/rtl8852bu_config.bin
ls -la /usr/lib/firmware/rtl_bt/rtl8852bu_fw.bin
file /usr/lib/firmware/rtl_bt/rtl8852bu_fw.bin
sudo dmesg | grep -i "rtl\|hci0\|firmware\|fw" | head -30
I think there’s a chance, the chip might actually need the BTU firmware instead…
Basically, if the driver is mapping your chip to the wrong firmware set internally, no amount of config file fixing will help. That might also explain the persistent null MAC across all we’ve done so far.
Actually, I avoid realtek on my own systems in favor of Intel, but during COVID was helping people using specialized software (from the lab where I worked before retiring) on linux systems provided by IT groups at labs around the world. Many users needed run the software at home on whatever systems they could scrounge, so wifi on realtek was often a source of problems (and it was hard to get alternative more linux friendly USB devices).
[quote="Chen Lv, post:18, topic:191250, username: @alumich
after trying the steps you mentioned in your blog, the Bluetooth adapter still initializes with the same all-zero MAC address and -16 error in Fedora.
[/quote]
Not my blog, but the analysis there seems sound.
@alumich Can you repeat the steps from “The Permanent Fix: Driver Load Ordering with modprobe softdep” and share the details so we can look for places your system behaves differently?
sudo dmesg | grep -i "rtl\|hci0\|firmware\|fw" | head -30
[ 0.278070] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 4.043907] amdgpu 0000:c6:00.0: [drm] Loading DMUB firmware via PSP: version=0x08005B00
[ 4.044333] amdgpu 0000:c6:00.0: [VCN instance 0] Found VCN firmware Version ENC: 1.24 DEC: 9 VEP: 0 Revision: 34
[ 6.388183] SELinux: Permission firmware_load in class system not defined in policy.
[ 7.355764] systemd[1]: systemd-boot-clear-sysfail.service - Clear SysFail Entry If The Boot Is Successful skipped, unmet condition check ConditionPathExists=/sys/firmware/efi/efivars/LoaderEntrySysFail-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
[ 7.355883] systemd[1]: systemd-hibernate-clear.service - Clear Stale Hibernate Storage Info skipped, unmet condition check ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67
[ 7.932054] r8169 0000:03:00.0 eth0: RTL8168h/8111h, 04:55:b2:00:28:fd, XID 541, IRQ 108
[ 8.006487] Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852
[ 8.009439] Bluetooth: hci0: RTL: rom_version status=0 version=3
[ 8.013493] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
[ 8.013498] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_fw.bin
[ 8.015408] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_config.bin
[ 8.020438] Bluetooth: hci0: Opcode 0xfcf0 failed: -16
[ 8.023494] Bluetooth: hci0: AOSP extensions version v0.96
[ 8.023502] Bluetooth: hci0: AOSP quality report is not supported
[ 8.187924] kvm_amd: [Firmware Bug]: Cannot enable x2AVIC, AVIC is unsupported
[ 8.242058] rtw89_8852be 0000:05:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
[ 8.250433] rtw89_8852be 0000:05:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 5
[ 8.250437] rtw89_8852be 0000:05:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 3
And both grep -r "b853\|8852bu\|8852b" /lib/modules/$(uname -r)/kernel/drivers/bluetooth/ 2>/dev/null and modinfo btusb | grep -A2 -i "b853\|8852" gave no output.
Apologies, but I wasn’t able to locate that particular section (“The Permanent Fix…”) in the blog. If possible, could you please provide the exact commands or configuration lines you’d like me to try? I will run them right away and share the outputs with you here. Thank you for your patience!
Your modinfo btusb | grep -A2 -i "b853\|8852" results seem to show the root cause; i.e., it appears the btusb driver in kernel 7.0.4-200.fc44.x86_64 has no entry for USB ID 0bda:b853 in its device table. The driver looks like it’s loading and attempting initialization via a generic fallback path, not a proper device-specific handler and that fallback doesn’t correctly handle the RTL8852BU’s initialization sequence, which is why 0xfcf0 fails.
We can try to verify that with:
modinfo btusb | grep -E "version|filename"
modinfo btusb | grep "0bda" | head -20
dnf list kernel
Since there have been many changes since May 13th, start by making sure Fedora and vendor firmware are fully updated.
Look for “The Complete Technical Solution” in the dredyson document. Don’t skip
“Phase 1: Windows-Side Preparation” to be sure Windows didn’t change things since you tried the proposed fix.
Before proceeding with “Phase 2”, make sure you still have /etc/systemd/system/bluetooth.service.d/debug.conf from Brian’s post.