ValveSoftware
OLED wifi bisect
Users are reporting that the OLED wifi sleep issues are fixed when loading a clean 6.16 ath11k dkms driver.
The dkms package seems to change 3 things at the same time:
- It updates 3.7 to use the 6.16 driver (without qcom extra patches)
- It updates board-2.bin to a newer version.
- It adds a workaround to unload/reload driver across suspend/resume boundaries.
We need to narrow down which one of these changes is the one that is fixing the issue.
Users have already reported (but it would be good to confirm) the following:
- SteamOS 3.7 + the unload/reload workaround do not fix the issue
Suggested next steps:
- Test SteamOS 3.8.
- This contains the 6.16 driver in addition + a set of extra patches from the wifi driver vendor[1]
- Test SteamOS 3.8 with board-2.bin from the dkms repo.
- https://github.com/WanderingxLotus/steamdeck-oled-ath11k-dkms
- Test SteamOS 3.8 with a clean 6.16 ath11k driver.
[1]: Delta between 6.16 upstream and SteamOS 3.8 kernel:
[andres@andres-dev ~/git/linux-integration]$ git log v6.16..6.16.7-valve1 --oneline drivers/net/wireless/ath/ath11k
49e1ff062876 [FROM-ML] bus: mhi: host: don't free bhie tables during suspend/hibernation
5d99063b4380 (origin/6.16/features/wifi) [FROM-QUECTEL] Revert "ath11k: do not restore ASPM in case of single MSI vector"
b7654415f12b [FROM-QUECTEL] wifi: ath11k: add log for HE_MODE_SU_TX_BFER/HE_MODE_MU_TX_BFEE
6ebf79ce3bf7 [FROM-QUECTEL] wifi: ath11k: support to force rddm mode
05523fbaee6d [FROM-QUECTEL] wifi: ath11k: add support for unit test command
228f75a967bb [FROM-QUECTEL] wifi: ath11k: Indicate NAN support to firmware
f35e159c2df1 [FROM-QUECTEL] wifi: ath11k: remove extra warning message, move to debug
9a394fd14950 wifi: ath11k: fix group data packet drops during rekey
6fc2589aae91 wifi: ath11k: fix dest ring-buffer corruption when ring is full
eed5fcf4a3d2 wifi: ath11k: fix source ring-buffer corruption
0f708ced8975 wifi: ath11k: fix dest ring-buffer corruption
6bdef22d5402 wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
16872194c80f wifi: ath11k: clear initialized flag for deinit-ed srng lists
Test 1: SteamOS 3.8 which includes 3.8 + extra patches
To install SteamOS main run the following commands:
sudo steamos-select-branch main
sudo steamos-update
sudo reboot
Then try to repro the sleep issue. If you run into it please leave a comment and we can move on to the next test.
Test 2: Test SteamOS 3.8 with board-2.bin from the dkms repo.
Please run Test 1 first, only proceed to this one if you've already reproduced the problem in SteamOS 3.8.
sudo steamos-readonly disable
sudo rm /lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst
wget https://raw.githubusercontent.com/WanderingxLotus/steamdeck-oled-ath11k-dkms/refs/heads/main/firmware/QCA2066/board-2.bin
sudo cp board-2.bin /lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin
sudo reboot
Test 3: Test SteamOS 3.8 with a clean 6.16 ath11k driver.
Please run Test 2 first, only proceed to this one if you've already reproduced the problem with an updated board-2.bin
wget https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-neptune-616-6.16.7.wifi.test.131e20-1-x86_64.pkg.tar.zst
sudo pacman -U linux-neptune-616-6.16.7.wifi.test.131e20-1-x86_64.pkg.tar.zst
# You might see some errors when running this pacman command, that is okay. See step below on verifying install.
sudo reboot
To verify you are running the right kernel:
(deck@callisto2318 ~)$ pacman -Q | grep linux-neptune
linux-neptune-616 6.16.7.wifi.test.131e20-1
This is a variant of the 6.16.7-valve1 which uses a "clean" version of the v6.16 ath11k driver. Note that this means that we are missing the wifi fixes that landed in 6.16.7, but I wanted to match the dkms driver as closely as possible.
Following is a diff of the ath11k driver in this build vs the dkms driver: diff-vs-dkms.txt
In case anyone wants a corresponding headers package, it is available here: https://steamdeck-packages.steamos.cloud/misc/test-kernels/
Example reply:
Results on my steamdeck oled:
- Test 1: failed
- Test 2: failed
- Test 3: streaming works
Feel free to add any details you think are relevant to each bullet point.
Sounds good, will test.
It updates board-2.bin to a newer version.
I never did this as the WanderxLotus repo readme says to only do his step 'if needed' ("Step 10: Install Firmware (if needed)"), and I didn't need to. So that's some evidence this isn't causally related to the fix.
Sounds good, will test.
It updates board-2.bin to a newer version.
I never did this as the WanderxLotus repo readme says to only do his step 'if needed' ("Step 10: Install Firmware (if needed)"), and I didn't need to. So that's some evidence this isn't causally related to the fix.
Yep, I'll test it as well this evening.
Note, I updated the instructions for Test 1 above. I forgot to write in the word main in this command:
sudo steamos-select-branch main
BTW I've run into some gnarly issues when messing with the firmware files, so as a precaution instead of rm'ing files, I've been moving them off:
# Instead of sudo rm /lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst
sudo mv /lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst{,.orig}
## To restore
# sudo mv /lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst{.orig,}
I've uploaded a driver build that should match the dkms driver into the Test 3 instructions.
I've uploaded a driver build that should match the dkms driver into the Test 3 instructions.
So that's the dkms source built against the 6.16 kernel?
Have those patches always been applied on top of SteamOS builds? I'm trying to understand test 3.
So that's the dkms source built against the 6.16 kernel?
Pretty much.
The dkms source is the 6.16 driver with some changes to make it work on 6.11. The driver in the package above is the original 6.16 driver with no modifications.
Have those patches always been applied on top of SteamOS builds? I'm trying to understand test 3.
Some yes and some no.
The goal of this test is to see if we can replicate the same results as the dkms driver with the minimum set of differences possible. I'm hoping that this results in a working driver on your systems, and it gives us a good starting point for further testing.
Have we confirmed what board-2.bin actually does? It's been mentioned elsewhere that amss.bin is the actual firmware file for the chipset. @WanderingxLotus how did this file come up in your copilot-ing?
I'm currently testing 3.8 (build 20251001.1001) with only board-2.bin and after one playthrough so far, didn't encounter the issue.
Have we confirmed what board-2.bin actually does?
My understanding is that it is a configuration blob. It contains information about transmit channels for different regions, transmit power values and things like that. I'm not very well versed in the details there, but we could ask the driver vendor.
I'm currently testing 3.8 (build 20251001.1001) with only board-2.bin and after one playthrough so far, didn't encounter the issue.
Hopefully it keeps working after a couple more test attempts. Since board-2.bin controls some of the power/channel config it could definitely be related.
I'm assuming that an unmodified SteamOS 3.8 manifested the issue the problem on your unit. So this would point at board-2.bin being the issue.
I've now run a few streaming sessions, punctuated by sleep/resume, in this setup:
- after updating to SteamOS 3.8,
- without installing
board-2.bin, - without installing
linux-neptune-616-6.16.7.wifi.test.131e20-1-x86_64.pkg.tar.zst, - but with the service to unload and reload the wifi driver between resume/wake
and have not experiencing the wifi issue yet (will keep trying to see if they come back in this config). That would seem point to the reloading service itself being the solution (although I know xovsumina earlier said this wasn't their experience, but maybe there is a subtle difference in their systemd script?) or that I've just been unlucky in triggering the bug - I'll keep trying over the next few days to see if it comes back in this config.
Specifically:
(deck@steamdeck ~)$ uname -a
Linux steamdeck 6.16.7-valve1-1-neptune-616-g27c7a95f5ca5 #1 SMP PREEMPT_DYNAMIC Wed, 24 Sep 2025 02:23:51 +0000 x86_64 GNU/Linux
(130)(deck@steamdeck ~)$ cat /etc/systemd/system-sleep/reload_ath11k.sh
#!/bin/bash
case $1 in
pre)
logger "system-sleep: Unloading ath11k_pci before suspend"
modprobe -r ath11k_pci
;;
post)
logger "system-sleep: Reloading ath11k_pci after resume"
modprobe ath11k_pci
;;
esac
(130)(deck@steamdeck ~)$ modinfo ath11k
filename: /lib/modules/6.16.7-valve1-1-neptune-616-g27c7a95f5ca5/kernel/drivers/net/wireless/ath/ath11k/ath11k.ko.zst
...
(deck@steamdeck ~)$ modinfo ath11k_pci
filename: /lib/modules/6.16.7-valve1-1-neptune-616-g27c7a95f5ca5/kernel/drivers/net/wireless/ath/ath11k/ath11k_pci.ko.zst
firmware: ath11k/WCN6855/hw2.1/*
firmware: ath11k/WCN6855/hw2.0/*
firmware: ath11k/QCN9074/hw1.0/*
firmware: ath11k/QCA6390/hw2.0/*
...
I did not factory-reset from my earlier setup with SteamOS 3.7 where I ran sudo dkms install ath11k-steamos/6.16-custom, although it looks like the upgrade to SteamOS 3.8 caused the ath11k driver to revert to the in-tree one based on the modinfo output. Just wanted to point out in case it's relevant.
although it looks like the upgrade to SteamOS 3.8 caused the ath11k driver to revert to the in-tree one based
If you want to confirm that you can run:
sudo dkms status
And if necessary:
sudo dkms remove <foo>
sudo dkms status returns no output and the filename field of modinfo ath11k references the in-tree driver as opposed to a path containing updates/dkms/... , so I believe that indeed confirms the custom driver is not being used.
Yeah any time you install a full build the drivers and a lot of the system config reverts to default. What does NOT revert however are systemd services and possibly things like that sleep hook. I found some instability after going back to 3.8 but then realized one of my services was still active. It was something that tried to detect degradation and then reload the ath11k modules.
Test results, will edit in place
- Test: 3.8 w/ board-2.bin - FAIL
- Test: 3.8 w/ 6.16 "clean" module (no patches) - FAIL
Hi folks. Thanks for assisting testing for this issue. As of yet, we have been unable to repro locally, so we really appreciate the help testing.
I put together 3 test kernels and 2 test firmware packages:
kernels: https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-neptune-616-6.16.7.valve1.t1-1-x86_64.pkg.tar.zst https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-neptune-616-6.16.7.valve1.t2-1-x86_64.pkg.tar.zst https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-neptune-616-6.16.7.valve1.t3-1-x86_64.pkg.tar.zst
firmware: https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-firmware-neptune-jupiter.20250731.1.t1-2-any.pkg.tar.zst https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-firmware-neptune-jupiter.20250731.1.t2-2-any.pkg.tar.zst
We would like to see if any of those changes help the situation. Each one should be tested in isolation to avoid any cross-contamination of test files. For each one, please do the install and test, then revert back to stock files and confirm before trying the next.
Getting results for each scenario kernel-t1, kernel-t2, kernel-t3, firmware-t1 and firmware-t2 will be very helpful. In the meantime, I'll try further to repro locally.
to install a kernel:
$ mkdir tmp && cd tmp
$ wget https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-neptune-616-6.16.7.valve1.t1-1-x86_64.pkg.tar.zst
$ sudo pacman -U ./linux-neptune-616-6.16.7.valve1.t1-1-x86_64.pkg.tar.zst
(reboot the device)
confirm after reboot with:
$ uname -r
6.16.7-valve1-t1-1-neptune-616-gf664e812cb14
(test whether it helped)
to restore the default kernel:
$ sudo pacman -Sy linux-neptune-616
(reboot the device)
confirm after reboot:
$ uname -r
6.16.7-valve1-1-neptune-616-g27c7a95f5ca5
to install a firmware test:
confirm the original file hashes:
$ md5sum /usr/lib/firmware/ath11k/QCA2066/hw2.1/{amss.bin.zst,board-2.bin.zst}
f343d15142e1486fb917734c5cb1c6d5 /usr/lib/firmware/ath11k/QCA2066/hw2.1/amss.bin.zst
37cf24ea5be05537e03a21a4323fd4dc /usr/lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst
install the firmware test:
$ cd tmp
$ wget https://steamdeck-packages.steamos.cloud/misc/test-kernels/linux-firmware-neptune-jupiter.20250731.1.t1-2-any.pkg.tar.zst
$ sudo pacman -U ./linux-firmware-neptune-jupiter.20250731.1.t1-2-any.pkg.tar.zst
confirm that the files changed (board-2.bin.zst changed in this case):
$ md5sum /usr/lib/firmware/ath11k/QCA2066/hw2.1/{amss.bin.zst,board-2.bin.zst}
f343d15142e1486fb917734c5cb1c6d5 /usr/lib/firmware/ath11k/QCA2066/hw2.1/amss.bin.zst
9fafd72fc76725cf03d42dde43bcacf1 /usr/lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst
(reboot the device) (test whether it helped)
to restore the original firmware files:
$ sudo pacman -Sy linux-firmware-neptune
confirm the restored firmware files:
$ md5sum /usr/lib/firmware/ath11k/QCA2066/hw2.1/{amss.bin.zst,board-2.bin.zst}
f343d15142e1486fb917734c5cb1c6d5 /usr/lib/firmware/ath11k/QCA2066/hw2.1/amss.bin.zst
37cf24ea5be05537e03a21a4323fd4dc /usr/lib/firmware/ath11k/QCA2066/hw2.1/board-2.bin.zst
NOTE: throughout these instructions, you will likely see some errors like:
==> ERROR: binary not found: 'plymouth'
...
error: command failed to execute correctly
ignore these. They are unrelated to this and are benign.
Again. Thanks a lot for the assist!
Thanks Bob for the continued attention to this issue.
After a few more streaming tests, I'm still in the situation I described in https://github.com/ValveSoftware/SteamOS/issues/2147#issuecomment-3363637835, where I can't reproduce the wifi issue in stock SteamOS 3.8 with stock firmware if I enable a systemd service that unloads the ath11k driver before sleep (modprobe -r ath11k_pci) and re-loads it after wake.
I'll try disabling that service to hopefully re-trigger the bug and then I can try out these scenarios.
After a few more streaming tests, I'm still in the situation I described in #2147 (comment), where I can't reproduce the wifi issue in stock SteamOS 3.8 with stock firmware if I enable a systemd service that unloads the ath11k driver before sleep (
modprobe -r ath11k_pci) and re-loads it after wake.
Okay, good to know. While this might be a temp work around, we probably can't roll that out as a fix due to the time to reconnect after S3 overhead that it will introduce on everyone who doesn't experience this issue. If a reload of the driver around S3 is ultimately required, it will likely take time to root cause the differences between the S3 and full reload at the hw/fw level. But, let's wait until more results are in before drawing any conclusions on that, we might get lucky yet with the tests.
Bob, if it helps, one of the things I noted to Rolando and team when they were over was that I seem to have a harder time reproducing the error if I have something plugged in (AC or a USB keyboard) or sometimes if I have a console open in the background in game mode (e.g. one of the ctrl+alt+F4 consoles).
I have one spot in my house where I can reproduce the issue consistently. If I toggle wifi, the issue doesn't occur again, leading me to think that it's not just poor signal quality. I repro'd the issues on 3.8 with the noted changes. I confirmed failure after toggling wifi and seeing that the issue didn't reoccur after at least the initial time it took the issue to come up (e.g. 5 mins of initial play before issue occurs, toggle wifi, play for another 5 mins). In some sessions last night I played for even longer.
I find that the content of the stream might also contribute, ie, graphics intensive games like Cyberpunk 2077, requiring more bytes over the stream will likely trigger it over say Minecraft.
I'll start testing these separate builds later today.
I'll update this comment as I test the scenarios. It's slow-going since given how stochastic the wifi issue is, it takes a fair amount of streaming sessions to feel confident if it's resolved.
Scenario: SteamOS 3.8, stock kernel, stock firmware Outcome: ❌ Wifi issue reproduced
Scenario: Test kernel 1, stock firmware Outcome: ❌ Wifi issue reproduced Notes: It took 7 streaming sessions to see the issue, which is larger than usual. Unclear if this was chance or the test kernel actually reduced the frequency.
Scenario:: Test kernel 2 Outcome: ❌ Wifi issue reproduced Notes: Only took three sessions, so this is no better than stock
Scenario: Test Kernel 3 Outcome: ❌ Failed Notes: The failure mode seemed a different here. The wifi slowdown would occur, then repair itself after 10 seconds without me having to toggle the wifi, but then would occur again after a few minutes and so on.
Replying to https://github.com/ValveSoftware/SteamOS/issues/2147#issuecomment-3366565411
I jumped straight to these tests while the others try what lostgoat has. I'm 7 hours in on the first kernal and haven't had any drops. I removed ally services and custom driver.
@WanderingxLotus Not sure how you're testing, but it seems for most of us the issue presents after about 5 minutes after starting a streaming session when waking the Deck from sleep (ie not from a reboot) and it doesn't present within that time, it never does for the rest of the session. So '7 hours' is perhaps less meaningful than the number of independent streaming sessions.
@WanderingxLotus Not sure how you're testing, but it seems for most of us the issue presents after about 5 minutes after starting a streaming session when waking the Deck from sleep (ie not from a reboot) and it doesn't present within that time, it never does for the rest of the session. So '7 hours' is perhaps less meaningful than the number of independent streaming sessions.
That's fair. A better description is I ran my streaming session on/off with about 16 sleep/wake cycles. I'm going to be repeating this tonight.
Will update over time
Kernal t1: fail Kernal t2: fail Kernal t3: fail
Firmware 1: fail Firmware 2: testing
Hmm, if all these fail, that would seem to leave open only a few possibilities:
- https://github.com/WanderingxLotus/steamdeck-oled-ath11k-dkms/commit/0eee58ca2db571c0e3ab1ee9f111159a9d8c5f1b introduces some important functional change besides just backporting that isn't in any of the test kernels
- Somehow installing the driver via DKMS instead of having it in-tree inexplicably makes a difference
- Fixing the issue of the deck rebooting on wake when using https://github.com/WanderingxLotus/steamdeck-oled-ath11k-dkms by unloading the driver before sleep and loading it after wake is actually the 'fix' and the modified driver is just a red herring
- We've been lucky in our testing of https://github.com/WanderingxLotus/steamdeck-oled-ath11k-dkms so far and it would actually fail if tried more
- SteamOS 3.8 actually introduces some kind of regression such that 3.7 with the backported ath11k driver works but 3.8 with the non-backported driver doesn't