Hi, my WiFi connection comes to a halt when connecting Bluetooth earbuds. I think I have isolated this to a recent firmware upgrade. Fedora 38 ISO as it comes from their website is NOT affected: https://download.fedoraproject.org/pub/fedora/linux/releases/38/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-38-1.6.iso But the issue will appear as soon as you update it after installing. I think it comes from the linux-firmware package: 20230625-151.fc38 -> bad 20230310-148.fc38 -> good The firmware file loaded after I install the "bad" version is iwlwifi-cc-a0-77.ucode. The one that is loaded with a fresh install (which works fine) is instead iwlwifi-cc-a0-72.ucode I have verified that the issue disappears if I manually delete from /lib/firmware all the versions > 72. This forces the module to load 72 after some warnings: [ 11.314297] iwlwifi 0000:a5:00.0: enabling device (0000 -> 0002) [ 11.423642] iwlwifi 0000:a5:00.0: Detected crf-id 0x3617, cnv-id 0x100530 wfpm id 0x80000000 [ 11.423769] iwlwifi 0000:a5:00.0: PCI dev 2723/1653, rev=0x340, rfid=0x10a100 [ 11.429182] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-78.ucode failed with error -2 [ 11.429218] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-77.ucode failed with error -2 [ 11.429249] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-76.ucode failed with error -2 [ 11.429280] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-75.ucode failed with error -2 [ 11.429308] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-74.ucode failed with error -2 [ 11.429336] iwlwifi 0000:a5:00.0: Direct firmware load for iwlwifi-cc-a0-73.ucode failed with error -2 [ 11.481473] iwlwifi 0000:a5:00.0: api flags index 2 larger than supported by driver [ 11.481491] iwlwifi 0000:a5:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 [ 11.481739] iwlwifi 0000:a5:00.0: loaded firmware version 72.daa05125.0 cc-a0-72.ucode op_mode iwlmvm [ 11.638529] iwlwifi 0000:a5:00.0: Detected Killer(R) Wi-Fi 6 AX1650w 160MHz Wireless Network Adapter (200D2W), REV=0x340 [ 11.784665] iwlwifi 0000:a5:00.0: Detected RF HR B3, rfid=0x10a100 [ 11.855502] iwlwifi 0000:a5:00.0: base HW address: 7c:21:4a:7f:db:04 [ 11.872226] iwlwifi 0000:a5:00.0 wlp165s0: renamed from wlan0 [ 12.536486] iwlwifi 0000:a5:00.0: Registered PHC clock: iwlwifi-PTP, with index: 0 As for the issue itself, I hope it's easy to reproduce. Here's how I do it: 1) While connected on WiFi, pair+connect a pair of BT earbuds (I use fedora 38 out of the box, so pipewire by default, not that I think it matters, but still). Audio codec is AAC, but again I think it doesn't matter, as I can also reproduce with mSBC or by putting the earbuds in handsfree mode. 2) Stream a network intensive video. I use a 4k sample video from youtube. My Internet connection is kind of weak (40-50 Mbps), and I am a bit far away from my router, but with the "good" firmware I can still comfortably stream at 1440p. 3) Enable stats for nerds (yt video context menu) and check buffer health and bandwidth Expected behavior: - bandwidth stays high, buffer health never gets to 0 Actual behavior: - bandwidth starts taking a dive as soon as you connect the earbuds, buffer quickly runs out and the video is stuck loading. Quality automatically scales down as a consequence, and even 240p becomes painful to buffer Extra info: this is unrelated to bt coex, as it happens also when connected to the 5Ghz band (plus, I haven't changed that mod param between the two firmware versions) I can confirm that reverting to firmware version 72 solves the problem. I couldn't find a clean way to do it, so I just deleted versions > 72
Following additional testing, I can confirm that version 73 of the firmware is also ok: loaded firmware version 73.35c0a2c6.0 cc-a0-73.ucode op_mode iwlmvm Versions 74, 76, 77 are bugged.
The problem might be in the firmware, but it also might be in the kernel, as different code patch are used depending on the firmware in use. Could you perform a bisection?
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #2) > The problem might be in the firmware, but it also might be in the kernel, as > different code patch are used depending on the firmware in use. Could you > perform a bisection? Hi Thorsten, thanks for your reply. As a recap (for future reference) here's what I have established so far with my testing: kernel 6.2.9 (fedora 38 fresh install) && firmware 72 -> ok kernel 6.4.4 && firmware 72 or 73 -> ok kernel 6.4.4 && firmware 74, 76, 77 -> ko If my understanding is correct (please correct me if not), I could "pin" the firmware version to 77 (or 76, or 74), and then bisect the kernel versions interval and test. If any of those tests provides the correct behavior, it means the firmware is not intrinsically bugged, and the regression is rather in the kernel. If they all fail, the issue is confirmed to come from the firmware. Since I'm a bit new to this, is there a smart way you'd recommend to run these tests in an efficient way? I was thinking of a separate installation for this purpose, and having some roll-back capability like Timeshift. Then use the package manager to install different kernel versions. As for the firmware files, is it enough to place/remove the ucode file for my adapter inside the /lib/firmware? Thanks!
Before going any further, please check if the same problem happens with 6.5-rc (and maybe the latest 6.4.y release as well); you seem to use Fedora, you can get them in these coprs: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
Strangely enough, I could no longer reproduce after following the same update path that showed the issue in the first place (i.e. updating via dnf a fresh install of fedora 38). I had the same issue on an opensuse Tumbleweed before that (which was I why I installed Fedora, for the sake of comparison), and now the issue is unreproducible in opensuse as well. I don't know what happened. Now all I can see is a slight drop in the internet connection speed as reported by Youtube's stats for nerds, from ~28Mbps to ~22Mbps when my earbuds are connected. Which I guess may be reasonable, given the extra audio streaming the card has to handle. I will therefore close this issue. I will keep an eye on this aspect and will report back if it happens again consistently. Meanwhile thanks Thorsten, and have a great day!
(In reply to Andrea Ippolito from comment #5) > Strangely enough, I could no longer reproduce […] Happens, thx for letting us know! > Meanwhile thanks Thorsten, and have a great day! yw & you, too!
A few months later I'm reopening this. I have kept fighting for this issue almost since after closing it as unreproducible, hoping each time a kernel update came out, that the issue would magically solve itself. Unfortunately, that didn't happen (I'm now on 6.5.6-1-default with opensuse Tumbleweed). I have reached the point where, after each system update that includes iwlwifi updates, I have to manually delete post-update these two firmware files: iwlwifi-cc-a0-74.ucode iwlwifi-cc-a0-77.ucode from /lib/firmware And everything goes back to normal. Please forgive me for lacking the time and experience with regression testing these super low-level bits of Linux, but there it is, the problem is real (at least for me). I'm reopening this in the hope that someone more experienced than me can somehow help move the investigation forward. I will keep a close eye on my e-mails in case more info (which I am able to provide) should be required. Something I initially hadn't mentioned, my router is a Tp-Link Archer C80 (WiFi 5, AC1900). I could also try and reproduce while connected to my smartphone's hotspot, if that can help. I know it's not much inf, but I hope that someone more experienced can find it actionable. Thanks and have a good one
I have kept fighting --for-- *WITH* this issue