libata.noacpi=1 ¿Solución real o fake a los errores ACPI?

[Jecc 15]

 

Saludos comunidad.

 

Hace poco me registré y comparto en este hilo mi presentación.

Les recuerdo que soy un usuario novel en GNU/Linux, por eso recurro hacia ustedes para esclarecer todas mis dudas.

 

La llegada del kernel 4.9 inrrumpío mi calma de 5 años como usuario común de Linux. Desde entonces he vuelto a mirar otras distros que tengan de fábrica un kernel anterior o como Manjaro, la opción de con un clic instalar otra. Sé que se puede hacer un downgrade del kernel, pero nunca lo he hecho y eso será algo que pediré ayuda acá pero en otro tema, quiero concentrarme ahora en lo que el título menciona, un comando llamado: libata.noacpi=1.

 

A partir del kernel 4.9 y posteriores mi sistema me registra dos errores ACPI al inciar, los comparto:

Haciendo un:

journalctl -p err

 

ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)

 

ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT5._GTF] (Node ffff8807fe0dbcd0), AE_NOT_FOUND (20160831/psparse-543)

 

La verdad he tratado de averiguar en qué podría afectar esos errores, pero no he encontrado la respuesta.

Desconozco la “gravedad” de esto y qué no funciona ahora, el sistema en teoría corre igual, pero en este tipo de cosas si soy quisquilloso y no me siento en paz al saber que tengo una falla que desconozco.

 

Por otro lado, encontré una “solución” para que los mensajes de errores desaparezcan. Se trata de añadir en el grub la siguiente línea: libata.noacpi=1

Al hacer esto desaparecen los mensajes de errores, pero leyendo en la página oficial del Kernel Linux, encontré esto:

 

libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume when set.

 

https://www.kernel.org/doc/html/v4.10/admin-guide/kernel-parameters.html

 

Como leen, ese comando deshabilita el uso de ACPI.

 

Pero acá mis dudas:

¿Deshabilita el uso de ACPI de solo dos errores o de todo lo relacionado a ACPI?

La lógica me hace suponer que de todo ACPI.

El problema con eso sería que al añadir esas líneas podría tener más problemas que al principio, ¿es así?

 

¿Alguno de ustedes sabe qué significa esos dos mensajes de error y a qué afecta?

¿Los ignoro y sigo normal mi vida? (No creo que esa sea una opción para mi subconsciente)

 

Cualquier conocimiento sobre este tema de errores ACPI es bienvenido.

 

Muchas gracias.

Editado Julio 1, 2017 por Jeccolhe

[Shiba87 38549]

Parece un problema de comunicación entre el kernel y el firmware de la placa base y puede ir en ambos sentidos. O bien una mala implementación ACPI por parte del fabricante de la placa o un bug del kernel que hace que interprete mal la información que recibe de ésta.

No lo creo, pero aparte de actualizar la versión de Linux ¿Han habido cambios/actualizaciones de BIOS?

 

 

Y la respuesta es NO. La opción para deshabilitar TODO ACPI sería:

acpi=off

Si ése fuera el caso sería mucho más evidente porque no podrías ni apagar el equipo

 

libata.noacpi=1 se limita a la suspensión y habilitación de dispositivos ATA, nada más.

 

En general y por lo que he podido encontrar, se trata de una malo o nulo apego por parte de los fabricantes de los estándares ACPI y Linux, que se ha vuelto más estricto a la hora de no permitir este tipo de chapuzas.

Dicho de otra forma y para que nos entendamos... puede que ese problema haya estado ahí desde el día que esa placa base salió de la fábrica

 

En principio no va a explotar nada, pero obviamente empezar a deshabilitar cosas no es la solución más elegante ni recomendada. Si se trata de una regresión del Kernel la solución no la veo en el downgrade sino en la actualización, pero es muy probable que los mensajes sigan ahí. Si es la placa, dependerá del fabricante y su buena voluntad de ofrecer actualizaciones de firmware que lo resuelvan, así que ahí ya nos metemos en un terreno más delicado.

[Jecc 15]

Muchas gracias Shiba87 por tu respuesta.

 

Concuerdo contigo en relación a que ir deshabilitando cosas por ahí no es la solución más elegante.

Como manifiestas, el problema pasaría por parte del fabricante y sus nulas actualizaciones.

Un error similar al mío lo leí en este hilo de bugzilla, mismo que está cerrado y documentado. La respuesta de quien cerró el caso hacía referencia a un error de Bios, para ser más exacto escribió:

 

