[quote=“tetrix”][quote=“vv222”]Mais ils ne lisent rien ces gens ?!
C’est un problème lo-gi-ciel : cette consommation nocturne n’a pas lieu si la machine a été éteinte via Windows…
Le responsable est le système, pas le matériel.[/quote]Un logiciel qui tournerait sans matériel, pas de support physique…Tu as une drôle de façon d’établir un diagnostique. 
[/quote]
Non, un logiciel qui indique à un matériel de continuer à tourner…
Si tu parlais de trouver le matériel qui tourne pour tenter de repérer le logiciel coupable, je retire mes grommellements !
La batterie ne eut être retirée.
Sinon, un arrêt de la machine après avoir retirée les modules (sauf USB notez) ne change rien. Un arrêt après avor fait un rfkill block all non plus. Je vais tester en arrêtant après avoir supprimé tous les modules possibles, puis si ça coince, en arrêtant sous windows, redémarrage et arrêt sous linux après avoir blacklisté ath9k par exemple (WIFI). Je voudrais le coupable;…
Pas de souci 
tu ne nous a pas dis comment tu arrêtais ta machine.
en cliquant sur le bouton exit ou en tapant une commande ?
[quote=“fran.b”]La batterie ne eut être retirée.
…[/quote]
et si elle lâche, comment tu fais, tu rachètes une autre machine ?
[quote=“fran.b”]La batterie ne eut être retirée.
Sinon, un arrêt de la machine après avoir retirée les modules (sauf USB notez) ne change rien. Un arrêt après avor fait un rfkill block all non plus. Je vais tester en arrêtant après avoir supprimé tous les modules possibles, puis si ça coince, en arrêtant sous windows, redémarrage et arrêt sous linux après avoir blacklisté ath9k par exemple (WIFI). Je voudrais le coupable;…[/quote]
si tu as le courage essais avec un aute pc d’aller voir en acces ssh ce qui tourne sois disant eteins avec htop par exemple , tu sais faire ! ca! 
?? Rien ne tourne, mais par contre il y a du nouveau. Eteint avec le noyau de clefagreg, tout marche impeccablement. C’est donc bien un souci de noyau. Je vais voir avec le dernier noyau en cours…
Bon, j’ai compilé un noyau 3.5.2 (que je dépose sur
deb boisson.homeip.net/debian wheezy divers
en amd64 avec les headers pour ceux qui veulent, il sera sur le site vers 15h le temps dépendant de la connexion). Je donnerais les résultats après
Bon, noyau 3.5.2 disponible chez moi. Test en cours pour voir si ce pbm est résolu juste après ce message.
Hé bé, ça ne nous rajeunit pas tout ça !
hello
bon je viens de passer un wheezy mai pas sur mes portables.
Sure mon fixe, cela déconne quand je fait halt … sa reboot et que je fait reboot ben sa fait reboot … 
je parie plutôt sur un problème coter kernel . ce qui me fait dire sa c’est que le bios n’a plus rien a voir avec ce qui existait. aux moment de la sortie squeez.
quand aux souci clavier énoncer par tetrix j’ai vu le miens rester allumer après l’arrêt de la machine.il c’est étin quand j’ai couper le courant.
il s’agit d’un clavier logitech g15 v2 . en usb je pense que quelque chose a été changer dans la relation bios/kernel si c est pas les micro-logiciel libre/non libre qui on été séparer du kernel…
je rappelle que parfois certain bios des portable son modifier pour éviter que les utilisateur y fasse des dégâts… tout les option n’y son pas forcement.
fran.b
met le en charge une fois fini. Place le dans un endroit ou il fait froid. (pas trop pour pas faire souffrir la batterie) puis une foit qui est a la meme température que la pièce,allume le . et étin le aussi sec
laisse le un bon moment 1 a 5 h. et pose la main aux dos de celui ci. si un coins est plus chaud que le reste c’est le coter ou il y a du courant. les 1 a 5h devrai suffire a ce que la chaleur du cpu soie de la même température que la pièce. Ou presque:) il suffi celon le coins de ce douter de partie en cause .disque,cm ,cg
voila pour les idées:)
Bon, échec complet pour le noyau 3.5.2 (j’ai rectifié 
). Je résume:
BIOS à jour, machine complètement opérationnelle, tout fonctionne parfaitement.
Module Size Used by
cpufreq_stats 12866 0
cpufreq_powersave 12454 0
cpufreq_conservative 13147 0
cpufreq_userspace 12576 0
parport_pc 22364 0
ppdev 12763 0
lp 17113 0
parport 31858 3 parport_pc,ppdev,lp
bnep 17577 2
rfcomm 33666 14
uinput 17479 1
fuse 62285 3
nfsd 198170 2
nfs 271103 0
lockd 55200 2 nfsd,nfs
fscache 36807 1 nfs
auth_rpcgss 29252 2 nfsd,nfs
nfs_acl 12511 2 nfsd,nfs
sunrpc 159322 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl
loop 22591 0
ath3k 12678 0
btusb 17470 0
bluetooth 148845 25 bnep,rfcomm,ath3k,btusb
dm_crypt 22586 0
dm_mod 63574 1 dm_crypt
snd_hda_codec_hdmi 30783 1
snd_hda_codec_realtek 50906 1
joydev 17266 0
uvcvideo 62689 0
videobuf2_core 25974 1 uvcvideo
videodev 88014 2 uvcvideo,videobuf2_core
media 18148 2 uvcvideo,videodev
videobuf2_vmalloc 12664 1 uvcvideo
videobuf2_memops 12526 1 videobuf2_vmalloc
arc4 12458 2
coretemp 12898 0
kvm_intel 117866 0
kvm 294470 1 kvm_intel
ath9k 78275 0
mac80211 331039 1 ath9k
snd_hda_intel 26504 2
snd_hda_codec 83533 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
acpi_cpufreq 12935 0
ath9k_common 12728 1 ath9k
snd_hwdep 13186 1 snd_hda_codec
ath9k_hw 315821 2 ath9k,ath9k_common
snd_pcm 64080 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
ath 21417 3 ath9k,ath9k_common,ath9k_hw
snd_seq 45130 0
i915 398799 4
microcode 25859 0
snd_timer 22917 2 snd_pcm,snd_seq
cfg80211 138839 3 ath9k,mac80211,ath
snd_seq_device 13176 1 snd_seq
psmouse 69266 0
evdev 17562 16
pcspkr 12595 0
drm_kms_helper 27228 1 i915
toshiba_acpi 17994 0
serio_raw 12980 0
drm 197822 5 i915,drm_kms_helper
lpc_ich 16665 0
sparse_keymap 12760 1 toshiba_acpi
mfd_core 12601 1 lpc_ich
snd 53077 13 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq,snd_timer,snd_seq_device
rfkill 19012 5 bluetooth,cfg80211,toshiba_acpi
soundcore 13026 1 snd
i2c_algo_bit 12841 1 i915
snd_page_alloc 12969 2 snd_hda_intel,snd_pcm
wmi 13243 1 toshiba_acpi
i2c_core 23919 5 videodev,i915,drm_kms_helper,drm,i2c_algo_bit
toshiba_bluetooth 12634 0
video 17629 1 i915
mperf 12453 1 acpi_cpufreq
battery 13109 0
ac 12624 0
button 12937 1 i915
processor 28393 1 acpi_cpufreq
ext4 361392 2
mbcache 13065 1 ext4
jbd2 71264 1 ext4
crc16 12343 2 bluetooth,ext4
sd_mod 36292 4
crc_t10dif 12348 1 sd_mod
xhci_hcd 73727 0
crc32c_intel 12747 0
ghash_clmulni_intel 12981 0
aesni_intel 50484 1
cryptd 14517 2 ghash_clmulni_intel,aesni_intel
aes_x86_64 16796 1 aesni_intel
aes_generic 33026 2 aesni_intel,aes_x86_64
ahci 24997 3
libahci 22820 1 ahci
libata 141139 2 ahci,libahci
scsi_mod 162270 2 sd_mod,libata
sdhci_pci 17894 0
sdhci 26993 1 sdhci_pci
ehci_hcd 40215 0
mmc_core 68635 2 sdhci_pci,sdhci
usbcore 128876 5 ath3k,btusb,uvcvideo,xhci_hcd,ehci_hcd
usb_common 12354 1 usbcore
thermal 17383 0
thermal_sys 18048 3 video,processor,thermal
e1000e 133732 0
Quand on arrête le PC, il y a une consommation correspondant à 0,6% de la batterie par heure soit 9,5Wh consommé soit en gros 40mA
Cela a lieu sous linux avec les noyaux 3.3 et 3.5 sous amd64, même si on supprime les modules du WIFI ou de la carte Ethernet avant. Le bluetooth est désactivé (soft), le WOL non activé (vérifié) avec option NETDOWN.
Cela n’a pas lieu sous Windows 7 et sous linux clefagreg (2.6.37 en 32 bits).
Dans ton rapport, je trouve
sparse_keymap 12760 1 toshiba_acpi
rfkill 19012 5 bluetooth,cfg80211,toshiba_acpi
mperf 12453 1 acpi_cpufreq
processor 28393 1 acpi_cpufreq
C’est toi qui a désactivé l’acpi toshiba ?
Les autres fonctions d’acpi serait donc celle du noyau ?
As-tu comparé le résultat de cette commande sur les deux noyaux ?
Edit: C’est quoi comme commande ?
Hum, à vue de nez il y a une nouvelle fonctionnalité WOWLAN qui serait le coupable idéal. Je vais voir si il y a une entrée dans le BIOS, l’utilitaire iw indique des commandes inconnues…
WOWLAN, c’est pour réveiller le PC par WIFI. La carte wifi doit reter sous tension.
Ton windows n’a pas cette fonction ?
Une fonctionnalité (Wake On Wifi) desactivée par défaut chez windows et activée chez linux?
Si tu trouves pas d’ici là, il suffit de l’activer sur windows et de voir si la batterie se vide.
La carte semble avoir des capacités de WOWLAN, or visiblement depuis le noyau 3.1, linux intègre petit à petit ces capacités. Cependant
phy0 wowlan disable
command failed: Operation not supported (-95)
donc le driver ath9k ne les inclut pas.
Du coup peut être qu’en arrêtant la machine puis en la redémarrant et arrêt manuel, ça devrait fonctionner. Sinon, il faut mettre le WOWLAN sur ath9k pour le désactiver (un comble)
Bon effectivement, un arrêt juste après le redémarrage de la machine lors du menu grub règle le souci. Pénible mais mieux que l’arrêt sous windows. Il faut donc compiler ath9k avec le support du WOWLAN pour pouvoir le désactiver… Ça ne vas pas être simple.
Salut fran.b,
je ne comprends pas la logique de ton raisonnement.
- Tu démarres le PC
- Tu l’éteins, et il continue de consommer
- Tu redémarres jusqu’à GRUB
- Tu l’éteins et il ne consomme plus
Quel rapport avec le WOWLAN ?
Comment GRUB le désactive ?
Je chercherai du coté de l’ACPI, par ex une option à passer au kernel
[quote=“piratebab”]Salut fran.b,
je ne comprends pas la logique de ton raisonnement.
- Tu démarres le PC
- Tu l’éteins, et il continue de consommer
- Tu redémarres jusqu’à GRUB
- Tu l’éteins et il ne consomme plus
Quel rapport avec le WOWLAN ?
Comment GRUB le désactive ?
Je chercherai du coté de l’ACPI, par ex une option à passer au kernel[/quote]
Je dirais une réinitialisation de la carte wifi au démarrage
Mais le fait de faire du WOWLAN 
tu m’étonne que ça vide une batterie 
Mais finalement ça a du sens avec les nouveaux portable / tablette qui n’ont plus de prise RJ45 