Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Hm, objawia się on następująco: gdy usypiam laptop na mniej niż x sekund (x < 30sekund) jest w porządku - wybudza się laptop. Jak więcej go potrzymam na suspend mode - nie obudzi się. W logach nie ma informacji żadnej. Co zrobiłem? Wymieniłem dysk i postawiłem system na nowo (na nowym dysku). Dysk sprawdzony (test z poziomu bios'a - testdiskiem lenovo), smart quick-test bez problemowo, Spin-up retry count jest na czerwono, ale wartość RAW jego wynosi 2. Dysk nie był oficjalnie montowany w laptopie. Model SAMSUNG HM250JI, SATA 2, AHCI włączone.
O co chodzi? Albo czego brakuje do poprawnego wybudzania/usypiania? usuwsup, pm-tools, laptop-mode-tools, acpid, acpitools, acpi**, laptop-detect itd. są, jądro 3.2.0 dystrybucyjne (ostatnia wersja), consolekit 0.4.1 (nowa dalej nie pozwala na wyłączanie/usypianie z poziomu zwykłego user'a - od kilku miesięcy).
Trochę to irytujące, bowiem na baterii pracuję bardzo dużo, a usypianie to +kilka godzin do pracy w ciągu dnia (przerwy, etc.)
P.s. wymieniany był też RAM - kości starych nie mam przy sobie - nie wymienię ich celem sprawdzenia, czy to na pewno dysk może być powodem - potrzeba mi działać na tej nowej konfiguracji.
Offline
Witam,
Sprawdzałeś na innej wersji kernela lub patche/paczki TuxOnIce?
Pozdrawiam,
Towarzysz Torrentow
Offline
U mnie na kernelu 3.2.x w ogóle usypianie przestało działać (nie wnikałem jeszcze dlaczego, bo i tak prawie nigdy tego nie używałem), na 3.1.x działa normalnie. Zatem pierwsze co, to sprawdziłbym na kernelu 3.1.x na Twoim miejscu.
paoolo napisał(-a):
consolekit 0.4.1 (nowa dalej nie pozwala na wyłączanie/usypianie z poziomu zwykłego user'a - od kilku miesięcy).
Może na nowszych po prostu masz nieaktywną sesję consolekit? To nie bug, to feature.
http://forum.dug.net.pl/viewtopic.php?pid=193504#p193504
Offline
Wycofali to jądro (research <5min) z repo. Zajmę się tym dopiero wieczorem.
Offline
Na snapshot.debian.org na pewno jest.
Offline
Obawiam sie, ze moze teraz trudno bedzie znalezc poniewaz jadro od 2.6.39 az do 3.1 mialo "wypadek" tzn. nie limitowalo wejscia do /proc/mem. Mimo patchowania nie bardzo udalo sie rozwiazac ten problem i w pospiechu skonstuowano 3.2.0-1
~$ aptitude search linux-image v linux-image - v linux-image-2.6 - p linux-image-2.6-amd64 - Linux for 64-bit PCs (dummy package) p linux-image-2.6-rt-amd64 - Linux for 64-bit PCs (dummy package) p linux-image-2.6.32-5-amd64 - Linux 2.6.32 for 64-bit PCs p linux-image-2.6.32-5-amd64-dbg - Debugging infos for Linux 2.6.32-5-amd64 p linux-image-2.6.32-5-openvz-amd64 - Linux 2.6.32 for 64-bit PCs, OpenVZ support p linux-image-2.6.32-5-openvz-amd64-dbg - Debugging infos for Linux 2.6.32-5-openvz-amd64 p linux-image-2.6.32-5-vserver-amd64 - Linux 2.6.32 for 64-bit PCs, Linux-VServer support p linux-image-2.6.32-5-vserver-amd64-dbg - Debugging infos for Linux 2.6.32-5-vserver-amd64 p linux-image-2.6.32-5-xen-amd64 - Linux 2.6.32 for 64-bit PCs, Xen dom0 support p linux-image-2.6.32-5-xen-amd64-dbg - Debugging infos for Linux 2.6.32-5-xen-amd64 i linux-image-3.2.0-1-amd64 - Linux 3.2 for 64-bit PCs p linux-image-3.2.0-1-amd64-dbg - Debugging infos for Linux 3.2.0-1-amd64 p linux-image-3.2.0-1-rt-amd64 - Linux 3.2 for 64-bit PCs, PREEMPT_RT p linux-image-3.2.0-1-rt-amd64-dbg - Debugging infos for Linux 3.2.0-1-rt-amd64 p linux-image-amd64 - Linux for 64-bit PCs (meta-package) p linux-image-rt-amd64 - Linux for 64-bit PCs (meta-package), PREEMPT_RT
Nie dotyczy stable/Squeeze do jadra 2.6.38 lub direct 3.2.0.1 (squeeze-backports)
http://packages.debian.org/search?keywords=linux-im … p;section=all + prasa
dddarek napisał(-a):
Obawiam sie, ze moze teraz trudno bedzie znalezc
Jak już pisałem — na snapshot.debian.org na pewno jest.
np.: http://snapshot.debian.org/package/linux-2.6/3.1.8- … amd64_3.1.8-2
Można użyć tego jako repozytorium, przykładowo:
deb http://snapshot.debian.org/archive/debian/20120127T214300Z/ testing main
linux-image-3.1.0-1-amd64: Zainstalowana: (brak) Kandydująca: 3.1.8-2 Tabela wersji: 3.1.8-2 0 990 http://snapshot.debian.org/archive/debian/20120127T214300Z/ testing/main amd64 Packages
=============================
PS Jeżeli data zawarta w polu „Valid-Until” dla danego repozytorium została przekroczona, można wyłączyć jej sprawdzanie.
np.:
apt-get -o Acquire::Check-Valid-Until=0 update
lub dodać na stałe do apt.conf:
Acquire::Check-Valid-Until "false";
Offline
O°K° Wykreslam slowo znalezc i zmieniam na "akceptowac/uzywac"
Obawiam sie, ze moze teraz trudniej bedzie akceptowac/uzywac poniewaz jadro od 2.6.39 az do 3.1 mialo "wypadek" tzn. nie limitowalo wejscia do /proc/mem. Mimo patchowania nie bardzo udalo sie rozwiazac ten problem i w pospiechu skonstruowano 3.2.0-1
Czy teraz mozesz przyjac moja odpowiedz jako Boss?
Zagorzaly fanatyk Debian'a. :)
Ostatnio edytowany przez dddarek (2012-03-05 17:22:26)
Nie no jasne. :) Ale ja nie doradzam mu żeby na stałe został na 3.1… Chodzi o to żeby sprawdzić czy na tej wersji również występuje problem z usypianiem. Jeżeli się okaże, że nie, to winien jest pewnie kernel. Jeżeli się okaże, że na tym również występuje, to przyczyna prawdopodobnie leży gdzie indziej.
Offline
A mam pytanko, skoro patch TuxOnIce jest tak dobry, czemu go do jądra na stałe nie wrzucą?
Fervi
Offline
ja do hibernacji/suspend zainstalowałem tylko pm-utils i jest git, acpi już było chyba. po co jeszcze jakieś patchy i inne bajery? (pamiętam ile męczyłem się na laptopie, a wystarczyło zainstalować pm-utils
Offline
dominbik napisał(-a):
po co jeszcze jakieś patchy i inne bajery?
TuxOnIce jest szybszy, sprawniejszy itp. niż standardowa hibernacja dostępna w kernelu… A tak w ogóle myślałem, że ten wątek dotyczy usypiania (suspend to ram), a nie hibernacji. :) TuxOnIce natomiast odpowiada tylko za hibernację, s2ram jest od niego niezależny.
PS W razie dalszych pytań o TuxOnIce proszę kontynuować tutaj: forum.dug.net.pl/viewtopic.php?id=18019, żeby tego wątku nie rozmywać.
Offline
To jednak nie kernel. Nowa obserwacja - po ca. 10 sekundach na 3.2.* dostaję masę błędów na konsoli i na końcu kernel-pniac - stack corrupted i inne bajery - nic o dysk, a początku listingu nie zdążyłem wychwycić. Nie udało się tego zalogować.
Offline
kernel-pniac
kernel-panic = panika kernela/jadra
EDIT :
dominbik napisał(-a):
po co jeszcze jakieś patchy i inne bajery?
Kolego, ty nawet nie wiesz o czym sie tutaj mowilo. Tu sie mowilo o patchowaniu kernela/jadra 2.6.39 / 3.0.0 / 3.1.0 w zwiazku z Faille Zero Day critique dans les noyaux Linux 2.6.39 et plus = Krytyczna usterka w jadrach Linux'a ;)
Ostatnio edytowany przez dddarek (2012-03-06 00:03:00)
dzięki za wyjaśnienie.
dddarek napisał(-a):
Kolego, ty nawet nie wiesz o czym sie tutaj mowilo.
no odkryłeś jedną z przyczyn tego pytania
Offline
dddarek - celowo tak napisałem :P
Pozostaje póki co hibernacja - względnie szybka jest. Ale i tak to nie to samo.
Offline
Tyle co wiem, to aby działała hibernacja to warunkiem koniecznym jest posiadanie SWAP'a. Natomiast warunkiem koniecznym dla suspend'a jest 'dobry' i działający sterownik grafiki. Nie słyszałem, żeby kernel miał coś do tego, no chyba, że w sterowniku grafiki coś pomieszali (więc to się klei).
Offline
P@blo napisał(-a):
Nie słyszałem, żeby kernel miał coś do tego, no chyba, że w sterowniku grafiki coś pomieszali (więc to się klei).
Na obu kernelach używam tych samych zamkniętych sterowników Nvidii. Po uruchomieniu systemu na 3.1 suspend działa, a po uruchomieniu na 3.2 nie. Także coś kernel jednak ma do tego (pomijając już nawet fakt, że w kernelu w ogóle można wyłączyć możliwość usypiania).
Offline
Ok, to coś nowego dla mnie :) Powiem tylko ze na 3.3.0-rc{1,...,5} działa. Nie polecam rc6 bo zawieche łapie przy halcie...
Offline
P@blo napisał(-a):
Natomiast warunkiem koniecznym dla suspend'a jest 'dobry' i działający sterownik grafiki.
Pierwszym podstawowym manewrem jest wlasnie zaczac od tego, jesli ma sie problem z zarzadzaniem energi ( suspend, hibernate + wentylatory) Zadne tam pm-utils i inne glupoty z Gnome nie pomoga.
Ze sterownikami prywatnej nvidia 295. wszystko swietnie dziala pod Sid i nic pod Wheezy na dzien dzisiejszy. (jak sama nazwa wskazuje - testing)
~$ uname -r 3.2.0-1-amd64
Co do SWAP to jest bardzo przydatny, mimo ze masz minimum 4 Giga RAM i twardy dysk nie przekraczajacy 1 Tera (lub dwa w RAID po 500)
EDIT :
bo zawieche łapie przy halcie...
??? Nie wiem kiedy "zrozumiem" wasze slownictwo. :)
@+
Ostatnio edytowany przez dddarek (2012-03-07 14:22:09)
@up: Dzięki za poparcie :D
dddarek napisał(-a):
Co do SWAP to jest bardzo przydatny, mimo ze masz minimum 4 Giga RAM i twardy dysk nie przekraczajacy 1 Tera (lub dwa w RAID po 500)
No ja osobiście nie polecam. Ktoś mi kiedyś opowiadał, że jak mu wlazło na swap'a to zaczęło tak mulić, że jakiś szok! Fajny wynalazek, ale jakoś tak, niedopracowany... (chyba).
Tak przy okazji... Mam takie pytanie bo się ostatnio zastanawiałem. Czy jest możliwość kopiowania płyty za pomocą RAM-u? Tzn nie żeby szło wpierw na dysk potem na płytę, ale na RAM i potem na płytę? Wydaje mi się, że się da :D no i chyba było by szybciej i to o wiele?
dddarek napisał(-a):
EDIT :
bo zawieche łapie przy halcie...
??? Nie wiem kiedy "zrozumiem" wasze slownictwo. :)
No co ci powiedzieć... Śledź i się ucz :D
Offline
Na 3.3-rc6 też suspend u mnie nie działa, nawet w trybie tekstowym bez odpalonych X-ów i bez modułów Nvidii. :)
Offline
P@blo napisał(-a):
Śledź i się ucz :D
A czy to jest literacki/techniczno informatyczny jezyk polski czy Wasza "gwara" typu kernel-pniac ?
SWAP (czasami nazywany pamiecia wirtualna) jest to partycja na dysku twardym sluzaca do odciazenia pamieci fizycznej (RAM) w momencie ktorym pamiec fizyczna dochodzi do saturacji. Wtedy mowi sie o partycji wymiany lub simple fichier/file swap.
zaczęło tak mulić,
Resultat uzywania SWAP'u jest znacznie gorszy niz pamiecu fizycznej (RAM) poniewaz zwalnia system i prowadzi do ciaglego uzywania twardego dysku co znacznie wplywa na jego zuzycie i raczej skraca mu zycie.
EDIT :
Tak przy okazji... Mam takie pytanie bo się ostatnio zastanawiałem. Czy jest możliwość kopiowania płyty za pomocą RAM-u? Tzn nie żeby szło wpierw na dysk potem na płytę, ale na RAM i potem na płytę? Wydaje mi się, że się da :D no i chyba było by szybciej i to o wiele?
Wydaje mi sie, ze powinienes otworzyc osobny topic aby nie mieszac tematow. ;) (tylko mi sie wydaje):)
Pozdrawiam.
Ostatnio edytowany przez dddarek (2012-03-07 19:57:56)
@paoolo
WYLACZYC / ZAMKNAC EKRAN BEZ WYLACZENIA SYSTEMU
Jezeli chcesz oszczedzac baterie BEZ WYLACZENIA LUB USPIENIA ordynatora mozna dorzucic :
exit 0
na poczatku skryptu /etc/acpi/actions/lid.sh Co daje :
#!/bin/sh exit 0 [ -e /usr/share/acpi-support/policy-funcs ] || exit 0 . /usr/share/acpi-support/policy-funcs # If powersaved is running, let it process the acpi event if pidof powersaved; then exit 0 fi if [ `CheckPolicy` = 0 ] ; then exit 0 fi [ -e /etc/acpi/actions/suspend.sh ] || exit 0 . /etc/acpi/actions/suspend.sh
P@blo napisał(-a):
Wydaje mi się, że się da :D no i chyba było by szybciej i to o wiele?
kopiowania jakiej płyty? porównaj prędkość odczytu/zapisu na dysk a zapisu na płytę. szybciej się nie da (mówię o kopiowaniu w locie)
Ostatnio edytowany przez dominbik (2012-03-07 20:15:59)
Offline