Hibernacja przez /sys/power/state w KPowerSave
KPowerSave umożliwia pełne zarządzanie energią w środowisku graficznym KDE. Niestety, od czasu przejścia na dbus są z nim same problemy. Jeden z nich opisałem niedawno, dziś odkryłem kolejny. KPowerSave nie do końca potrafi jeszcze rozmawiać z pm-suspend odcinając w skuteczny sposób użytkownika od możliwości hibernacji (wstrzymania do RAM) swojego laptopa.
Na początek jednak odrobina teorii. W zamierzchłych czasach jądra 2.4.xx do usypiania komputera służył interfejs /proc/acpi/sleep. Jako że od pewnego czasu /proc jest zastępowany przez /sys, obsługę usypiania przejął interfejs /sys/power/state. Niestety, nie wszystkie aplikacje zdążyły przejść na nowy standard a na dodatek powstało zamieszanie wokół HALd oraz Dbus o to, które czym ma się zajmować. W konsekwencji końcowy użytkownik dostał kilka porządnie napisanych aplikacji, kilka wrapperów zapytań, kilka źle napisanych aplikacji i kilka żałosnych skryptów, które powinny działać a (czasem) nie działają. Do dobrych aplikacji można zaliczyć pm-utils, które w zamierzeniu mają zajmować się komunikacją z HAL i całkowicie obsłużyć zarządzanie energią w laptopach. Niestety - komunikacja z pm-utils w przypadku KPowerSave opiera się na okropnie napisanych skryptach ( /usr/lib/hal/scripts/linux/ ), które nie zawsze działają (w moim przypadku 2 na 3 komputery nie usypiały się). Jeśli mamy pecha i KPowerSave niezbyt chce usypiać nasz komputer musimy zadbać o to sami.
Włączamy konsolkę i wklepuje bezwiednie:
# cd /usr/sbin # mv pm-suspend pm-suspend.old # touch pm-suspend # chmod +x pm-suspend # nano -w pm-suspend
Do pliku dopisujemy:
#!/bin/bash echo mem > /sys/power/state
I to tyle. Zdaję sobie sprawę że jest to bardzo brzydkie, jednak naprawdę to działa, w przeciwieństwie do obecnego stanu pm-utils... Rozwiązanie zostało sprawdzone na Debian Testing oraz Debian Unstable. Nie wiem jak ma się sprawa w innych dystrybucjach.
Na potwierdzenie problemu - garść linków: 1 2 3 4
Jak widać problem dotyczy nie tylko Debiana a także PLD, Mandrivy, Archa oraz Mepisa. Czasem się zastanawiam czy zmiany które obecnie widzimy w jądrze linuksa są aby na pewno dobre?
Witam
A jaką wersję KPowerSave używasz?
W tym momencie nie mogę sprawdzić jaką dokładnie mam skompilowaną, ale było to coś w okolicach 7.2.
Pomijając problemy z samym "suspend to disk" (zwisy przy "Doing atomic cache"), to program działa bardzo dobrze.
Suspend/Hibernate, podpinanie zdarzeń pod skróty (choć ma pewien problem z przyciskiem "Power"), zarządzanie tektowaniem procka - działą.
Pozdrawiam
heh to u mnie jest ten sam problem, później sprawdzę czy Twoje rozwiązanie działa...
Podobną kaszanę miałem ostatnio z networkmanger, a teraz z wicd. O ile wicd sprawia ze moge normalnie się połączyć z siecią bezprzewodową, o tyle jego gui na to mi nie pozwala i muszę się łączyć ręcznie ;]
@radmen: u mnie Kwifimanager odstawiał takie cyrki, że używam go już tylko do przechowywania essidów i haseł do sieci, z których korzystam, zaś samego wifika odpalam z palca ;)
Wracając do tematu - po ostatnim emerge world pozbyłem się opcji "hibernate" w KPowerSave - i ni huhu nie wiem dlaczego :/ Ale wcześniej wszystko działało bardzo dobrze (sam "Suspend to RAM" wciąż śmiga, bez żadnych problemów).
U mnie to nie pomogło, ale mam dość nietypowy problem. Otóż po uśpieniu, normalnie miga przerywanym żółtym światłem dioda od sygnalizacji stanu laptopa, jednak po naciśnięciu dowolnego klawisza mam coś takiego:
1. Przełączenie diody na kolor zielony (tak, jak włączony).
2. 2-3 sekundy próby jakiegoś mielenia dyskiem.
3. Nagłe wyłączenie się laptopa, i po 10-15 sekundach włączenie, ale tylko diody sygnalizacyjnej oraz wentylatora, nic innego się nie dzieje.
Co ciekawe, w Mandriva 2007.1 działało to bez problemu, po aktualizacji do 2008.0 już nie. Próbowałem już wszystkich kombinacji komendy s2ram z wiki, ale nie pomogło.
@MiB:
wersja KPowerSave: 0.7.3
Powersaved: 0.14.0
Na niektórych platformach sprzętowych suspend2ram przez KPowerSave działa od ręki, na niektórych nie chce ruszyć za żadne skarby. W moim przypadku jak napisałem działało na 1 z 3 kompów jakie mam.
@Dandys - znany problem. Spotkałem się z nim dzisiaj. Używasz "złego skryptu" do suspenda. Jest kilka różnych implementacji np. z użyciem czystego ACPI, z użycie HAL, z użyciem /sys itd itp. Musisz spróbować czegoś innego.
Tylko zamieszanie z tym nowym HALem :/
night: Mógłbyś mnie jakoś nakierować, co mam zrobić? Bo szukałem dość dużo na ten temat i tak, jak mówię - kombinacje s2ram nie działały. Jakieś słowa klucze, resztę sobie wygooglam.
A mógłbym :-)
Domyślam się że zależy Tobie na wstrzymaniu do RAM a nie hibernacji na dysk. W takim razie spróbuj jednego z powyższych:
echo 3 > /proc/acpi/sleep
echo mem > /sys/power/state
suspend
s2ram mówisz że Tobie nie do końca chwyta - sprawdziłbym logi dlaczego się wszystko wywala. Możesz też spróbować bardzo hardkorowej metody:
cd /usr/lib/hal/scripts/
sh hal-system-power-suspend
Jeśli żadna nie zadziała to daję sobie głowę uciąć że masz konflikt sprzętowy, przez co komp nie wstaje po hibernacji. Ja coś takiego miałem z ath_pci i uhci. Wtedy pozostaje kombinowanie z modułami.
Konflikt sprzętowy? Przecież wcześniej na Mandriva 2007.1 wszystko działało.
A co do poleceń to:
[root@localhost scripts]# echo 3 > /proc/acpi/sleep
bash: /proc/acpi/sleep: Nie ma takiego pliku ani katalogu
echo mem > /sys/power/state
To samo, co przy każdym innym usypianiu.
[root@localhost scripts]# suspend
[3]+ Stopped su root
[root@localhost scripts]# sh hal-system-power-suspend
hal-functions: line 7: [: argument expected
org.freedesktop.Hal.Device.UnknownError
No back-end for your operating system
sthsth