J'avais l'habitude d'avoir Fedora 14 installé sur ce HP Compaq 610, et la fonction de suspension a bien fonctionné. Maintenant que j'ai installé Scientific Linux 6.1, la suspension ne fonctionne plus. Comment le déboguer / le corriger?
J'avais l'habitude d'avoir Fedora 14 installé sur ce HP Compaq 610, et la fonction de suspension a bien fonctionné. Maintenant que j'ai installé Scientific Linux 6.1, la suspension ne fonctionne plus. Comment le déboguer / le corriger?
Réponses:
Il existe de nombreuses façons de gérer les capacités de suspension et d'hibernation, la plupart des anciennes méthodes sont obsolètes. Cela a rendu la recherche de solutions difficile, car il semble que chaque solution soit complètement indépendante de la suivante. Cela étant dit...
La méthode actuellement recommandée, préconisée à partir de http://pm-utils.freedesktop.org/wiki/ , devrait être disponible pour les distributions les plus récentes. Je voudrais d'abord vérifier si vous avez pm-utils
installé et si les commandes incluses fonctionnent comme prévu.
Voir si le package est installé, entrez cette commande dans le terminal
rpm -qa | grep pm-utils
Cela devrait produire la version que vous avez installée. Si vous n'obtenez pas la sortie attendue, vous devez installer le package.
sudo yum install pm-utils
Une fois que vous avez vérifié cela, testez votre capacité à suspendre.
sudo pm-suspend
Si vous ne suspendez pas et n'obtenez aucune sortie pourquoi, vérifiez la sortie récente de votre dmesg
dmesg | tail -50
Cela devrait vous aider à démarrer, une fois que vous obtenez des indices, il est beaucoup plus facile d'aller plus loin sur la piste. Postez en arrière avec des commentaires concernant vos résultats, je peux vous faire passer le reste.
dmesg
sortie vous dira ce qui se passe derrière la scène. Plus important encore, ce qui pourrait échouer en particulier. O et BTW, vous n'avez pas besoin du paquet devel. Vous n'en avez besoin que lors de la compilation du code, alors n'hésitez pas à purger. Il y a beaucoup de directions à partir d'ici, je ne vous envoie pas aboyer le mauvais arbre.
pm-suspend
commandes à partir d'un shell et non via le menu GNOME? Essayez en echo -n "mem" >/sys/power/state
tant que root. De plus, si vous utilisez, acpi
vous pouvez acpi_listen
voir quels événements sont générés, par exemple lors de la fermeture du couvercle.
Essayez ceci en tant que root:
PM_DEBUG=true pm-suspend
Vérifiez ensuite les /var/log/pm-suspend.log
indices sur ce qui pourrait mal tourner.
Si vous pouvez suspendre, mais ne pas reprendre, il y a un bon article sur le wiki Ubuntu sur la façon de déboguer ce problème.
Si vous ne souhaitez obtenir que lorsque vous avez suspendu / repris le système, vous pouvez essayer ceci:
cat /var/log/syslog | grep 'systemd-sleep' | grep "Suspending\|resumed";
Feb 7 10:44:23 dmatej-lenovo systemd-sleep[19900]: Suspending system...
Feb 7 10:44:33 dmatej-lenovo systemd-sleep[19900]: System resumed.
Feb 7 10:45:35 dmatej-lenovo systemd-sleep[20707]: Suspending system...
Feb 7 12:58:39 dmatej-lenovo systemd-sleep[20707]: System resumed.
Feb 7 14:42:55 dmatej-lenovo systemd-sleep[24690]: Suspending system...
Feb 7 16:31:57 dmatej-lenovo systemd-sleep[24690]: System resumed.
Comme le suggère Mika, en tant que root:
PM_DEBUG=true pm-suspend
Détails dans:
/var/log/pm-suspend.log
Dans ce cas, vous cherchez où
[...] service [servicename] suspend suspend success
se termine, et
[...] service [servicename] suspend resume success
commence. Quelque part entre les deux, vous pouvez trouver des appels renvoyant une erreur, moment auquel la suspension est inhibée. Dans ce cas, vous pouvez avoir suspendu les modifications en cours d'annulation. Déterminez quel appel de service génère l'erreur, ouvrez-le dans vi et jetez-y un œil.
J'ai eu le même problème où après l'installation xboxdrv
sur un Ubuntu 12.04, un appel en cours dans une règle /etc/pm/sleep.d/
essayait d'arrêter un service qui n'a jamais été démarré ou inexistant, dans ce cas xboxdrv
,. Il s'avère qu'il n'a jamais pu être démarré en premier lieu, car il n'y avait pas de /lib/modules/uinput.ko
module, car ce module est fusionné dans le noyau. Cela a provoqué l'instruction case /etc/pm/sleep.d/xboxdrv
à lancer une erreur lorsque la casse correspond à "suspend" à l'appel service xboxdrv stop
. Le fait de suspendre la ligne avec #
contourne l'instruction, au détriment de devoir débrancher et rebrancher votre contrôleur en mode suspension puis reprendre.