[Steam Frame] WCN7850/ath12k: Wi-Fi uplink collapses under simultaneous receive (the streaming workload) while a same-AP client does not, breaking Remote Play

Abierto
  • ¿Algo no está bien?
#3,060 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
linux
Área
networking, operating-systems

Línea de trabajo

Start with the linked reproduction scripts, repro/bidir.sh and repro/read-ath12k-fw-stats.sh, and compare the Steam Frame measurements with the control laptop on the same AP and wired host. The issue points to ath12k firmware behavior but says the relevant firmware code is unavailable for inspection. Done would require identifying a firmware or driver change that prevents the uplink collapse during simultaneous receive and verifying it with the reproduction.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Your system information
  • Steam client version: public beta branch linux_arm64_publicbeta, BuildId 20261022
  • SteamOS version: SteamOS 0.5.7 (BUILD_ID 20261103.6153824, variant vr), Steam Frame; kernel 7.2.0-g9a8c8ea46950 (aarch64)
  • Opted into Steam client beta?: Yes (linux_arm64_publicbeta)
  • Opted into SteamOS beta?: Yes (branch beta)
  • Have you checked for updates in Settings > System?: Yes

Hardware: Steam Frame. Wi-Fi: Qualcomm WCN7850 (FastConnect 7800) [17cb:1107], ath12k driver, firmware WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 (fw_version 0x110a0012, built 2025-08-20).

Please describe your issue in as much detail as possible:

Each direction of Wi-Fi is fine on its own. Uplink alone runs 40 to 145 Mbit/s, downlink alone about 90. Run them together and the uplink falls apart. That is the streaming case exactly: video coming down to the headset while it sends input, audio and ACKs back up. When the up path dies, the host's bandwidth estimate drops and it throttles the video, which is the stutter.

Here is the control that convinced me it is the headset and not my network. Same AP, same wired target, same tool, one right after the other:

client uplink (concurrent) downlink (concurrent) uplink solo
control laptop (MacBook) 806 Mbit/s 150 Mbit/s 726
Steam Frame 3.8 Mbit/s 60 Mbit/s ~133

The laptop pushes ~950 Mbit/s both ways at once and never stumbles. The Frame, on the same AP to the same wired PC with the same tool, drops its uplink to 3.8 Mbit/s the instant it also has to receive. So this is the Frame's radio, not the router, the path, or how I measured it. It reads like a transmit-vs-receive arbitration problem in the WCN7850: the TX path loses to RX when both are live.

I checked the obvious alternatives, each with a measurement:

  • Router / path / method: the laptop is fine on the identical setup, so none of these.
  • Rate control: iw dev wlan0 set bitrates is rejected, so the rate is firmware-owned, not something I can pin.
  • The hardware TX scheduler (HWSCH): hwsch_reset_count does not move during the collapse, and hwsch_misaligned_offset_received keeps climbing even during a healthy 140 Mbit/s transmit, so that counter is noise, not the fault.
  • A firmware crash: none this boot. No coredump, no MHI reset, no time out while waiting for fw stats done.
  • Driver TX errors: zero over 30 hours, including with full DP_TX debug on.
  • Signal, channel, thermal, PCIe, power save, Bluetooth coexistence, scanning, ASPM: all measured, none of them.

I put everything in a repo: the per-second numbers, a one-command reproduction, and a ready-to-send Qualcomm ticket. https://github.com/theTechGoose/steamframe-wcn7850-tx-stall

This looks related to #2831 (same chip, same firmware build), which is a crash-then-degrade variant on 6 GHz / 160 MHz. The difference here is that it reproduces on demand with no crash, which should make it easier to work with.

I did try to find the exact spot in the firmware, the way the recent Steam Frame wake-on-LAN issue was tracked down. Static analysis cannot reach it this time. amss.bin is paged (dlpager) and patches on-chip ROM, and it logs through QSHRINK message IDs rather than string pointers, so the transmit and scheduler code is not plaintext in the image and nothing in the file references the diagnostic strings. Pinning the actual instruction needs the ROM and the QSHRINK database, which only Qualcomm has.

So the questions that would move this are really for them:

  • Is this a known issue on this WCN7850 firmware line, where transmit starves while receive is active?
  • Is there a newer firmware image I can try on the Frame?
  • Is there a driver-side setting I could toggle to narrow it down without a firmware change? I am thinking HE/EHT feature bits, UL OFDMA or MU, aggregation, MU-EDCA, or RTS/CTS.

The headset is set up for testing with a saved baseline per configuration, so I can turn things around quickly. Send me a firmware image or a driver patch and I will run it. I can also grab whatever's useful on the way: htt_stats dumps, a coredump (CONFIG_ATH12K_COREDUMP=y is already set), trace-cmd, or a capture from the AP.

Steps for reproducing this issue:
  1. Put the Steam Frame and a healthy control laptop on the same 5 GHz AP, and pick a wired host on the same LAN as the target.
  2. For the Frame, measure uplink alone, downlink alone, then both at once (repro/bidir.sh in the repo runs all three). Uplink alone is 40 to 145 Mbit/s; both at once, the uplink drops to single digits.
  3. Repeat with the laptop as the client. It holds both directions (about 806 up and 150 down at the same time).
  4. On the Frame as root, repro/read-ath12k-fw-stats.sh shows hwsch_reset_count sitting still through the collapse, which is what rules out the hardware scheduler.
Lenguaje dominante
Sin datos de lenguaje
Estrellas
2.7k
Forks
89
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ValveSoftware/SteamOS

Todos los issues de ValveSoftware/SteamOS

Issues similares

Más issues de Networking

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.