Re: Le Load_Cycle_Count : encore des problèmes ?
Le samedi 17 septembre 2011 à 21:51:26, Eddy F. a écrit :
>[…]
> > Quand est-ce que la valeur repasse à 128 ?
>
> Je suis à 128 par défaut !
>[…]
> Ensuite si je change la valeur, par ex. 160, le niveau reste
> à 160 et n'est modifiée que par un reboot, une sortie de
> veille en ram ou une hibernation.
Ok. Donc soit c’est un script (v. plus loin), soit c’est le
disque.
> Mon premier souci est que, partout où je cherche (listes
> debian, rapports de bugs, forums debian ou ubuntu...) le
> problème est résolu depuis 2 ou 3 ans !
Attention. Le bogue/problème résolu, c’est la valeur par
défaut utilisée par les scripts. Debian a décidé d’utiliser 128
sur batterie et 254 sur secteur, crois-je.
Le problème des disques qui font n’importe quoi n’est pas
résolu vu que ce sont certains disques (pas tous) qui font
n’importe quoi…
> Et le problème n'est pas lié à la distribution testing. Sur
> un autre portable où squeeze est installée, j'ai aussi le
> même niveau de 128 par défaut (mais là cela ne cause pas de
> souci de load_cycle_count - je suppose parce que c'est un
> autre disque).
Yep.
>[…]
> Chez moi aussi donc. Mais est-ce le disque qui est
> responsable ? Ou est-ce dû aux scripts de mise/sortie de
> veille/hibernation ?
Étant donné que, par défaut (en tout cas sous Sid ce jour),
aucun script dans /etc n’utilise hdparm (à part ceux de hdparm),
qu’aucun fichier de config (notamment ACPI) ne parle de hdparm
ni ne contient 128 (dans un sens hdparmiesque), je vois mal
comment ça pourrait être un script ou c’est très mal foutu.
Le seul script qui passe de 128 à 254 et réciproquement est
l’exemple donné dans /usr/share/doc/acpi-
support/examples/*.d/90-hdparm.sh (lequel est plutôt bien
écrit : il laisse laptop_mode gérer s’il est là pour ça).
>[…]
> La variable $hdparm_opts de ce script est lue dans
> /etc/default/hdparm.
Oui, c’est pour cela que la première ligne de mon script est
. /etc/default/hdparm
> Chez moi, elle est vide. Cela explique-t-il pourquoi je suis
> au niveau 128 au démarrage ?
Oui, puisque 128 semble être la valeur préférée de ton disque.
> Est-ce normal qu'elle soit vide ?
Oui.
> Est-ce un bug ?
Non.
> Y écrire "-B 254" ne sera pas satisfaisant car j'aimerais tout
> de même conserver cette valeur de 128 quand je suis sur
> batterie.
Dans ce cas, il faut utiliser laptop-mode-tools ou avoir un
script plus malin dans /etc/acpi/.
> En fait, je n'y connais rien et donc ne comprends rien à ce
> qui se passe dans la gestion de l'énergie et du disque :
> hdparm, acpi, apm, pm-utils... qui fait quoi dans quel
> ordre.
Bonnes questions. Quelques réponses :
hdparm : juste un outil pour vérifier/régler le matériel
ACPI : un beau merdier…
APM : en général, juste un acronyme, à ne pas confondre avec
l’APM qui était le système de gestion d’énergie dans les BIOS
avant ACPI (même acronyme mais certaines vieilles pages ou
vielles gens peuvent confondre, donc ne pas utiliser comme
mot-clef dans ses recherches)
pm-utils : des scripts pour suspendre/hiberner, lesquels lancent
les scripts adéquats dans /etc/pm/*.d/
acpi-support : des scripts qui gèrent les évènements ACPI, dont
l’appel aux scripts de pm-utils lors d’un appui sur le bouton
ACPI correspondant (p.ex. fermeture de l’écran).
On peut mettre ses scripts (hooks) dans /etc/acpi/*.d/.
(Note que ces répertoires n’existent plus, et ne sont plus
visités, dans les dernières versions d’acpi-support et donc
que le script /etc/acpi/power.sh est aussi à modifier suivant
l’exemple de /usr/share/doc/acpi-support/examples/acpi/ ;
remarque que l’on peut aussi tout traiter directement dans ce
power.sh…)
acpi-support utilise aussi upower (c’est notamment indiqué
dans les commentaires de /etc/default/acpi-support).
upower : démon qui donne des infos sur et active les fonctions
de la gestion d’énergie, via D-Bus.
Il doit utiliser les scripts de pm-utils (et donc passer par
/etc/pm/*.d/*) lorsque l’on suspend/hiberne…
> Que se passe-t-il quand on clique bêtement sur le
> bouton hiberner de gnome ou kde ?
Maintenant, ils sont censés passer par upower, via D-Bus.
Ils peuvent aussi gérer les boutons ACPI (ce qui peut causer
une double gestion et des soucis avec acpi-support ?).
> Ou trouver une documentation sur le sujet (si possible
> spécifique à Debian) ?
Lire /usr/share/doc/<paquet>/README.Debian (et les fichiers
autours), regarder aussi les pages web indiquées dans les
descriptions des paquets (ou les README)…
> > Peut-être que maintenant laptop-mode-tools le fait aussi
> > mais, la dernière fois que j’ai regardé, il fallait éditer
> > le script pour modifier ces valeurs (à plusieurs endroits en
> > plus ; et à refaire/vérifier à chaque m-à-j)…
>
> Bon, a priori, ce paquet n'est pas indispensable. Je vais
> essayer sans. Tant que je ne comprends pas comment le
> laptop-mode fonctionne, pas besoin d'en utiliser des outils
> :-(
Je crois que, pendant un moment, laptop-mode-tools et pm-utils
étaient en conflit (de canard) mais ce n’est plus la cas sous
Sid. En tout cas, gérer le spin-down des disques était son
propos principal, c’est juste qu’il est (était ?) un peu fouilli
et qu’on peut le faire soi-même.
>[…]
> Donc effectivement, utiliser un tel script me permettrait
> d'avoir au moins une valeur correcte au démarrage. Ensuite
> un script au bon endroit pour les autres cas.
Yep.
>[…]
> > (Note : hdparm -i est plus intéressant que smartctl pour
> > l’APM…)
>
> Ok, je donne le résultat ici, on ne sait jamais.
C’est surtout qu’on y retrouve la valeur de -B (0x80 = 128),
laquelle ne figure pas dans SMART.
--
Sylvain Sauvage
Reply to: