Steam Frame: suspend unreliable: ath12k (WCN7850) firmware crashes on suspend (Wi-Fi dead until reboot), plus warm resets and hangs during suspend
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- kubernetes, linux
- Área
- networking, operating-systems
Línea de trabajo
Start by reviewing the attached sanitized kernel and userspace logs, especially the suspend failure around ath12k_pci, MHI firmware reload, and the warm reset events; compare them with the clean-boot ath12k initialization and runtime crash logs. The issue gives reproduction steps using the Steam Frame, home Wi-Fi, and USB Wireless Adapter soft AP. Done means identifying and fixing the suspend failure so Wi-Fi works after resume and the headset does not reset or hang.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Logs were collected and analysed with the help of an LLM and checked against the raw journal. Private data (MAC/BSSID, LAN IPs, Steam ID) has been removed from the attached logs.
Your system information
- Device: Steam Frame
- Steam client version:
1792099137(linux_arm64_beta) - SteamOS version:
VERSION_ID=0.4.5,VARIANT_ID=vr,BUILD_ID=20261007.6125817, kernel6.18.0-ge66bc2ca6f8c - Opted into Steam client beta?: Yes
- Opted into SteamOS beta?: Yes
- Have you checked for updates in Settings > System?: Yes. An update is available but not applied yet. I'll retest once I update.
- Wi-Fi:
ath12k_pci17cb:1107,wcn7850 hw2.0, fwWLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1(0x110a0012, built 2025-08-20),board_77.bin - Network:
wlan0on home Wi-Fi (UniFi U7 Pro, 5 GHz ch 149 / 80 MHz) and, on the samephy0, the soft APwlanapfor the USB Wireless Adapter (6 GHz ch 37 / 160 MHz,softapmanager desired_mode = HBS6)
Please describe your issue in as much detail as possible:
Expected: after sleep (short power press), the headset wakes with Wi-Fi working.
What happens: suspend is unreliable in three ways. The main one: the Wi-Fi firmware crashes while entering suspend. On resume, MHI can't reload the firmware, ath12k times out, and mac80211 drops the radio. Wi-Fi is then gone (empty network list, toggling Wi-Fi doesn't help) until a full reboot. Other times the headset doesn't wake at all and needs a long-press power-off.
Kernel log, 2026-10-28 (full log attached):
21:02:05 PM: suspend entry (deep)
ath12k_pci 0000:01:00.0: Uploading coredump
qcom_mhi_qrtr mhi0_IPCR: 21: Failed to receive RESET channel command completion
ath12k_pci 0000:01:00.0: failed to set mhi state POWER_OFF_KEEP_DEV(4) in current mhi state (0x1)
WARNING: CPU: 0 PID: 196781 at kernel/irq/manage.c:753 __enable_irq+0x54/0x90
mhi_async_power_up / ath12k_mhi_start / ath12k_pci_power_up / ath12k_core_resume_early / pci_pm_resume_early
mhi mhi0: MHI did not load AMSS, ret:-5
ath12k_pci 0000:01:00.0: failed to start mhi: -110
ath12k_pci 0000:01:00.0: failed to early resume core: -110
ath12k_pci 0000:01:00.0: failed to resume core: -110
ath12k_pci 0000:01:00.0: fail to start mac operations in pdev idx 0 ret -108
Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
WARNING: ... at net/mac80211/util.c:1818 ieee80211_reconfig+0x3e4/0x17f8
ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume returns -108
21:04:45 PM: suspend exit
wpa_supplicant: Could not set interface wlan0 flags (UP): Cannot send after transport endpoint shutdown
21:06:46 NetworkManager: device (wlan0): supplicant interface keeps failing, giving up
How often: of 13 suspends in my journal (2026-10-09 → 10-28), 7 failed:
- 2 × resumed with Wi-Fi dead, identical signature (2026-10-18 17:59 and 2026-10-28 21:02)
- 2 × reset itself during suspend. Most recently: Steam menu → Sleep at 21:16:59,
PM: suspend entry (deep)at 21:17:01, then a new boot at 21:17:16 with nobody touching the headset. The PMIC reportsPON_ON_REASON 0x40→PON: type: Warm reset,trigger: none; normal boots show0x80/PON reset seq. ramoops/pstore was empty after the reset, so the kernel logged no panic, and the reset seems to come from a watchdog or firmware below the kernel. The boot after the 2026-10-18 22:53 suspend shows the same warm reset. - 3 × never resumed: the boot's journal ends at
PM: suspend entry (deep), and recovery needed a long-press power-off (10-11, 10-13, 10-25). Nothing was logged after the hang, so I can't prove it's the same crash.
The same firmware also crashed 12 times while awake in that period (Uploading coredump, auto-recovered). Possibly related: #2831 (runtime crash, degraded after recovery). This issue is about the suspend path, where it doesn't recover.
Secondary, minor: power-button presses made while the headset is asleep or still resuming get queued. After resume steamos-powerbuttond logs skipping power button push since we are already suspending or still actively resuming, then submitting short power press to steam for the queued presses. Steam then suspends again about 3 s after waking (SuspendResume: Received suspend request ×6 → PM: suspend entry at 21:04:48). From the user's side it looks like "the headset won't turn on".
Steps for reproducing this issue:
- Connect the Steam Frame to home Wi-Fi with the USB Wireless Adapter soft AP (
wlanap) up. - Put it to sleep with a short power press, Steam menu → Sleep, or
steam -ifrunning steam://shortpowerpress. - Wait a minute or more, then wake it with a single short power press.
- Roughly half the time: Wi-Fi is dead after wake (log above), the headset warm-resets on its own a few seconds into suspend, or it doesn't wake and needs a long-press power-off.
Logs (sanitized), in this gist: https://gist.github.com/xthree/28d0838894f406338df3561c1e7d905a. Contents: kernel + userspace logs for the 2026-10-28 and 2026-10-18 failures, the 21:17 sleep → warm reset (with the PMIC reset reason, plus each boot's reset reason in the event summary), runtime crashes from 2026-10-25 with the end of a boot that never resumed, ath12k init from a clean boot, and a list of every suspend/crash event across 20 boots. I have no firmware devcoredump yet (it expired before I could collect it). I'll attach one next time.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 2.7k
- Forks
- 89
- Métricas de merge de PR
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ValveSoftware/SteamOS
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
ValveSoftware/SteamOS#3037 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
ValveSoftware/SteamOS#2983 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ValveSoftware/SteamOS#2927 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ValveSoftware/SteamOS#2875 · 1 comentario ·
-
steam-short-session-tracker: incorrect registry backup path resets settings during automatic repairAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
ValveSoftware/SteamOS#2829 ·
Todos los issues de ValveSoftware/SteamOS
Issues similares
-
[BUG] IP 质量类型误判:ISP 静态段被显示为机房Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
complexity: easy good first issue impact: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ueberdosis/hocuspocus#1211 ·
Los mantenedores suelen responder en 1 día
-
kind/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
krahabb/meross_lan#740 · 1 comentario ·
Los mantenedores suelen responder en 1 día