APM et ACPI font bien la même chose ? (Mise en veille et tout ça)
Je me demande lequel des deux modules il vaut mieux prendre, l'un
n'est-il pas deprécié ?
La page de man d'acipd est plus agée que celle d'apm mais acipd a l'air
plus puissant.
Dernier truc, j'envisage de patcher mon 2.4.24 avec le suspend-to-disk,
y-at-il des incompatibilités avec apm ou acpi.
Merci
--
> It looks as if noone with a 64 bit machine has gotten bitten by this yet
Well, in order to get bitten by this you have to have a 2-terabyte IDE
disk, so we don't have to worry about it for another few months..
-+- Linus in Guide du linuxien pervers - J'ai déjà entendu ça quelque part"
Le Wed, 28 Jan 2004 16:15:33 +0000, Samuel Colin a écrit:
C'est un ventilateur très précis et pointilleux, dans ce cas ;-).
Plus que moi alors ! :-)
Non, toujours du côté de l'acpi. Par exemple, le réglage des zones thermiques: :/proc/acpi/thermal_zone/TZ1$ cat trip_points critical (S5): 93 C passive: 91 C: tc1=1 tc2=2 tsp0 devices=0xc158b980 active[0]: 78 C: devices=0xc15f2880 active[1]: 72 C: devices=0xc15f29c0 active[2]: 67 C: devices=0xc15f2ac0 active[3]: 55 C: devices=0xc15f2bc0
# find /proc/acpi/thermal_zone/THRM/ -type f -exec echo "-------"{}"-------" ; -exec cat {} ; -------/proc/acpi/thermal_zone/THRM/polling_frequency------- <polling disabled> -------/proc/acpi/thermal_zone/THRM/cooling_mode------- <not supported> -------/proc/acpi/thermal_zone/THRM/trip_points------- critical (S5): 85 C -------/proc/acpi/thermal_zone/THRM/temperature------- temperature: 75 C -------/proc/acpi/thermal_zone/THRM/state------- state: ok
Je suis loin d'avoir ce que tu as.
Y'a toute une tripotée de fichiers à explorer dans /proc/acpi. Avec un dictionnaire d'anglais à côté si on a du mal.
Ben là, pas besoin de dico ;-)
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
En tout cas, tes problèmes ont l'air de se résoudre progressivement, c'est motivant :-).
N'est-ce pas ! :-) Maintenant, il ne me reste plus qu'à mettre le bon script. Comment on met l'écran en veille sous X déjà (pour le power)? Pour le suspend, je sais (pour le sleep). Par contre, pour le LID, je ne sais pas encore si je change quelque chose puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la dernière mouture, et je l'affecterai là aussi.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 28 Jan 2004 16:15:33 +0000, Samuel Colin a écrit:
C'est un ventilateur très précis et pointilleux, dans ce cas ;-).
Plus que moi alors ! :-)
Non, toujours du côté de l'acpi. Par exemple, le réglage des zones thermiques:
scolin@tyneth:/proc/acpi/thermal_zone/TZ1$ cat trip_points
critical (S5): 93 C
passive: 91 C: tc1=1 tc2=2 tsp0 devices=0xc158b980
active[0]: 78 C: devices=0xc15f2880
active[1]: 72 C: devices=0xc15f29c0
active[2]: 67 C: devices=0xc15f2ac0
active[3]: 55 C: devices=0xc15f2bc0
# find /proc/acpi/thermal_zone/THRM/ -type f -exec echo "-------"{}"-------" ; -exec cat {} ;
-------/proc/acpi/thermal_zone/THRM/polling_frequency-------
<polling disabled>
-------/proc/acpi/thermal_zone/THRM/cooling_mode-------
<not supported>
-------/proc/acpi/thermal_zone/THRM/trip_points-------
critical (S5): 85 C
-------/proc/acpi/thermal_zone/THRM/temperature-------
temperature: 75 C
-------/proc/acpi/thermal_zone/THRM/state-------
state: ok
Je suis loin d'avoir ce que tu as.
Y'a toute une tripotée de fichiers à explorer dans /proc/acpi. Avec un
dictionnaire d'anglais à côté si on a du mal.
Ben là, pas besoin de dico ;-)
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!!
Il faut installer acpi ET acpid !!
Argh.... ça s'invente pas !
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à
l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
En tout cas, tes problèmes ont l'air de se résoudre progressivement, c'est
motivant :-).
N'est-ce pas ! :-)
Maintenant, il ne me reste plus qu'à mettre le bon script.
Comment on met l'écran en veille sous X déjà (pour le power)?
Pour le suspend, je sais (pour le sleep).
Par contre, pour le LID, je ne sais pas encore si je change quelque chose
puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que
le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la
dernière mouture, et je l'affecterai là aussi.
Le Wed, 28 Jan 2004 16:15:33 +0000, Samuel Colin a écrit:
C'est un ventilateur très précis et pointilleux, dans ce cas ;-).
Plus que moi alors ! :-)
Non, toujours du côté de l'acpi. Par exemple, le réglage des zones thermiques: :/proc/acpi/thermal_zone/TZ1$ cat trip_points critical (S5): 93 C passive: 91 C: tc1=1 tc2=2 tsp0 devices=0xc158b980 active[0]: 78 C: devices=0xc15f2880 active[1]: 72 C: devices=0xc15f29c0 active[2]: 67 C: devices=0xc15f2ac0 active[3]: 55 C: devices=0xc15f2bc0
# find /proc/acpi/thermal_zone/THRM/ -type f -exec echo "-------"{}"-------" ; -exec cat {} ; -------/proc/acpi/thermal_zone/THRM/polling_frequency------- <polling disabled> -------/proc/acpi/thermal_zone/THRM/cooling_mode------- <not supported> -------/proc/acpi/thermal_zone/THRM/trip_points------- critical (S5): 85 C -------/proc/acpi/thermal_zone/THRM/temperature------- temperature: 75 C -------/proc/acpi/thermal_zone/THRM/state------- state: ok
Je suis loin d'avoir ce que tu as.
Y'a toute une tripotée de fichiers à explorer dans /proc/acpi. Avec un dictionnaire d'anglais à côté si on a du mal.
Ben là, pas besoin de dico ;-)
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
En tout cas, tes problèmes ont l'air de se résoudre progressivement, c'est motivant :-).
N'est-ce pas ! :-) Maintenant, il ne me reste plus qu'à mettre le bon script. Comment on met l'écran en veille sous X déjà (pour le power)? Pour le suspend, je sais (pour le sleep). Par contre, pour le LID, je ne sais pas encore si je change quelque chose puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la dernière mouture, et je l'affecterai là aussi.
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 28 Jan 2004 12:07:27 -0400, Christophe PEREZ a écrit:
Je sens que je suis près du but, mais il semble me manquer encore un petit quelque chose...
Réglé par l'installation de acpid en plus de acpi.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 28 Jan 2004 12:07:27 -0400, Christophe PEREZ a écrit:
Je sens que je suis près du but, mais il semble me manquer encore un
petit quelque chose...
Réglé par l'installation de acpid en plus de acpi.
Le Wed, 28 Jan 2004 10:58:53 -0400, Christophe PEREZ a écrit:
Qu'est-ce que tu as là-dedans (/etc/acpi/events/default) stp ?
J'ai trouvé, je cherchais le "%e" comme paramètre à passer au script
-- Christophe PEREZ Écrivez moi sans _faute !
Samuel Colin
Dans l'article , Christophe PEREZ a tapoté :
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc. Pas besoin d'acpid pour ça.
Ton problème lié à acpid était que les fichiers de config que tu avais écrits ne fonctionnaient pas : normal, il n'y avait pas le daemon pour "écouter" les événements. Et de toute façon, si acpid était en fonctionnement: - Tu n'aurais pas pu lire /proc/acpi/event : deux programmes ne peuvent pas accéder au même fichier en même temps (ici, ç'aurait été cat et acpid) - Tu aurais eu à redémarrer acpid après chaque modification de tes scripts (ben oui, pour qu'il relise la nouvelle configuration).
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités
(un spécialiste dans la salle?), acpi doit en faire partie.
N'est-ce pas ! :-) Maintenant, il ne me reste plus qu'à mettre le bon script. Comment on met l'écran en veille sous X déjà (pour le power)?
xset dpms force off Lancer "xset" pour avoir une vue rapide des options.
Pour le suspend, je sais (pour le sleep). Par contre, pour le LID, je ne sais pas encore si je change quelque chose puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la dernière mouture, et je l'affecterai là aussi.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai
vu que tu avais posté des erreurs de compilation sur la mailing-list).
-- Connaîtriez-vous une adresse où télécharger un mail bomber ? Ou bien si vous en avez un (assez simple), pouvez-vous me l' envoyer ? -+- Y.G. in <http://www.le-gnu.net> : NeunEu vA tOuT p3TeR -+-
Dans l'article <pan.2004.01.28.16.59.13.359430@novazur.fr>,
Christophe PEREZ a tapoté :
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!!
Il faut installer acpi ET acpid !!
Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc. Pas besoin d'acpid pour ça.
Ton problème lié à acpid était que les fichiers de config que tu avais
écrits ne fonctionnaient pas : normal, il n'y avait pas le daemon pour
"écouter" les événements. Et de toute façon, si acpid était en fonctionnement:
- Tu n'aurais pas pu lire /proc/acpi/event : deux programmes ne peuvent pas
accéder au même fichier en même temps (ici, ç'aurait été cat et acpid)
- Tu aurais eu à redémarrer acpid après chaque modification de tes scripts
(ben oui, pour qu'il relise la nouvelle configuration).
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à
l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités
(un spécialiste dans la salle?), acpi doit en faire partie.
N'est-ce pas ! :-)
Maintenant, il ne me reste plus qu'à mettre le bon script.
Comment on met l'écran en veille sous X déjà (pour le power)?
xset dpms force off
Lancer "xset" pour avoir une vue rapide des options.
Pour le suspend, je sais (pour le sleep).
Par contre, pour le LID, je ne sais pas encore si je change quelque chose
puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que
le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la
dernière mouture, et je l'affecterai là aussi.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai
vu que tu avais posté des erreurs de compilation sur la mailing-list).
--
Connaîtriez-vous une adresse où télécharger un mail bomber ?
Ou bien si vous en avez un (assez simple), pouvez-vous me l' envoyer ?
-+- Y.G. in <http://www.le-gnu.net> : NeunEu vA tOuT p3TeR -+-
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc. Pas besoin d'acpid pour ça.
Ton problème lié à acpid était que les fichiers de config que tu avais écrits ne fonctionnaient pas : normal, il n'y avait pas le daemon pour "écouter" les événements. Et de toute façon, si acpid était en fonctionnement: - Tu n'aurais pas pu lire /proc/acpi/event : deux programmes ne peuvent pas accéder au même fichier en même temps (ici, ç'aurait été cat et acpid) - Tu aurais eu à redémarrer acpid après chaque modification de tes scripts (ben oui, pour qu'il relise la nouvelle configuration).
Et l'option apm de ton bios doit signifier apm "en général" (contrairement à l'ancien apm), et donc acpi.
Bizarre alors car activé comme désactivé, même comportement.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités
(un spécialiste dans la salle?), acpi doit en faire partie.
N'est-ce pas ! :-) Maintenant, il ne me reste plus qu'à mettre le bon script. Comment on met l'écran en veille sous X déjà (pour le power)?
xset dpms force off Lancer "xset" pour avoir une vue rapide des options.
Pour le suspend, je sais (pour le sleep). Par contre, pour le LID, je ne sais pas encore si je change quelque chose puisque mon écran s'éteint déjà tout seul dans ce cas. J'attends que le swsusp soit stable j'ai là, j'ai encore pas mal de pb avec la dernière mouture, et je l'affecterai là aussi.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai
vu que tu avais posté des erreurs de compilation sur la mailing-list).
-- Connaîtriez-vous une adresse où télécharger un mail bomber ? Ou bien si vous en avez un (assez simple), pouvez-vous me l' envoyer ? -+- Y.G. in <http://www.le-gnu.net> : NeunEu vA tOuT p3TeR -+-
Christophe PEREZ
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc.
Ben oui mais ce n'était pas une problème de reconnaissance du clavier pour que mon script soit exécuté, juste que rien n'était à l'écoute du clavier. Le reste, j'ai bien compris cette fois.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités (un spécialiste dans la salle?), acpi doit en faire partie.
Ça semble clair ;-)
xset dpms force off Lancer "xset" pour avoir une vue rapide des options.
Oui, j'ai trouvé ça entre temps, mais ce que je ne comprends pas ce que le mettre dans mon script ne donne rien alors que dans un terminal ça passe. Je ne vois pas où je fais l'erreur. Pas dans le script puisque j'ai mis des traces et que j'arrive bien jusqu'à ce point.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai vu que tu avais posté des erreurs de compilation sur la mailing-list).
Franchement, j'aimerais bien mais : 1) j'ai déjà tellement de mal à comprendre tout ce qui s'y écrit 2) d'après le peu que j'en comprends, il a encore des problèmes au resume avec l'agp et le dri. 3) j'ai beaucoup de mal à cerner moi même où, quand et comment apparaissent les problèmes, et surtout à les exprimer, alors en anglais...
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!!
Il faut installer acpi ET acpid !!
Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc.
Ben oui mais ce n'était pas une problème de reconnaissance du clavier
pour que mon script soit exécuté, juste que rien n'était à l'écoute
du clavier.
Le reste, j'ai bien compris cette fois.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités
(un spécialiste dans la salle?), acpi doit en faire partie.
Ça semble clair ;-)
xset dpms force off
Lancer "xset" pour avoir une vue rapide des options.
Oui, j'ai trouvé ça entre temps, mais ce que je ne comprends pas ce que
le mettre dans mon script ne donne rien alors que dans un terminal ça
passe. Je ne vois pas où je fais l'erreur. Pas dans le script puisque
j'ai mis des traces et que j'arrive bien jusqu'à ce point.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai
vu que tu avais posté des erreurs de compilation sur la mailing-list).
Franchement, j'aimerais bien mais :
1) j'ai déjà tellement de mal à comprendre tout ce qui s'y écrit
2) d'après le peu que j'en comprends, il a encore des problèmes au
resume avec l'agp et le dri.
3) j'ai beaucoup de mal à cerner moi même où, quand et comment
apparaissent les problèmes, et surtout à les exprimer, alors en anglais...
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Ben dans ce cas, c'était un problème de reconnaissance clavier.
Non; pire que ça !!! Il faut installer acpi ET acpid !! Argh.... ça s'invente pas !
Non, là tu espionnais le fichier event de /proc.
Ben oui mais ce n'était pas une problème de reconnaissance du clavier pour que mon script soit exécuté, juste que rien n'était à l'écoute du clavier. Le reste, j'ai bien compris cette fois.
Je crois que Linux prend le pas sur le bios pour pas mal de fonctionnalités (un spécialiste dans la salle?), acpi doit en faire partie.
Ça semble clair ;-)
xset dpms force off Lancer "xset" pour avoir une vue rapide des options.
Oui, j'ai trouvé ça entre temps, mais ce que je ne comprends pas ce que le mettre dans mon script ne donne rien alors que dans un terminal ça passe. Je ne vois pas où je fais l'erreur. Pas dans le script puisque j'ai mis des traces et que j'arrive bien jusqu'à ce point.
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai vu que tu avais posté des erreurs de compilation sur la mailing-list).
Franchement, j'aimerais bien mais : 1) j'ai déjà tellement de mal à comprendre tout ce qui s'y écrit 2) d'après le peu que j'en comprends, il a encore des problèmes au resume avec l'agp et le dri. 3) j'ai beaucoup de mal à cerner moi même où, quand et comment apparaissent les problèmes, et surtout à les exprimer, alors en anglais...
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai vu que tu avais posté des erreurs de compilation sur la mailing-list).
Tiens, comme mon bouton power qui est in-efficient au retour de l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai
vu que tu avais posté des erreurs de compilation sur la mailing-list).
Tiens, comme mon bouton power qui est in-efficient au retour de
l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
Le Wed, 28 Jan 2004 21:39:40 +0000, Samuel Colin a écrit:
Si tu as la possibilité d'aider l'auteur à débugger, 'faut pas hésiter (j'ai vu que tu avais posté des erreurs de compilation sur la mailing-list).
Tiens, comme mon bouton power qui est in-efficient au retour de l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 28 Jan 2004 19:42:51 -0400, Christophe PEREZ a écrit:
Tiens, comme mon bouton power qui est in-efficient au retour de l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
Bon, compte rendu des courses, mais affaire loin d'être close à mon humble avis ;-)
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup au retour.
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep) mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu l'inverse du pb initial)
3) Pour qu'une connexion usb ne me plante pas le pc après le resume, il me faut décharger plus recharger (dans l'ordre inverse) les modules : usb-storage ehci-hcd usb-uhci sr_mod ide-scsi scsi_mod sd_mod
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement (mis à part qu'il croit le dri activé et donc que n'importe quelle appli qui y fait appel plante).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch de la dernière mise à jour 20040116, le branchement et débranchement du secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il que moi même que je sache avant) il me faut décharger/rechercher les modules ac et battery. Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Si quelqu'un a des idées pour tenter de résoudre les points 4 et 5, ça serait merveilleux car là, entre pouvoir faire un suspend-to-disk et être au courant de l'état d'alimentation de mon portable, il n'y a pas photo.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 28 Jan 2004 19:42:51 -0400, Christophe PEREZ a écrit:
Tiens, comme mon bouton power qui est in-efficient au retour de
l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
Bon, compte rendu des courses, mais affaire loin d'être close à mon
humble avis ;-)
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut
pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup
au retour.
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne
faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep)
mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus
que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu
l'inverse du pb initial)
3) Pour qu'une connexion usb ne me plante pas le pc après le resume, il
me faut décharger plus recharger (dans l'ordre inverse) les modules :
usb-storage ehci-hcd usb-uhci sr_mod ide-scsi scsi_mod sd_mod
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement
(mis à part qu'il croit le dri activé et donc que n'importe quelle appli
qui y fait appel plante).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch
de la dernière mise à jour 20040116, le branchement et débranchement du
secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange
le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il
que moi même que je sache avant) il me faut décharger/rechercher les
modules ac et battery.
Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Si quelqu'un a des idées pour tenter de résoudre les points 4 et 5, ça
serait merveilleux car là, entre pouvoir faire un suspend-to-disk et
être au courant de l'état d'alimentation de mon portable, il n'y a pas
photo.
Le Wed, 28 Jan 2004 19:42:51 -0400, Christophe PEREZ a écrit:
Tiens, comme mon bouton power qui est in-efficient au retour de l'hibernate. Par contre, le LID et le SLEEP fonctionnent toujours.
Allez, je vais me fendre d'un message du la mailing.
Bon, compte rendu des courses, mais affaire loin d'être close à mon humble avis ;-)
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup au retour.
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep) mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu l'inverse du pb initial)
3) Pour qu'une connexion usb ne me plante pas le pc après le resume, il me faut décharger plus recharger (dans l'ordre inverse) les modules : usb-storage ehci-hcd usb-uhci sr_mod ide-scsi scsi_mod sd_mod
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement (mis à part qu'il croit le dri activé et donc que n'importe quelle appli qui y fait appel plante).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch de la dernière mise à jour 20040116, le branchement et débranchement du secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il que moi même que je sache avant) il me faut décharger/rechercher les modules ac et battery. Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Si quelqu'un a des idées pour tenter de résoudre les points 4 et 5, ça serait merveilleux car là, entre pouvoir faire un suspend-to-disk et être au courant de l'état d'alimentation de mon portable, il n'y a pas photo.
-- Christophe PEREZ Écrivez moi sans _faute !
Samuel Colin
Dans l'article , Christophe PEREZ a tapoté :
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup au retour.
Curieux. 'fin bon, si ça marche...
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep) mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu l'inverse du pb initial)
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais
je crois qu'il faudra passer au 2.6 pour bénéficier des futures améliorations au niveau de la gestion d'énergie des divers périphériques.
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement (mis à part qu'il croit le dri activé et donc que n'importe quelle appli qui y fait appel plante).
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu
vas en baver :-).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch de la dernière mise à jour 20040116, le branchement et débranchement du secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il que moi même que je sache avant) il me faut décharger/rechercher les modules ac et battery. Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Cherche les différences dans ton .config. Tu devrais facilement pouvoir
récupérer celui de la mandrake.
-- | tu es décidemment trop rapide... ;-) Bah, dès que je voie un truc interessant, je m'en occupe de suite, sinon, après, j'oublie :) -+- TN in GFA : RAM défaillante ... -+-
Dans l'article <pan.2004.02.02.05.07.46.782996@novazur.fr>,
Christophe PEREZ a tapoté :
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut
pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup
au retour.
Curieux. 'fin bon, si ça marche...
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne
faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep)
mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus
que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu
l'inverse du pb initial)
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais
je crois qu'il faudra passer au 2.6 pour bénéficier des futures
améliorations au niveau de la gestion d'énergie des divers périphériques.
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement
(mis à part qu'il croit le dri activé et donc que n'importe quelle appli
qui y fait appel plante).
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu
vas en baver :-).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch
de la dernière mise à jour 20040116, le branchement et débranchement du
secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange
le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il
que moi même que je sache avant) il me faut décharger/rechercher les
modules ac et battery.
Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Cherche les différences dans ton .config. Tu devrais facilement pouvoir
récupérer celui de la mandrake.
--
| tu es décidemment trop rapide... ;-)
Bah, dès que je voie un truc interessant, je m'en occupe de
suite, sinon, après, j'oublie :)
-+- TN in GFA : RAM défaillante ... -+-
1) Tout d'abord, pour avoir mon réseau au retour du suspend, il ne faut pas que je mette l'interface réseau eth0 down, mais que je fasse un ifup au retour.
Curieux. 'fin bon, si ça marche...
2) Pour avoir tous mes boutons (acpi) toujours actifs au resume, il ne faut pas que je suspende avec le mode acpi (echo 4 > /proc/acpi/sleep) mais en mode swsusp (echo > /proc/swsusp/activate), sinon, je n'avais plus que mon bouton power et plus ni lid ni sleep (oui, je sais c'était devenu l'inverse du pb initial)
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais
je crois qu'il faudra passer au 2.6 pour bénéficier des futures améliorations au niveau de la gestion d'énergie des divers périphériques.
4) Au resume, je n'ai plus de dri activée, mais X fonctionne correctement (mis à part qu'il croit le dri activé et donc que n'importe quelle appli qui y fait appel plante).
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu
vas en baver :-).
5) Avec l'acpi d'origine (20031002) du noyau 2.4.24 comme avec le patch de la dernière mise à jour 20040116, le branchement et débranchement du secteur n'est pas vu par ma machine (Et c'est le problème qui me dérange le plus actuellement). Pour qu'elle s'en rende compte (mais encore faut-il que moi même que je sache avant) il me faut décharger/rechercher les modules ac et battery. Or, je n'avais pas ce problème avec le noyau standard de la mandrake 9.1.
Cherche les différences dans ton .config. Tu devrais facilement pouvoir
récupérer celui de la mandrake.
-- | tu es décidemment trop rapide... ;-) Bah, dès que je voie un truc interessant, je m'en occupe de suite, sinon, après, j'oublie :) -+- TN in GFA : RAM défaillante ... -+-
Christophe PEREZ
Le Mon, 02 Feb 2004 18:50:56 +0000, Samuel Colin a écrit:
Curieux. 'fin bon, si ça marche...
J'en ai ensuite lu la confirmation sur la mailing list.
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais je crois qu'il faudra passer au 2.6 pour bénéficier des futures améliorations au niveau de la gestion d'énergie des divers périphériques.
Pfff... j'ai essayé une fois de compiler un 2.6.1, mais rien compris au modules-init-machin. Du coup, comme déjà dit ici, ça bootait, mais 1) j'avais un écran noir tant que X n'était pas lancé 2) l'ouverture d'une session graphique était impossible, erreur gnome...
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu vas en baver :-).
Même pas, c'est du intel, mais ça suffit pour en baver ;-)
Cherche les différences dans ton .config. Tu devrais facilement pouvoir récupérer celui de la mandrake.
Oui, mais le pb, c'est que même en bootant avec le noyau mdk maintenant, aucun évènement concernant le ac_adapter ou battery n'est envoyé. J'ai du me résoudre à faire tourner un script en tâche de fond, qui va régulièrement regarder l'état de charge de la batterie, charging ou discharging, et son pourcentage de charge, afin de lancer les opérations nécessaires ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 02 Feb 2004 18:50:56 +0000, Samuel Colin a écrit:
Curieux. 'fin bon, si ça marche...
J'en ai ensuite lu la confirmation sur la mailing list.
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais
je crois qu'il faudra passer au 2.6 pour bénéficier des futures
améliorations au niveau de la gestion d'énergie des divers périphériques.
Pfff... j'ai essayé une fois de compiler un 2.6.1, mais rien compris au
modules-init-machin.
Du coup, comme déjà dit ici, ça bootait, mais 1) j'avais un écran noir
tant que X n'était pas lancé 2) l'ouverture d'une session graphique
était impossible, erreur gnome...
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu
vas en baver :-).
Même pas, c'est du intel, mais ça suffit pour en baver ;-)
Cherche les différences dans ton .config. Tu devrais facilement pouvoir
récupérer celui de la mandrake.
Oui, mais le pb, c'est que même en bootant avec le noyau mdk maintenant,
aucun évènement concernant le ac_adapter ou battery n'est envoyé.
J'ai du me résoudre à faire tourner un script en tâche de fond, qui va
régulièrement regarder l'état de charge de la batterie, charging ou
discharging, et son pourcentage de charge, afin de lancer les opérations
nécessaires ;-)
Le Mon, 02 Feb 2004 18:50:56 +0000, Samuel Colin a écrit:
Curieux. 'fin bon, si ça marche...
J'en ai ensuite lu la confirmation sur la mailing list.
Apparemment l'interconnexion acpi<->swsusp n'est pas encore au point. Mais je crois qu'il faudra passer au 2.6 pour bénéficier des futures améliorations au niveau de la gestion d'énergie des divers périphériques.
Pfff... j'ai essayé une fois de compiler un 2.6.1, mais rien compris au modules-init-machin. Du coup, comme déjà dit ici, ça bootait, mais 1) j'avais un écran noir tant que X n'était pas lancé 2) l'ouverture d'une session graphique était impossible, erreur gnome...
Encore des problèmes de module, je pense. Et si c'est les drivers nvidia, tu vas en baver :-).
Même pas, c'est du intel, mais ça suffit pour en baver ;-)
Cherche les différences dans ton .config. Tu devrais facilement pouvoir récupérer celui de la mandrake.
Oui, mais le pb, c'est que même en bootant avec le noyau mdk maintenant, aucun évènement concernant le ac_adapter ou battery n'est envoyé. J'ai du me résoudre à faire tourner un script en tâche de fond, qui va régulièrement regarder l'état de charge de la batterie, charging ou discharging, et son pourcentage de charge, afin de lancer les opérations nécessaires ;-)
