Steam Frame adapter holo-realtek-firmware-toggles 1.4-1: set-low-latency-mode fails, resolves two interface names

先阅读第 187 行附近的辅助程序 holo-realtek-firmware-toggles，并追踪它如何从 debugfs 的 netdev:* 条目中推导出 WLAN_NAME。使用 p2p-dev-wlan0 和 wlan0 的条目检查结果，然后运行该辅助程序的相关测试，或使用列出的 debugfs 路径复现查找过程。查找选出一个可用接口，且 set-low-latency-mode 不再因收到两个名称而失败，即为完成。

Investigation and write-up by Sonnet 5.5 (an AI model), working on the machine's owner's behalf. Everything below was observed on the owner's machine; claims that were not verified are listed under "Not verified".

Summary

With the Steam Frame Wireless Adapter plugged in, holo-realtek-firmware-toggles (1.4-1) fails on every call because it resolves two interface names instead of one. Steam calls the helper repeatedly (about 3 times per second) with no backoff, so the journal fills with pkexec entries. The 1.3-3 expression yields a single name with the same debugfs listing (by accident, see below); the 1.4-1 expression does not. Sonnet 5.5 evaluated both expressions but did not run the 1.3-3 script end to end.

Environment

• SteamOS 3.9.5, build 20261023.100, stable channel (holo-3.9 repo)
• Kernel 7.2.7-valve2-2-neptune-72
• Desktop (AMD Ryzen AI Max 300 Series), gamescope session
• Package: holo-realtek-firmware-toggles 1.4-1 (built 2026-10-14)
• Adapter: Steam Frame Wireless Adapter, USB 28de:2432 (rtw89_8852cu), appears as phy2 / wlan0
• wlan0 state at the time: "disconnected" (NetworkManager profile "Steam Frame Wireless Adapter" failing activation every ~60 s)

What happens

$ sudo /usr/bin/holo-polkit-helpers/holo-realtek-firmware-toggles set-low-latency-mode off
command failed: No such device (-19)
ERROR at .../holo-realtek-firmware-toggles:259
ERROR at .../holo-realtek-firmware-toggles:320
ERROR at .../holo-realtek-firmware-toggles:209
exit: 1

Traced with bash -x:

+ PHY_NAME=phy2
+++ compgen -G '/sys/kernel/debug/ieee80211/phy2/netdev:*'
+ WLAN_NAME=$'p2p-dev-wlan0\nwlan0'
command failed: No such device (-19)

WLAN_NAME is two lines, so iw dev "${WLAN_NAME}" set power_save ... fails.

Meanwhile the Steam client keeps invoking the helper (set-low-latency-mode off) about 95 times per 30 seconds, every call failing the same way. The loop began in the same second that the Steam client (pid 2232) requested a disconnect of wlan0 (NetworkManager: device-disconnect interface=wlan0 ... pid=2232, reason 'user-requested'). wlan0 is the Frame adapter's own link to the headset (it held a 10.35.x address, not the LAN's); the host's LAN connection is wired Ethernet. The loop is still running after a Steam restart. This correlation was observed in the journal; it has not been established that the disconnect causes the loop.

Root cause

debugfs lists both interfaces:

/sys/kernel/debug/ieee80211/phy2/netdev:p2p-dev-wlan0
/sys/kernel/debug/ieee80211/phy2/netdev:wlan0

1.4-1 line 187 tries to exclude the p2p one:

WLAN_NAME="$(basename "$(compgen -G "$(dirname "${DEBUGFS_DIR}")/netdev:*" | grep -E -v -- '(^|-)p2p(-|$)' | cut -d: -f2-)" )"

The grep runs on the full path, where p2p is preceded by : (not start-of-line or -), so nothing is excluded. This was checked per line: both entries are kept.

Why 1.3-3 worked: its line was

WLAN_NAME="$(basename "$(compgen -G "$(dirname "${DEBUGFS_DIR}" )/netdev:*")" | cut -d: -f2-)"

basename of the two-line string returned only the last path component (netdev:wlan0), so cut left wlan0. That depended on wlan0 sorting after p2p-dev-wlan0. The 1.3-3 -> 1.4-1 diff moved cut inside basename, which removed that accidental behaviour. The only other change in the diff is set-aggressive-edca on being commented out.

Result with the same debugfs listing:

• 1.3-3 expression: wlan0
• 1.4-1 expression: p2p-dev-wlan0 + newline + wlan0

Suggested fix

Strip the path prefix first, then filter, and take one name:

compgen -G "$(dirname "${DEBUGFS_DIR}")/netdev:*" | sed 's|.*/netdev:||' | grep -Ev '^p2p-' | head -n1

On this machine that prints wlan0.

Second problem (Steam client)

When the helper exits non-zero, Steam retries immediately and indefinitely. A retry delay or a stop after a few failures would avoid the journal spam (about 95 pkexec sessions per 30 seconds).

Not verified

• The suggested fix was not applied to the helper. The expression was tested read-only.
• It is not known whether the helper's later steps (iw set bitrates etc.) are safe on this kernel once the interface name resolves. Related reports on the SteamVR-for-Linux tracker mention an rtw89 oops from iw set bitrates on an unassociated adapter (7.x kernels): see ValveSoftware/SteamVR-for-Linux#946.
• ValveSoftware/SteamOS was searched for an existing report and none was found for this failure. The search tool is not exhaustive.

Related

• ValveSoftware/steam-for-linux#13643 (Steam retries the adapter link every 60 s)
• ValveSoftware/SteamVR-for-Linux#965, #946 (adapter and low-latency helper discussion)