Resolviendo un misterioso problema de batería en las laptops Endless

En junio de 2022, una comunidad de mujeres emprendedoras de bajos recursos en Estados Unidos fue invitada a participar en un programa innovador de financiamiento para obtener su primera computadora personal bajo el plan Endless Laptop. Asistieron a un evento local, hicieron un pequeño pago inicial y se llevaron a casa una computadora poderosa llena de herramientas y contenido, lista para impulsar sus negocios y apoyar la educación de sus familias.

Nuestro programa de acceso a dispositivos finalmente estaba en marcha, llegando a hogares que nunca antes habían tenido una PC. Pronto, la iniciativa se extendió a comunidades desfavorecidas en Guatemala y México, pero a medida que la base de usuarios crecía, surgió un problema importante: la batería se agotaba rápidamente cuando la computadora entraba en modo de suspensión.

En este artículo quiero compartir la historia de cómo el equipo técnico de la Fundación Endless OS persiguió sin descanso este problema a través de múltiples giros técnicos, hasta identificar la causa en el lugar menos esperado: un controlador defectuoso de un tipo de disco… que ni siquiera estaba presente en el equipo.

Por la complejidad del tema, esta historia incluye cierta jerga técnica, pero espero que sea accesible para quienes tienen aunque sea un interés básico en la arquitectura de sistemas y computadoras.

Resolver el drenaje de batería… ¿por casualidad?

Nos dimos cuenta del problema de batería al mismo tiempo que nuestro laboratorio en Taipéi estaba depurando otro fallo de gestión de energía en una versión más nueva del mismo modelo. Ese equipo, considerado como sucesor, no podía entrar en suspensión correctamente: al reactivarse, perdía acceso al disco.

Nuestro sistema operativo, Endless OS, se basa en software de código abierto (Linux), lo que nos permite aprovechar la colaboración de una amplia comunidad global de desarrolladores. En el debate técnico sobre este fallo, probamos y aprobamos una solución temporal que hacía que ambos modelos usaran una implementación más antigua del modo de suspensión.

Además de permitir que el nuevo modelo durmiera y despertara sin problemas, este cambio redujo drásticamente el consumo de energía en el modelo original que ya estaba en manos de los usuarios. Por casualidad, habíamos resuelto el problema de consumo. Pensamos: “¡Qué conveniente!”, y distribuimos la actualización rápidamente.

Fallos al despertar del modo suspensión

El problema reapareció cuando empezamos a recibir reportes de usuarios indicando que, ocasionalmente, la laptop se quedaba congelada en modo suspensión y no respondía al intentar despertarla. Fue difícil reproducir el fallo, pero finalmente logramos hacerlo y entenderlo en detalle.

La solución que habíamos implementado forzaba a los sistemas a usar el modo de suspensión S3 (legacy suspend), una versión antigua en la que el firmware controla totalmente el hardware durante el reposo. Como el fallo ocurría allí, quedó claro que el problema estaba a nivel de firmware, fuera del alcance del sistema operativo.

Esto no era del todo sorprendente: el producto no estaba diseñado para usar S3, probablemente ni siquiera se probó ese modo. Por tanto, aunque al principio el cambio pareció una solución de suerte, resultó ser poco confiable y tuvimos que abandonarlo para entender el problema original con mayor profundidad.

Teníamos dos preguntas:

1. ¿Por qué el modelo más nuevo no podía acceder al disco después de despertarse?
2. ¿Por qué el modelo original consumía tanta energía durante la suspensión?

Intel Volume Management – error de acceso al disco

Al comparar los dos modelos descubrimos que el problema de acceso al disco tras el despertar se debía a una configuración distinta.

El modelo original usaba Intel VMD (Volume Management Device), una función de gestión de almacenamiento avanzada, poco relevante para nuestro caso doméstico. El modelo nuevo tenía los discos configurados sin VMD, y era precisamente esa versión la que perdía el acceso al disco al despertar.

