Erreurs ACPI qui saturent l'espace disque

Support Debian
Tags: #<Tag:0x00007f63f4ea6820>
#1

Bonjour,

Je gère dans mon entreprise, des afficheurs dynamiques (des mini-PCs Intel NUC qui diffusent des informations via un client Xibo-Player sur des écrans).
Nous avons décidé de migrer nos afficheurs de Windows 10 vers Linux Debian 10 à cause d’instabilités sous Windaube et car nous sommes attachés au monde libre.
Mais finalement nous n’avons pas gagné en stabilité et c’est même pire:

Les NUCs sont programmés avec cron pour hiberner la nuit grâce à rtcwake et c’est entre-autres la cause de mon problème.
En effet, les mini-PCs génèrent des erreurs ACPI en boucle quand ils sortent d’hibernation, ce qui crée des logs de plusieurs dizaines/centaines de Go, sature le disque et rend inutilisable l’afficheur.

Voici un extrait des logs:

root@afficheur:/var/log# head -n 6 syslog
kernel: [18626.421742] ACPI BIOS Error (bug): Could not resolve [\_GPE._L66._SB.ITBI], AE_NOT_FOUND (20180810/psargs-330)
kernel: [18626.421744] ACPI Error: Method parse/execution failed \_GPE._L66, AE_NOT_FOUND (20180810/psparse-516)
kernel: [18626.421746] ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L66] (20180810/evgpe-515)
kernel: [18626.421893] ACPI BIOS Error (bug): Could not resolve [\_GPE._L66._SB.ITBI], AE_NOT_FOUND (20180810/psargs-330)
kernel: [18626.421895] ACPI Error: Method parse/execution failed \_GPE._L66, AE_NOT_FOUND (20180810/psparse-516)
kernel: [18626.421897] ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L66] (20180810/evgpe-515)

Je n’ai pas réussi à trouver quelqu’un ayant le même cas que moi, d’autant plus que ces erreurs sont aléatoires.

L’erreur peut apparaitre sur plusieurs afficheurs de modèles différents mais n’apparaît pas sur tous les PCs d’un même modèle:
Les PCs en question sont des Intel NUC8i3BEK2, quasiment identiques niveau système car clonés avec CloneZilla, mais seulement quelques-uns ont été touchés.

J’ai déjà mis à jours à la dernière version les BIOS de ces PCs, mais l’erreur est revenue au démarrage d’un PC puis disparait après un redémarrage forcé…

Pour l’instant, j’ai retiré la tâche cron qui programme rtcwake mais ce n’est pas très écologique de laisser allumer ces PCs h24.
J’ai aussi programmé logrotate toutes les 10 minutes et restreint la taille des logs à 1Go mais je ne parviens pas à régler la cause du problème.

Auriez-vous donc des pistes ? Revenir à Windows :lol: ? Migrer vers une distrib compatible avec ces matériels ? Report le bug à Debian ?

Je reste à votre disposition pour toute demande d’infos complémentaires.
Merci par avance pour votre aide,
tintamarre

#2

Deux façons de voir :

rmmod acpi_power_meter
echo blacklist acpi_power_meter >> /etc/modprobe.d/blacklist-power-meter.conf
modprobe ipmi_si
modprobe acpi_ipmi

ou trouver le firmwre qui manque mais tu l’as déjà surement fait.

  • garder cette information et empêcher son écriture dans syslog ( solution probablement suffisante )
#3

Merci pour ta réponse, concernant ton lien, il s’agit d’un problème d’IPMI sur un serveur dont je ne pense pas être concerné ?

Comment puis-je savoir quel firmware chercher ? Je ne trouve pas en cherchant sur le web quel composant peut être relié à l’erreur « GPE._L66._SB.ITBI »

Les erreurs apparaissaient également au démarrage, la suppression des erreurs dans syslog n’évitera pas le blocage au démarrage, si ?

#4

Tu peux essayer d’ajouter le paramètre suivant à la ligne de commande du noyau pour supprimer les messages :

acpi_mask_gpe=0x66

Cf. ce sujet précédent

cat /proc/acpi/wakeup

pourrait identifier le composant en cause.

#5

A partir de là je ne vois pas ce qu’on peut faire. Vérifier que les installations sont vraiment identiques, programme par programme ?
Ou ça viendrait d’une différence entre machines, un bios update peut etre?

#6

Merci pour ta réponse et désolé pour mon retour tardif : étant apprenti, je ne suis pas tout le temps présent et n’ai donc pas pu tester ta solution.
Sinon, ça me semble être tout à fait ce que je cherchais :slight_smile:
J’ai appliqué le masque dans grub et réactivé l’hibernation, je tâcherai de faire un retour ici dès que j’aurai assez de recul sur cette résolution.

Pour répondre à dindoun, comme précisé dans mon premier post, les machine ont été clonées à l’identique à partir d’un template, les seuls changement apparaissent dans la configuration de xibo-player et des horaires d’hibernation.
Un BIOS update a déjà été effectué également.

#7

Bonjour,

une question: pourquoi les mettre en hibernation la nuit et ne pas tout simplement les éteindre?
Si c’est pour les redémarrer le matin, pouruqoi ne pas utiliser le Wake on LAN?

#8

Bonjour, l’hibernation avec rtcwake nous a paru être le meilleur choix car jusqu’ici c’était assez fiable, facile à mettre en place (une tâche CRON à programmer) et modifiable à distance (TeamViewer). En comparaison avec du Wake on Lan pour lequel il faut un appareil tiers pour gérer le réveil, et l’ensemble de nos afficheurs ne sont pas tous dans le même réseau non plus.

Avant, nous gérions ça par démarrage programmé dans le BIOS mais avec les changements d’heure et le fait que l’on ne puisse pas modifier l’horaire de réveil à distance, ce n’était pas pratique ^^

Enfin, un arrêt/allumage programmé (Wake on LAN ou réveil BIOS) n’aurait pas réglé le problème car les erreurs sont également apparues au démarrage d’un des PCs.