Exactement, je pense que Windows 7 ignore cette fonctionalité et linux commence à l’intégrer. Le fait qu’après un arrêt Windows, il n’y ait pas de souci fait que le BIOS désactive ce bazar au démarrage et c’est le noyau linux qui le remet d’où cette idée de redémarrer la machine pour l’arrêter immédiatement. Ça semble marcher (gros test cette nuit).
Par contre je n’arrive pas à trouver un patch WOW pour ath9k fonctionnel…
Et ça voudrait dire que GRUB réinitialise la carte ?
Non, le BIOS. Une fois le système démarré, le BIOS la met dans l’état standard. Mais je vais refaire le test ce soir.
je suis le topic depuis le début et il y a un truc que je ne comprend pas.
si je ne dit pas de sottise ( a l’heur qu’il est ou j’écris c’est vendredi donc un peu d’indulgence^^) le wow ou wol est géré par le bios jusque la nous somme d’accord je pense?
donc, si cela est géré par le bios que l’ont éteigne la machine sous Debian ou windows ne devrait rien changer à ceci, et ce même si le noyaux intègre cette fonctionnalité…
ou alors j’ai raté un épisode, ce qui est fort possible je l’admet vu l’heure tardive…
Je ne pense pas que le wowlan soit géré par le BIOS
wireless.kernel.org/en/users/Doc … ion/WoWLAN
Cela ne fonctionne que si le PC est en mode S3.
Le WOWLAN ou le WOLAN réveille la machie si un ppaquet dit paquet magique est reçu par la machine. Le BIOS est capable de ce réveil mais c’est le système d’exploitation qui met la machine dans un état où la carte réseau reste alimentée et à l’écoute.
Je confirme la technique de redémarrage puis arrêt manuel au menu de grub…
Oui, mais à condition quelle soit en mode S3, c’est à dire pas toute à fait éteinte.
Tu devrais chercher du coté de l’ACPI , ou de ta façon d’éteindre l’ordinateur, plutôt que du coté du driver wifi.
Il me semble que les modes Sx concerne l’ordianteur lui même (S3 étant l’hibernation), pour les périphériques, cela s’appelle plutôt Dx: de D0 (allumé) à D3 (extinction complète). Ce serait un mode D2 ou D1. Par exemple, chez moi j’ai
[ 0.223913] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
[ 0.224061] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[ 0.224212] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[ 0.224336] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.224500] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.224679] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
[ 0.224807] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[ 0.224966] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[ 0.225249] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.225690] pci 0000:01:00.0: supports D1 D2
[ 0.225692] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.234990] pci 0000:02:00.0: supports D1
[ 0.234992] pci 0000:02:00.0: PME# supported from D0 D1 D3hot
[ 0.242761] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
(D3hot et cold doivent préparer le démarrage à venir). La carte WIFI étant la 02:00.0, j’en ai déduit qu’elle serait en mode D1. Sur lspci -vv, je lis
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3h
ot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Ce qui est plus précis.
Je cherche où modifier ça mais je n’ai rien vu au niveau de l’ACPI.
Rq: C’est vai que dans ce cas, la machine edevrait être en mode S3 et non arrêt complet mais comme le WOWLAN n’est pas activé, ça n’est pas sûr…
Et en regardant du coté de acpitool et des fonctions de wakeup ?
[code]-w Show the wakeup capable devices. (Available since ACPI 20040715, check your version).
-W x Enable/disable wakeup capable device x. Run ‘acpitool -w’ to see valid numbers for x. Requires write access to /proc/acpi/wakeup
J’y avais pensé mais
Je n’ai pas fini avec cette histoire. Lisez le fil
http://lists.debian.org/debian-user-french/2012/08/msg00164.html
Mon dernier message est lesuivant:
Le noyau 3.5.4 que j’utilise est un noyau à ma sauce ainsi que tous les autres,
3.2.0-2, 3.2.0-3 et 3.3.0 utilisés: Voilà la liste complète des paquets que j’ai utilisé (en plus
des noyaux wheezy 3.2.0-2 et 3.2.0-3). Un seul vient des dépots debian.
francois@portos:~/Noyaux$ uname -r
3.5.4-fb-aufs
francois@portos:~/Noyaux$ ls linux-image*deb
linux-image-3.0.41-fb_3.0.41-fb_amd64.deb
linux-image-3.2.28-fb_3.2.28-fb_amd64.deb
linux-image-3.3.0-rc6-amd64_3.3~rc6-1~experimental.1_amd64.deb
linux-image-3.5.2_3.5.2-FB_amd64.deb
linux-image-3.5.2–fb-aufs_3.5.2–fb-aufs_amd64.deb
linux-image-3.5.4-fb-aufs_3.5.4-fb-aufs_amd64.deb
francois@portos:~/Noyaux$
(il manque le3.1)
Sinon 2 choses:
Le problème existe aussi sur un TOSHIBA Satellite A500/KSKAA, BIOS V1.30
09/04/2009è. Ce n’est donc passeulement sur un portege. La perte a été de 6%
de la batterie en une nuit. Je n’ai pas souvenir d’un tel problème avec une
lenny sur ce même portable (il n’avait aucun souci à tenir un mois sans être
utilisé, batterie dans le portable).
Si je fait un shutdown -h -H now
puis que j’éteints la machine (appui long sur le marche/arrêt), ma machine ne
consomme plus. C’est donc réellement un problème spécifique au power_off des
noyaux 3.x…
C’est un problème du noyau linux. Je n’en suis plus à une recompilation du
noyau près, donc à mettre des printk partout. Visiblement c’est au niveau de
arch/x86/kernel/reboot.c et arch/x86/kernel/apm_32.c, mais je n’arrive pas à
voir comment dialoguer avec le bios. Cela se fait via apm_bios_call_mais
francois@portos:~/linux-3.5.4$ grep -r apm_bios_call Documentation/*
francois@portos:~/linux-3.5.4$
Nulle part je n’ai vu des descriptions sur les fonctions du BIOS, on a une
vague liste dans include/linux/apm_bios.h mais j’ai vraiment l’impression de
réinventer la roue à faire ce travail d’analyse de code sur le noyau linux. Il
y a eu 1200 messages sur la liste linux-kernel depuis le mien et aucune
réponse. Qu’on me donne juste une doc à lire sur ce foutu BIOS et je me
débrouillerai mais là, au rythme où j’avance le problème sera résolu dans 2
ans et 1/2 (encore qu’en rédigeant ce message, j’ai trouvé le fichier
include/linux/apm_bios.h (je suis étonné que ça ne dépende pas de
l’architecture mais bon…)).
À suivre donc mais bonnes volontés acceptées…
En attendant mieux, j’enlève la batterie lors d’une extinction prolongée.
Un petit up.
Lu ici
linuxquestions.org/questions … 175429035/
même problème de batterie qui se décharge PC éteint, il a un TOSHIBA QOSMIO F755 (voir les liens pastebin) avec une Gentoo dessus.
d’après ses tests, le bug ne se reproduirait pas sous Ubuntu!
(c’est pas un troll hein! 
)
Vraiment intéressant, le bug ne serait pas du au noyau mais à une configuration de l’ACPI. Je vais essayer de comparer les configurations…
Bon j’ai adapté l’ACPI de Ubuntu sur debian, ça ne change rien (paquets acpi, paci-support et acpid). Je vais voir du coté du shutdown…
Et si tu essayai le bon vieux APM ?
tldp.org/HOWTO/Battery-Powered/p … l#WHICHONE
ou démarrer avec l’option noacpi
J’ai eu confirmation que ce problème n’existait pas sous Ubuntu precise. C’est donc une histoire de scripts, configuration ou logiciel. Je pensais dans les scripts d’acpi mais que dalle. Peut être sysvinit?? Je vais basculer sur le sysvinit de squeeze qui est la même version que celui de precise
Comme je sens que cette histoire vous passionne, je continue…
Je commence à éplucher les différences Ubuntu/Debian. Ces crétins pourraient se mettre d’accord sur le découpage des paquets ça simplifierait les choses mais passons, on y arrive quand même en bidouillant.
L’installation de l’ACPI de Ubuntu/precise est un échec notoire. Le remplacement du sysvinit wheezy par celui de squeeze aussi. En cherchant les sources de shutdown, je me suis aperçu d’un remplaçant en cours de sysvint: upstart. Donc nouveau test avec ça (chaque test durant au moins 4 heures, il faut les choisir avec soin). Feuilleton passionnant à suivre donc …
Pour ma part je vais installer (temporairement!) une (X)Ubuntu sur ma machine pour vérifier la chose 