Parche para el consumo de energía en portátiles
Hace tiempo venía leyendo sobre el tema aunque sin mayor interés ya que no soy usuario de portátiles, por lo que no tengo idea de la gravedad o no del asunto para un usuario del día a día. Además, me parecía una prueba muy interesante para desarrolladores y gente observadora que se encargan del mantenimiento del kernel. Sin embargo, lo que al principio parecería un desafío solucionable en los dos o tres lanzamientos siguientes del núcleo, concluyó en un conjunto de correcciones pasajeras.
Cuando ya el asunto parecía estancarse en una lista de cosas para hacer, surge una noticia (que encontré de casualidad y fue publicada hace ya un tiempo) con otra maravillosa solución en pocas líneas. Matthew Garrett, ingeniero de Red Hat, publicó un parche de 60 líneas que, si bien no afirma ser la modificación absoluta para todo ordenador portátil, ha logrado ahorrar alrededor de 5W en su Thinkpad X220. Básicamente lo que busca hacer el parche es que el kernel se encargue de aquello que se debía hacer mediante el ingreso de parámetros durante el inicio.
Sepan disculpar que no soy un programador activo ni conozco mucho de la estructura del núcleo en sí pero a partir de los comentarios del autor del parche y algo que sé, intentaré analizar superficialmente qué es lo que se soluciona. En primer lugar, son tres los archivos que sufren modificaciones, relacionados con ACPI y ASPM. A simple vista, se tratan de sutilezas. Aparentemente lo que causa el problema es un problema de indicaciones: FADT (Fixed ACPI Description Table) dice que no soporta ASPM entonces no se le presta atención a FADT y lo activa igual. Como afirma en la publicación, Garrett, esto no sucede en Windows ya que no toca ninguna función de las PCI Express (y por lo tanto ASPM).
Ahora, existiendo el parche, ¿la corrección está a la vuelta de la esquina? No, se prevé que no vaya a estar incluído para la versión 3.3 aunque puede que aparezca en un próximo lanzamiento de alguna distribución (sea Ubuntu, Fedora, etc.). De cualquier manera, el diff para la corrección existe y está disponible para quienes quieran usarlo, de lo contrario, a esperar no más que unos meses. Ya ha pasado tanto tiempo…
Nota: quien quiera más información al respecto, Phoronix le dedicó un análisis más extenso. Sin embargo, personalmente prefería acudir a la fuente principal de la noticia.
Ahora a aprender como usar el diff, estoy desperado al no poder usar linux mas de una hora y media en mi portatil XD
El problema no es usar diff, sino compilar tu kernel. De seguro empiezan a haber kernels con este parche para las distintas distros. Si no compilas tu propio kernel regularmente esperaría a algo de esto, que aunque no es una tarea demasiado complicada es igualmente fácil cagarla.
Hola,
puedes añadir la opción “pcie_aspm=force” a los parámetros del kernel para evitar el consumo excesivo de bateria.
Tienes mas información aqui
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/ASPM.html
Un saludo.
Yo con jupiter instaladado, wifi, brillo medio bajo y firefox con 4 o 5 pestañas el máximo que consigo es una hora y veinte…
No estaría de más explicar como aplicar el diff :)
patch < parche.diff
Aunque hay que situarse bien en la jerarquía de directorios. De lo contrario 'patch' no encontrará los archivos.
Y existe el parámetro -p con el que se pueden quitar niveles de la ubicación referenciada.
Por ejemplo, si el fichero está en '/u/howard/src/blurfl/blurfl.c', con 'patch -p4' se buscará 'blurfl/blurfl.c'
wowowow no es tan facil como creen muchachos no es un simple diff hay que recompilar el nucleo sino me equivoco…
No quería meterme en tema porque tal vez se haga algo extenso y se iba del hilo del artículo pero sí, es bajar la fuente del kernel y aplicar el parche la carpeta del kernel. De ahí compilarlo (yo suelo hacer make && make modules install), copiar el bzImage de arch//boot a /boot, lo mismo con el System.map. El tema es que al usar el núcleo precompilado y no haber compilado jamás el núcleo, es un proceso más largo al tener que configurar todo a punto teniendo en cuenta la información que se tiene del hardware y lo que puede ofrecer lspci y demás. En sí, para quien compila sus núcleos, esto es un paso y listo. De lo contrario, es un trabajo algo más largo que, en mi opinión, vale la pena hacer alguna vez para conocer un poco más de lo que hay dentro.
Por si alguien copia y pega,
make -j (numero de cores * 2) <- recomendado
modules_install <- poned el guión bajo, o de lo contrario podreis hacer un estropicio.
Un saludo.
Para Mandriva ya lo hemos aplicado en MIB, no es la panacea, a mi con Mandriva 2011.0 de 32 bits y kernel 3.1.4-nrj sin pae he pasado de 20 minutos a 1hora 30 minutos, haciendo un ahorro de energía intensivo, y usando el KDE ROSA LAB. Pero hay otros que no han obtenido mejora.
Sí, aparentemente por lo que estuve viendo, resulta ser una solución algo particular. Sin embargo, ya es un paso modificar la parte problemática del código. Lo que queda será cuestión de hacer más particular esa solución para cada uno de los diferentes ordenadores.
Fue confirmado que sera incluido en 12.04 de hecho estan realizando pruebas desde hace algun tiempo la de ASPM ya termino y se agregaran algunas mejoras al kernel. https://wiki.ubuntu.com/Kernel/PowerManagement#preview
Me alegra que hayan encontrado solución, es muy buena noticia.
En Windows me duraba 4hrs más o menos, ahora en Linux 2hrs y media como mucho, aunque depende de la distro, consume más o menos.
yo la verdad no entiendo mucho porque de la noche a la mañana empezo a consumir tantos recursos la actualizacion de un kernell, si es por incompatibilidad de las tarjetas nuevas pues deberia afectar a los portatiles nuevos, pero afecta a todos, los nuevos y viejos. Porque el kernel de ubuntu 10.10 por ejemplo no tiene ese fallo y el del 11.10 si, tendríamos que devolvernos al kernel que no consume batería?
Algo tuvieron que quitar o que poner en el nuevo que hace que se consuma la bateria y que no tenia el viejo. Si fue asi, deberia poder desactivarse.
Aparentemente, resulta ser que desde 2.6.38 agregaron unas líneas para el soporte de ASPM (que desconozco desde cuando vienen incorporado a los portátiles) y lo que parece suceder es que en vez de hacer uso de él, lo desactiva. Seguramente sea mucho más complejo que eso, y entre las tantas líneas de código encontrar justo cuál es la que causa el problema es un lío, especialmente si no estaban correctamente comentadas.
ahi es donde viene mi dilema, si ASPM o lo que sea que intentaron empezar a usar en las placas de los portatiles mejora el rendimiento de la gestion de la energia, porque se descarga la bateria, y si no es asi, porque no se devolvieron al 2.6.38 y siguieron por otro camino hasta que se pueda implementar un soporte probado a esta tecnologia?. Tienes razon, puede que sea mas complejo que solo eso, pero en teoria si antes funcionaba y ahora no, porque no volver a antes y validar el soporte antes de publicar nueva version?… parece que versionitis cronica es contagiosa.
Para mi que el famoso codigo que aceleraba el rendimiento del kernell es el que se esta comiendo la bateria en los portatiles.
Es que no es tan fácil volver a la versión anterior, porque habría que desechar nuevos cambios. Igualmente esto es una de las tantas maravillas de la programación que uno agrega una línea, otra línea y por alguna extraña razón el programa deja de comportarse como antes tal vez por un paréntesis mal puesto en la línea 143 del archivo que está entre veinticinco archivos más y que para colmo no produce un error de sintáxis. Creo que es un riesgo que vale la pena correr, es decir, tal vez hoy no funcione bien eso pero tampoco por ese motivo se tiene que estancar el desarrollo. Al fin y al cabo, de alguna u otra manera somos nosotros también estamos involucrados en la prueba del software al dar nuestras quejas de algo que no funciona bien. Por ejemplo, tú dices que puede ser eso, sería interesante probar el kernel con esa funcionalidad desactivada y ver si algo cambia.
En resumen, es un riesgo que se corre usar la última versión del núcleo y las últimas versiones de todo. A mí me gusta. Por otro lado, quien no, existen versiones estables que aún se mantienen. Recuerdo hace un tiempo las distros seguían viniendo con 2.6.37 habiendo salido ya la 39 o incluso 3
Y mientras tanto, en windows no hay problema con la bateria y linux termina siendo poco competitivo en esos portatiles. Así es como se pierden usuarios, despues de todo si yo tengo un portatil con linux que me dura poco la bateria y con windows no tengo problema, voy a usar windows y voy a decir que este ultimo es mejor, y con justa razón.
En todo caso, es un retroceso hacer que algo que funcionaba bien antes, empiece a andar bien en pos de sacar nuevas versiones y dps de varias versiones no se pueda solucionar. En fin… menesteres comunes en linux. Lastima, porque estas cosas son las que alejan a los usuarios.
En mi netbook asus eeepc era una locura. La batería de tres celdas que ya de por si tiene una duración escasa (Cerca de las dos horas y poco) usando Archlinux con el kernel 3.1 no duraba ni 40 minutos. Por lo tanto, me vi obligado a instalar el kernel 2.6 LTS y hasta ahora perfecto en autonomía. El único problema lo tuve con el soporte de dispositivos ya que la tarjeta ethernet no la detectaba y tuve que instalar el driver a mano pero cosa fácil, tres comandos y a volar.
Netbook emachines e255 con xubuntu y kernel 3.0 5 horas llevo haciendo trabajos con firefox 4 pestañas y libre-office y escuchando música…
Da un poco de tristeza que a los que desarrollan el kernel hayan pasado esto completamente por desapercibido! yo solo uso linux en mis portátiles y la verdad me he dado unos topes, al punto de quedarme con ubuntu 10.10 por la cuestión de la batería, el wifi y el tiempo de encendido!
No lo pasaron desapercibido. Simplemente no les importa tanto como para retrasar la salida de una versión para arreglar ese problema. Recuerda que el target de Linux son los servidores. La culpa es de las distros que incorporan las últimas versiones del kernel aun conociendo el problema.
Otra cosa. No tenías por qué volver a Ubuntu 10.10, si tienes el problema que aquí se describe basta añadir “pcie_aspm=force como paráemtro del kernel en el cargador de arranque (grub en ubuntu), y listo.
cuando se detectó este problema en la beta del kernel, no debió de salir versión ninguna sin haberlo solucionado
es decir, nuevas versiones sirven para mejorar, no para empeorar, realmente si pasó una vez, puede pasar más de una vez
conclusión: el desarollo del kernel linux es una chapuza
tampoco… el desarrollo del kernell es algo complejo, y no se puede satanizar el trabajo de los programadores, mas cuando tienen recursos limitados y documentación escasa; pero esto va a seguir pasando a medida que linux se vaya expandiendo, eso mismo le paso a microsoft, solo que ya lo solucionaron en algún punto, hace rato y en privado.
ese error no solo fue un error de programación, sino un error de logística
es decir, deberían aprender de ese fallo, y en versiones futuras testear bien antes de sacar nuevas versiones
la nueva versión se testeó, sabían que tenia el problema de energía, el problema era que no tenían todavía la solución y no podían retrasar la fecha de salida quien sabe hasta cuando. Los que estamos en este mundo de programación sabemos lo complicado que puede ser corregir un error entre mas de 30 megas de código. Es mas, me parece lo mas acertado publicarlo con la falla para que todos se involucren y sientan el fallo propio y traten de dar luces a los programadores en donde pueda estar el error, así es como se encuentran a las joyas de programación ocultos en la maleza de internet.
No es un error de programación. El bug está en los bios que no informan correctamente el uso de ASPM. En windows funciona bien porque los fabricantes ignoran los estándares con tal que funcione en Windows.
Además, Linux tiene foco en servidores, no se puede retrasar la salida de una versión sólo porque a los nenes les come mas batería en sus laptos. Por otro lado nadie obliga a las distros a usar las últimas versiones del kernel, es problema de ellas si ignoran los problemas conocidos.
Entonces, Los PC’s de escritorio, los servidores y demás dispositivos que no sean portátiles o que no usan el ASPM les tocaría esperar???
Mi bateria murió en batalla con las botas puestas, para cuando llegue la solución ya tendré mi bateria nueva, espero…
¿Será que en Opensuse 12.1 se pueda mantener el kernel de la 11.4 y evitar así el problema? En Debian se pueden mantener los kernel anteriores cuando actualizas la versión de la distro, yo tenía kernels de recuerdo desde Woody.
No tienes más que coger el src.rpm del kernel que te interese, e intentar instalarlo, si no se deja intentar recomplilarlo, instalarlo y probarlo. Asegúrate en Yast de tener activada la opción de kernel múltiples.
Instalas, reinicias, eliges el kernel recompilado, y si funciona problema resuelto. Luego tendrás otros problemas, como los parches de actualización.
El kernel es uno o varios paquetes, como todos los demás. Por probar asegurándote de que tienes la opción de kernel múltiple activada en principio no tiene porqué ser dañino. En todo caso siempre puedes probar en VirtualBox, etc.
Veo que se puede tener más de un kernel, y arrancar con el que quieras, pues tengo en el portátil también tengo el kernel de xen, que a fin de cuentas es un kernel. Lo que no quiero es que me desinstale de oficio el kernel 2.6.37, para seguir iniciando con él, en vez de con el que traiga Opensuse 12.1
YaST tiene la solución.
P.D. Algo que se me olvidaba. Si usas driver privativo del kernel tienes que usar el que “esté a juego” con el kernel. Si no crash de video muy probablemente.
Sí, yast es la repera, fue por él que dejé Debian, ya estoy viejo para ir por ahí editando archivos de texto. En cuanto a los drivers privativos, tengo el repositorio de Nvidia y supongo que los paquetes de drivers funcionarán con cualquier kernel que arranque.
Conozco muy poco de OpenSUSE pero si mal no recuerdo, en el caso que quieras actualizar y no instalar de 0, había una opción para bloquear la actualización de un paquete, algo dentro de un archivo de configuración o tal vez en la interfaz del gestor de paquetes. De lo contrario, el repositorio con el kernel 2.6.37 están http://download.opensuse.org/repositories/Kernel:/openSUSE-11.4/openSUSE_11.4/
No entiendo porque tanta queja, para los que no quieran el problema está Ubuntu 10.4 que uso en la portatil.
También hay que tener en cuenta el controlador de Video. Yo tuve que instalar el privativo de AMD y me funciona perfecto la batería. Solo es un poco malo el uso de Flash.
Tambien hay que tener en cuenta que en algunas portátiles el Kernel nuevo funciona perfecto, como en la HP Elite Book de mi trabajo. Supongo que en las nuevas portátiles este problema está solucionado porque el Bios está bien configurado.
Hace tiempo traduci para blogdrake un articulo de Adam Willianson en el que abordaba con algo de humor el desarrollo de las aplicaciones libres y de código abierto
http://blogdrake.net/node/16516
Muchachos, ese parche fue generado con Git, por lo cual con el comando patch al menos a mí no me funcionó aplicarlo al código del kernel. Hagan lo siguiente.
1. Se bajan el código del kernel.
2. Lo descomprimen y se paran mediante el comando cd en la carpeta donde tienen el código.
3. Luego con el comando git apply aplican el parche, se hace así:
git apply parche.diff
donde parche.diff es precisamente el diff del parche, el que está en el link al que hace alusión este artículo.
Luego deben compilar ese kernel y ya listo.
Nota: A mí me funcionó bien aplicar ese parche al código del kernel 3.1.
Saludos y happy hacking