Salut,
Sur le forum gentoo je suis tombé sur ce post
Le mec a résolu son problème.
Comme je suis sous gentoo je ne sais pas si hwclock se configure pareil.
A voir
tant qu’on y est on va coller la soluce potentielle 
[quote]I finally found the cause of the issue: the command “hwclock --systohc --local” causes the battery to drain when the laptop is off.
This command is executed by the /etc/init.d/hwclock script.
If I set clock_hctosys=“NO” in /etc/conf.d/hwclock, that command does not get executed anymore, and the battery does not drain.[/quote]
L’équivalent de /etc/conf.d/hwclock sous Debian serait /etc/modprobe.d/hwclock non ? J’ai pas mon laptop sous la main pour tester…
non, il y a un /etc/init.d/hwclock.sh qui sert à paramétrer l’heure au démarrage (indiquer quelle horloge prendre, et synchroniser l’horloge soft avec l’horloge hard)
il y a un HCTOSYS_DEVICE=rtc0, mais pas de clock_hctosys
Les scripts lisent /etc/default/rcS et /etc/default/hwclock
Je vais regarder mais j’avoue que ça me laisse perplexe. Comment diable cette commande (qui met l’heure système dans l’heure machine laisse la machine dans un état de consommation???
En tout cas je n’aurais jamais cherché dans cette voie, j’ai essayé de supprimer énormément de chose à l’arrêt mais pas ça…
Je teste.
PS: Il suffit de mettre HWCLOCKACCESS=no dans /etc/default/hwclock
Bon, les premiers tests semblent concluants. Je pense que le noyau ne doit pas attendre la fin de la mise à jour de l’horloge avant d’éteindre la machine. Je vais éplucher hwclock pour savoir. Merci d’avoir signaler le fil (récent il date du 16 novembre!), je n’aurais jamais pensé regarder du coté d’hwclock (et pourtant j’en ai stoppé des services avant de fermer la machine)…
Si ton problème est résolu, merci de cliquer sur la coche verte.
Sont pénibles ces petits nouveaux 
Ça n’est pas résolu, c’est une rustine et il faut que j’attende une nuit pour être sur qu’elle marche. Le problème semble être dans la gestion de rtc par le noyau. Ce serait bien un souci du noyau. Je verrais si je coche le bazar vert ou pas à ce moment… 
Concretement hwclock lit les fichiers /etc/default/rcS et /etc/default/hwclock.
Je n’ai vu nulle part l’option HWCLOCKACCESS définie par défaut (ce qui
revient à la mettre à yes, oui, ok, etc)
J’ai crée le fichier et ça convient.
En fait concrétement, outre le rajout de cette opotion, j’ai un
fichier /etc/rc.local contenant
#!/bin/bash
if [ -d /etc/scripts.d ] ; then
for f in $(ls /etc/scripts.d | grep -v "~$") ; do
/etc/scripts.d/$f
done
fi
exit 0
qui exécute ce qui est dans /etc/scripts.d au démarrage.
Dans /etc/scripts.d, j’ai un fichier economie contenant
[code]#!/bin/sh
/sbin/ethtool -s eth0 wol d
acpitool -w | grep enabled
| grep -v “LID” | sed -e ‘1,$s/ ([0-9])…*$/\1/’ \
| xargs -n 1 acpitool -W
[/code]qui stoppe toutes les causes de réveil automatique sauf le
relevé de l’écran (LID) que je veux conserver.
Je me demande si le problème ne viendrait pas du temps
que met le noyau pour mettre à jour l’horloge système?
En tout cas ça marche, bon on va mettre la coche verte mais ça n’est pas satisfaisant.
Si je regarde le noyau (arch/x86/kernel/rtc.c), il semble que la mise à jour de l’horloge se fait exactement 500ms après la demande ce qui est long. Je vais voir si il ne suffit pas de rajouter 1s de délai lors de l’extinction de la machine…
Bon, un délai de 1s avant la suite ne suffit pas. C’est plus compliqué que ça.
Pznse à faire un rapport de bug debian, ça fera peut étre bouger les choses, et d’autres personnes vont apporter leur pierre à la résolution du probléme.
Il me semble que cela à été précisé comme fait bien avant mais que l’équipe du noyau renvoyé le problème à d’autre et que les rapports avaient été clôturés 
Maintenant si le problème est bien ciblé pourquoi pas 
Le problème n’avait pas été cloturé mais renvoyé sur l’ACPI. J’ai évidemment précisé le problème sur le rapport de bug et espère que les choses vont bouger. Mais rien de neuf pour le moment
Malheureusement, sur mon laptop un
n’a rien changé… 
Essaye de mettre tout ce que j’ai dit, c’est à dire
-
le fichier /etc/default/hwclock avec donc
HWCLOCKACCESS=no -
Un fichier rc.local contenant l’exécution des scripts dans /etc/scripts.d
-
le script suivant dans /etc/scripts.d/batterie
#!/bin/sh
/sbin/ethtool -s eth0 wol d
acpitool -w | grep enabled | grep -v "LID" | sed -e '1,$s/ *\([0-9]*\)\..*$/\1/' | xargs -n 1 acpitool -W
N’oublie pas de faire un chmod +x, il supprime le WOL et désactive toutes les réveils par des péripohériques excepté l’écran.
Ça récapitule tout ce que j’ai essayé pour arrêter la fuite de la batterie…
Tu peux également essayer en faisant un modprobe -r des modules réseaux et bluetooth avant l’extinction.
Yes, ça marche !
C’est donc l’ACPI qui prévoit un WakeOnBidule qui pompe la batterie ?
Tu as
- Soit le Wake On Lan activé
- Soit le Wake On USB (via une action sur un clavier USB) activé
- Soit la charge port USB laissée machine éteinte
- Soit le Wake on Bluetooth (j’imagine, avec des claviers bluetooth)
etc.
Regarde le contenu de /proc/acpi/wakeup pour voir les possibilités…
Effectivement,
Device S-state Status Sysfs node
SPB0 S4 *disabled pci:0000:00:15.0
SPB1 S4 *disabled pci:0000:00:15.1
USB0 S3 *enabled pci:0000:00:12.0
USB1 S3 *enabled pci:0000:00:13.0
USB4 S3 *enabled pci:0000:00:12.2
USB5 S3 *enabled pci:0000:00:13.2
KBC0 S3 *enabled pnp:00:07
PS2M S3 *disabled pnp:00:08
P2P S5 *disabled pci:0000:00:14.4
Bon, des nouvelles du front:
-
Le rapport de bug (48711) est pris en compte et j’ai reçu des nouvelles (notamment une demande de test avec le noyau 3.
. -
Le noyau 3.8 ne change strictement rien au problème, le seul effet de bord est que du coup j’ai compilé ces noyaux pour wheezy avec le support aufs (cf mon dépot).