[Steam Frame] Hard power-off at 47-62% battery under sustained ~2.8 A load; BCL counter climbs for minutes beforehand, no warning

Abierto
#3,040 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
linux

Línea de trabajo

Start by reviewing the reported deckard_charge_daemon journal lines and the qcom-bcl-hwmon thresholds mentioned in the issue. Reproduce with a sustained 2.6–3.0 A load and monitor the battery current, BCL counter, and shutdown behavior. Done means identifying why the headset powers off with substantial charge remaining and whether a warning or load response is feasible.

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

Descripción

Your system information
  • Steam client version: Steam Frame stable client as of 2026-11-04
  • SteamOS version: Steam Frame build 20261022.6150929 (no OS update pending when checked on 2026-11-04)
  • Opted into Steam client beta?: No
  • Opted into SteamOS beta?: No
  • Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:

Expected: under a sustained heavy load the headset keeps running until the battery is actually low, and warns before it shuts down.

Actual: the headset powers off abruptly, with no warning and no orderly shutdown, while the fuel gauge still reports 47-62 %. In both cases the battery was discharging at about 2.6-3.0 A. For several minutes before each power-off, the BCL counter in the deckard_charge_daemon log climbed by hundreds of thousands every 20 s. In sessions with lighter load (~1.2-1.3 A), the counter stays at 0 and the headset runs normally down to 20 %.

The load is a PC VR streaming client: an OpenXR app doing hardware HEVC decode at about 1440x1440 per eye and 120-144 Hz, plus the compositor. The same kind of load that any SteamVR streaming session puts on the device.

Battery: max1720x reports cycle_count=33, charge_full=2454000 vs charge_full_design=2730000 (90 %), health=Good.

What the journal shows. For both power-offs the journal just stops: no shutdown target, no logind or poweroff messages. The next boot starts about a minute later.

Boot ended SOC at end Battery current BCL counter (first value in BCL(1): [...]) How it ended
2026-10-30 13:15 62 % -2.6 to -2.9 A 0x0002d784 at 71 % -> 0x000cf1a6 at 62 %, rising steeply in the last 2 min journal stops (hard power-off)
2026-10-31 09:50 47 % -2.7 to -3.0 A 0x0004eaf8 at 69 % -> 0x003bd7c9 at 49 %, +200k to +500k per 20 s journal stops (hard power-off)
2026-11-02 (long session) down to 20 % -1.2 to -1.3 A 0 throughout normal
2026-11-03, 2026-11-04 99-100 % 0 orderly shutdown by the user

Last minutes before the 2026-10-31 power-off (journalctl -b -3 -t deckard_charge_daemon, FG and BCL lines only):

09:46:07 FG INT - V: 7.567;            Cur: -2.80;             SOC:  55 %
09:46:07 BCL(1): l0=2975 l1=2975 [0021cdf1 00000000 00000000]
09:46:27 FG INT - V: 7.554;            Cur: -2.80;             SOC:  54 %
09:46:27 BCL(1): l0=2975 l1=2975 [002832d8 00000000 00000000]
09:47:07 FG INT - V: 7.529;            Cur: -2.86;             SOC:  53 %
09:47:07 BCL(1): l0=2900 l1=2900 [0029a299 00000000 00000000]
09:48:07 FG INT - V: 7.502;            Cur: -2.99;             SOC:  51 %
09:48:07 BCL(1): l0=2950 l1=2950 [002d0c19 00000000 00000000]
09:48:27 FG INT - V: 7.490;            Cur: -2.87;             SOC:  50 %
09:48:27 BCL(1): l0=2900 l1=2900 [00345349 00000000 00000000]
09:48:47 FG INT - V: 7.479;            Cur: -2.97;             SOC:  49 %
09:48:47 BCL(1): l0=2925 l1=2925 [003bd7c9 00000000 00000000]
09:49:48 FG INT - V: 7.455;            Cur: -2.86;             SOC:  47 %
09:49:48 BCL(1): l0=2800 l1=2775 [003bd7c9 00000000 00000000]
# journal ends at 09:50:04; next boot 09:51:11

For comparison, the 2026-11-02 session at about 1.25 A stayed at [00000000 ...] from 99 % down to 20 % (e.g. 17:48:13 ... SOC: 20 %, BCL(1): ... [00000000 00000000 00000000]).

Observations

  • The pack voltage reported by the gauge is still 7.45-7.75 V (about 3.73-3.88 V per cell) when the BCL counter starts climbing. That is well above voltage_min_design (6.6 V). So the trips look like transient sag under load peaks, not a depleted battery.
  • l0/l1 (as I understand it, the BCL thresholds the daemon programs; they match in0_min/in0_lcrit of the qcom-bcl-hwmon sensor) go down with SOC: 3600 at full, 2775-2950 around 50 %. The counter climbs regardless.
  • On this unit, under a sustained ~2.8 A load, the usable range ends at around 50-70 % SOC instead of near 0 %. SteamOS shows no low-battery warning before the cut-off, because the percentage is still high.
  • A Steam Community user reports a similar symptom: the Frame shut off "like it was dead" at 75 % right after startup, and was fine on an external battery. That points to the same kind of load-dependent cut-off.

Questions / requests

  1. Is a hard power-off at this SOC and current expected for this battery, or does it point to a cell or BCL configuration problem on this unit?
  2. If BCL is about to escalate to a shutdown, could SteamOS warn the user, or throttle harder, before the headset dies? Right now there is no warning.
  3. Could the BCL counters (or a "power limited" state) be exposed to unprivileged apps? Today they are only visible in the daemon log and debugfs, so apps cannot warn the user or reduce their own load.
Steps for reproducing this issue:
  1. Charge to 100 %, unplug.
  2. Run a sustained heavy load that keeps the battery current around 2.6-3.0 A (PC VR streaming at 120-144 Hz is enough).
  3. Watch journalctl -f -t deckard_charge_daemon. Around 70 % SOC the first value in BCL(1): [...] starts climbing every 20 s. Within roughly 5-15 minutes the headset powers off with 45-65 % left.
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

  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 Operating Systems

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.