Kiedyś miałem Fedorę 14 zainstalowaną na tym HP Compaq 610, a funkcja zawieszenia działała dobrze. Teraz, gdy zainstalowałem Scientific Linux 6.1 zawieszenie nie działa. Jak to debugować / naprawić?
Kiedyś miałem Fedorę 14 zainstalowaną na tym HP Compaq 610, a funkcja zawieszenia działała dobrze. Teraz, gdy zainstalowałem Scientific Linux 6.1 zawieszenie nie działa. Jak to debugować / naprawić?
Odpowiedzi:
Istnieje wiele sposobów obsługi funkcji zawieszenia i hibernacji, wiele starych metod jest przestarzałych. Utrudniło to poszukiwanie rozwiązań, ponieważ wydaje się, że każde rozwiązanie jest całkowicie niezwiązane z następnym. Powiedziawszy to ...
Metoda obecnie zalecana, zalecana na stronie http://pm-utils.freedesktop.org/wiki/ , powinna być dostępna dla najnowszych dystrybucji. Najpierw sprawdzę, czy masz pm-utils
zainstalowany i czy zawarte w nim polecenia działają zgodnie z oczekiwaniami.
Sprawdź, czy pakiet jest zainstalowany, wpisz to polecenie w terminalu
rpm -qa | grep pm-utils
To powinno wypisać zainstalowaną wersję. Jeśli nie otrzymasz oczekiwanego wyniku, musisz zainstalować pakiet.
sudo yum install pm-utils
Po zweryfikowaniu sprawdź swoją zdolność do zawieszenia.
sudo pm-suspend
Jeśli nie zawieszasz i nie otrzymujesz danych wyjściowych, sprawdź ostatnie wyjście dmesg
dmesg | tail -50
To powinno pomóc w rozpoczęciu pracy, gdy zdobędziesz jakieś wskazówki, znacznie łatwiej pójdziesz dalej szlakiem. Odpowiedz z komentarzami na temat twoich wyników, mogę przeprowadzić cię przez resztę.
dmesg
Wyjście powie, co dzieje się za sceną. Co ważniejsze, co w szczególności może zawieść. O i BTW, nie potrzebujesz pakietu deweloperskiego. Potrzebujesz ich tylko podczas kompilacji kodu, więc możesz je wyczyścić. Stąd jest wiele kierunków, po prostu nie wysyłam was do szczekania niewłaściwego drzewa.
pm-suspend
polecenia z powłoki, a nie z menu GNOME? Spróbuj echo -n "mem" >/sys/power/state
jako root. Również jeśli używasz acpi
, możesz acpi_listen
sprawdzić, jakie zdarzenia są generowane, np. Po zamknięciu pokrywy.
Spróbuj tego jako root:
PM_DEBUG=true pm-suspend
Następnie sprawdź /var/log/pm-suspend.log
wskazówki, co może pójść nie tak.
Jeśli możesz zawiesić, ale nie wznowić, na stronie wiki Ubuntu znajduje się dobry artykuł na temat debugowania tego problemu.
Jeśli chcesz uzyskać tylko po zawieszeniu / wznowieniu systemu, możesz spróbować:
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.
Jak sugeruje Mika, jako root:
PM_DEBUG=true pm-suspend
Szczegóły w:
/var/log/pm-suspend.log
W tym przypadku szukasz miejsca
[...] service [servicename] suspend suspend success
kończy się i
[...] service [servicename] suspend resume success
zaczyna się. Gdzieś pośrodku możesz znaleźć błąd zwracania połączeń, w którym to momencie zawieszenie jest wstrzymane. W takim przypadku możesz zawiesić wycofywanie zmian. Dowiedz się, jakie zgłoszenie serwisowe powoduje błąd, otwórz go w vi i spójrz na to.
Miałem ten sam problem, gdy po zainstalowaniu xboxdrv
na Ubuntu 12.04 wywołanie w regule /etc/pm/sleep.d/
próbowało zatrzymać usługę, która nigdy nie została uruchomiona lub nie istniała, w tym przypadku xboxdrv
. Okazuje się, że nigdy nie można go było uruchomić, ponieważ nie było /lib/modules/uinput.ko
modułu, ponieważ moduł ten został scalony z jądrem. Spowodowało to, że instrukcja case /etc/pm/sleep.d/xboxdrv
zgłasza błąd, gdy pasuje do „zawiesić” połączenie service xboxdrv stop
. Przygotowanie linii z #
pominięciem instrukcji kosztem odłączenia i ponownego podłączenia kontrolera po zawieszeniu, a następnie wznowieniu.