Analizamos y descubrimos que Linux apagaba completamente el disco en ese modo sin VMD, lo que tiene sentido para ahorrar energía. Pero luego no lograba volver a encenderlo. Al usar herramientas de depuración avanzada, observamos que Windows no apagaba el disco durante la suspensión.

No sabemos exactamente por qué, pero ajustamos el comportamiento de Linux para mantener la alimentación del disco como hacía Windows. El problema desapareció, esta vez con un entendimiento técnico mucho más preciso.

Modern Standby: entendiendo el consumo de energía

Ahora ambos modelos podían dormir y despertar correctamente, sin usar el modo S3 heredado. Era momento de volver a la pregunta inicial: ¿por qué el sistema consumía tanta energía al dormir?

Este producto usa un diseño Modern Standby, donde el procesador central y el sistema operativo permanecen técnicamente activos, aunque casi todo el hardware (pantalla, Wi-Fi, disco, etc.) se apaga y el procesador entra en un modo de bajo consumo extremo. En teoría, esto permite que el equipo “duerma” durante días.

Pero en nuestro caso, la batería se agotaba en pocas horas.

Activamos herramientas internas del procesador Intel para identificar qué partes del sistema no alcanzaban sus estados de bajo consumo. Descubrimos que el controlador SATA impedía que la CPU entrara en modo de ahorro profundo.

Esto fue una sorpresa: ¡nuestro producto ni siquiera usa discos SATA! ¿Por qué un componente inactivo impediría que el CPU ahorrara energía?

El misterioso caso del ahorro de energía SATA en Tiger Lake

Gracias a la comunidad open source, pudimos consultar directamente con ingenieros de Intel. Ellos confirmaron que el ahorro de energía SATA había sido deshabilitado intencionalmente en los procesadores Intel “Tiger Lake” para Linux, porque en versiones anteriores provocaba que algunos usuarios no pudieran arrancar sus computadoras.

Eso implicaba que muchos productos estaban sufriendo el mismo problema de batería, y que tendríamos que solucionarlo aunque nuestro equipo no usara SATA.

Nuestro ingeniero Jian-Hong Pan descubrió un detalle que había pasado desapercibido durante años: el código encargado de activar el ahorro de energía para los controladores SATA de Intel también activaba un “quirk” (ajuste especial) que debía aplicarse solo a controladores antiguos (anteriores a 2017). Sin embargo, seis años después, Linux seguía aplicando ese quirk a los controladores modernos, lo que provocaba que los discos SATA fueran inaccesibles… y bloqueaba el ahorro de energía.

Misión cumplida: dormir tranquilamente

Gracias a estos hallazgos, los mantenedores del subsistema SATA de Linux corrigieron el código, restringiendo el uso del quirk y reactivando el ahorro de energía en procesadores Tiger Lake. Esto mejoró el consumo energético en muchos dispositivos, incluidos los nuestros.

Posteriormente, evitamos que el disco se apagara por completo durante la suspensión y reactivamos Modern Standby. Ahora, el producto puede lograr hasta una semana de batería en modo suspensión.

Estas correcciones se integraron en versiones oficiales de Linux y se distribuyeron rápidamente a nuestros usuarios con Endless OS 5.1.2. Desde entonces, el problema ha desaparecido por completo: las familias que obtuvieron su primera PC con Endless ahora disfrutan una batería duradera y confiable.

Fue un viaje largo y fascinante. Lo que comenzó como un problema de energía nos llevó por los mecanismos de suspensión, firmware, gestión de discos y peculiaridades de hardware de años anteriores. Este caso demuestra la habilidad y resiliencia del equipo de Endless, el poder de la comunidad open source, y la importancia de entender los problemas hasta su raíz técnica.

Créditos:A Jian-Hong Pan y Cassidy Blaede de Endless por su investigación detallada;a David Box y Mika Westerberg de Intel por su apoyo técnico;y a los mantenedores de Linux SATA, Niklas Cassel y Mario Limonciello, por completar la solución.

Autor: Daniel Drake, VP de Ingeniería en Endless.
Daniel está comprometido con ampliar el impacto positivo de la tecnología en todo el mundo, con un especial interés en el software libre y de código abierto.