[hdparm]reglage ne subsiste pas (resolu)

Reconnaissance et configuration du matériel / kernel linux
Avatar de l’utilisateur
albireo
Elfe
Messages : 554
Inscription : ven. 15 sept. 2006, 15:47
Localisation : vallée de la save en Occitanie

[hdparm]reglage ne subsiste pas (resolu)

Message par albireo »

bonjour,

je règle l'Advanced Power Management du disque de mon Eeepc à la valeur: 254 et après mise en veille cette valeur retombe à 96. A cette valeur le parcage des têtes devient inquiétant (ça claque en permanence). Y a t'il une solution pour que les règlages hdparm reste aux valeurs choisies avant la mise en veille ?

Pour précision je fait actuellement ces réglages avec systemctl mais avant c'était la même chose sans systemctl avec rc.local
Dernière modification par albireo le ven. 17 août 2012, 16:55, modifié 1 fois.
Utilisateur ArchLinux depuis 2004 et linux depuis 1996 :D
Arch 64/gnome sur ASUS H87M-E C2 + i5 3.2GHz + 16Go + 2To + écran 22"
1996 *** 2004 nova widget wombat woodoo dontpanic overlord .......... 2026
hopimet
Elfe
Messages : 996
Inscription : mer. 14 mars 2012, 22:48

Re: [hdparm]reglage ne subsiste pas (en cour)

Message par hopimet »

Salut,

Tu peux contourner en mettant le réglage dans le fichier /etc/rc.local. Il suffit d'y ajouter la ligne :
hdparm -B 254 /dev/sda
(si sda est le disque concerné)

Ainsi, ça sera appliqué à chaque démarrage.

Edit : je n'avais pas lu ta dernière ligne. Ça m'étonne que ça ne fonctionne pas avec rc.local. Au cas où tu utilises systemd, n'aurais-tu pas désactivé l'exécution de rc.local ?
Avatar de l’utilisateur
albireo
Elfe
Messages : 554
Inscription : ven. 15 sept. 2006, 15:47
Localisation : vallée de la save en Occitanie

Re: [hdparm]reglage ne subsiste pas (en cour)

Message par albireo »

cela n'a rien a voir avec systemd, mais j'ai dut mal poser le problème.
Quand je boote (avec systemd mais c'était pareil avant) l'APM est a 254, ce qui est normal puisque j'ai fait un service pour ça ou j'utilisais rc.local. Ensuite je passe en veille (systemctl suspend ou sudo pm-suspend, j'ai essayé les deux) et quand je relance l'APM est à 96. Si je le remets à 254 et que je remette en veille etc ... etc ... il se retrouve toujours à 96 ...
C'est ça que je ne comprends pas, et j'aimerais savoir s'il existe un moyen de fixer ces valeurs ou des les controler automatiquement ...

voilà.
Utilisateur ArchLinux depuis 2004 et linux depuis 1996 :D
Arch 64/gnome sur ASUS H87M-E C2 + i5 3.2GHz + 16Go + 2To + écran 22"
1996 *** 2004 nova widget wombat woodoo dontpanic overlord .......... 2026
Avatar de l’utilisateur
albireo
Elfe
Messages : 554
Inscription : ven. 15 sept. 2006, 15:47
Localisation : vallée de la save en Occitanie

Re: [hdparm]reglage ne subsiste pas (en cour)

Message par albireo »

personne n'a une idée sur ce problème ?
Utilisateur ArchLinux depuis 2004 et linux depuis 1996 :D
Arch 64/gnome sur ASUS H87M-E C2 + i5 3.2GHz + 16Go + 2To + écran 22"
1996 *** 2004 nova widget wombat woodoo dontpanic overlord .......... 2026
Avatar de l’utilisateur
albireo
Elfe
Messages : 554
Inscription : ven. 15 sept. 2006, 15:47
Localisation : vallée de la save en Occitanie

Re: [hdparm]reglage ne subsiste pas

Message par albireo »

bon j'ai trouvé en fait.
il faut créer un fichier executable dans /usr/lib/systemd/system-sleep
moi je l'ai appelé resume.sh mais je pense que le nom importe peu.
Quand la commande systemctl suspend est utilisée elle envoie une variable $1 qui prend les valeurs pre ou post et il suffit de mettre la commande hdparm dans les instructions post :D et ça fonctionne.

Code : Tout sélectionner

#! /bin/sh
case "$1" in
  pre )
    #
    ;;
  post )
    hdparm -B 254 /dev/sda
    ;;
esac
je ne sais pas si la place de fichier est bonne dans la mesure ou si une mise à jour est effectuée il doit disparaitre, et qu'il vaut mieux le placer dans /etc mais je verrais ça plus tard.
Utilisateur ArchLinux depuis 2004 et linux depuis 1996 :D
Arch 64/gnome sur ASUS H87M-E C2 + i5 3.2GHz + 16Go + 2To + écran 22"
1996 *** 2004 nova widget wombat woodoo dontpanic overlord .......... 2026
Répondre