Cita

This bug is about a broken BIOS causing Linux to spew warning messages about a broken BIOS. Ignore the messages, or get a computer from a vendor that validates for Linux. Closed as Documented -- will not fix.

 

Necesitaría una nueva versión de Bios para ver si eso soluciona, pero en mi caso con la mainboard Asus Hero VI será imposible, la última actualización data del 2014 y obviamente esa fue la última.

 

Sobre el tema del downgrade del kernel, lo plantearé en otro tema más por motivos de aprendizaje, seguro interesará a otras personas.

Mi solución será usar un kernel anterior al 4.9.

Siempre me ha gustado Debian y esta es la oportunidad para instarle Jessie, ya que la nueva Stretch trae el kernel 4.9.

Por cierto, leí tu guía y es muy ilustrativa (¿aunque creo que faltó agregar la instalación de las X?).

Siendo usuario Arch de toda una vida, optaré por la instalación Netinstall básica y sin entorno gráfico, necesito ver en consola todo lo que se instala; creo que es más por costumbre que otra cosa.

 

Muchas gracias.

Editado Julio 2, 2017 por Jeccolhe

[Fransis 3409]

yo tengo los mismos errores de acpi, tanto mi sobremesa que es una placa asus  sabertooth pero h77, osea modelo de tercera generacion de procesadores intel, la ultima actualizacion que lanzaron de bios fue para el 2015 creo. y en el portatil xiaomi mi notebook air 13,3, que a estos de xiaomi no les he visto lanzar ninguna actualizacion para la bios desde hace 1 año que tengo el portatil.

los errores me aparecen con kernel 4.9, 4.10 y el actual 4.11, asi es que si, coincido en que es algo que han metido en el kernel de linux.

por mi parte tengo que decir, que no he notado ningun tipo de fallo, ni problemas de consumo, ni ventiladores locos, ni nada extraño... actualmente uso kernel CK 4.11 con BFQ como siempre, y ningun problema.

salu2

[Shiba87 38549]

Cuidado, cuidado que viene el pejiguero de guardia...

 

En el kernel DE Linux en realidad no han metido nada, principalmente porque Linux es un kernel en sí mismo y eso sería imposible

 

Lo que ocurre es que ahora Linux es más estricto con las especificaciones ACPI, lo que implica que errores en el firmware de la placa base que siempre han estado ahí pero hasta ahora pasaban desapercibidos, se tienen mucho más en cuenta.

En ese sentido salvo que el problema de la BIOS sea muy escandaloso, en la mayoría de los casos todo seguirá igual que siempre, al fin y al cabo no ha cambiado nada

[alguien 461]

A mi hasta que he instalado debian 9 no me salía ningún error ACPI, ahora muchos:

 

 

 

Como no vi este tema he investigado en mi anterior foro de Debian, un foro francés con mucho moviminto y actividad, pero tengo mi frances muy oxidado, del ingles mejor ni hablar.

 

Total que un usuario me ha ofrecido hoy mismo esta solucion en el menú del Grub, " libata.noacpi=1"

Con la cual los errores dejan de mostrarse. También me preguntaba si eso es barrer bajo la alfombra.

[mijailbellum 1872]

hace 10 horas, alguien dijo:

Total que un usuario me ha ofrecido hoy mismo esta solucion en el menú del Grub, " libata.noacpi=1"

Con la cual los errores dejan de mostrarse. También me preguntaba si eso es barrer bajo la alfombra.

 

Es barrer bajo la alfombra, pero estos errores vienen dados porque los creadores del hardware  no implimentan bien ciertas cosas y poco se puede hacer para solucionarlo, son más como advertencias, así que no hay que preocuparse mientras no falle nada.

[Shiba87 38549]

De hecho, los errores han estado ahí toda la vida, sólo que no habíamos reparado en ellos.
La única diferencia es que ahora Linux (nada tiene que ver con Debian) es más estricto y nos los muestra más claramente.

[alguien 461]

Ya lo habeis comentado mas ampliamente varios post mas arriba. Pero es como que da mas tranquilidad que no se muestren errores y/o advertencias. Hay algo psicologico en eso.

 

pues mi placa tambien es asus, y de la gama mas alta en su dia, tanta fama con asus. La ultima actualizacion de la bios fue del 2015, y como han dejado de fabricarla no creo que saquen mas.