Działa to doskonale 17.10, ale po aktualizacji wczoraj do 18.04, kiedy pokrywa jest zamknięta, ekran wyłącza się, ale nie zawiesza się poprawnie.
Dużo podróżuję i od razu zauważyłem ciepło (i rozładowanie baterii), gdy wyjmowałem je z futerału.
Próbowałem odkomentować te linie w /etc/systemd/logind.conf
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend
i uruchomił się ponownie, ale nie zrobił żadnej różnicy.
Odpowiedzi:
Myślę, że udało mi się dowiedzieć, co się dzieje, dzięki dwóm źródłom: Dell XPS 13 (9370) ArchLinux z uwagami dotyczącymi instalacji i Arch Linux Forum .
Z jakiegoś powodu laptop nie przechodzi już w głęboki sen, ale raczej
s2idle
tryb, który jest jedynie zawieszeniem ekranu.Diagnoza problemu
Aby potwierdzić, czy tak jest w przypadku twojego systemu, zawieś laptopa przy użyciu ulubionej metody (zamknij pokrywę, naciśnij
Fn
+End
, napiszpm-suspend
w terminalu, jeśli maszpm-utils
zainstalowany, lub naciśnijWindows
typ kluczasuspend
i naciśnijEnter
klawisz).Obudzić się z trybu zawieszenia i wpisać w terminalu:
sudo journalctl | grep "PM: suspend" | tail -2
. Jeśli dane wyjściowe toWtedy nie wchodzisz w głęboki sen. Możesz także sprawdzić,
cat /sys/power/mem_sleep
które powinny zostać zwróconeco potwierdza, że domyślnym trybem zawieszenia jest s2idle (ponieważ jest podświetlony nawiasami kwadratowymi).
Tymczasowa poprawka
Aby wypróbować tymczasową poprawkę, zrób to
echo deep > /sys/power/mem_sleep
jako użytkownik root. Sprawdź, czy się powiodło, patrząc na wynik,cat /sys/power/mem_sleep
który powinien byćnastępnie zawieś laptopa i obudź się ponownie. Jeśli
sudo journalctl | grep "PM: suspend" | tail -2
powróciwtedy problem powinien zostać rozwiązany. Możesz uśpić komputer na kilka godzin i sprawdzić, czy rozładowanie baterii uległo poprawie.
Stała poprawka
Aby to było trwałe, musisz edytować cmdline bootloadera. Aby to zrobić, edytuj jako użytkownik root plik / etc / default / grub, uruchamiając na przykład
sudo -H gedit /etc/default/grub
. Zamień linięz
i zregeneruj swoją konfigurację grub (uruchom
sudo grub-mkconfig -o /boot/grub/grub.cfg
).źródło
sysfsutils
iecho 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf
. sysfsutils to niewielka usługa, która po prostu przywraca takie parametry sysfs.echo deep
etapie, w którym dostajęecho: write error: Invalid argument
. Może to być spowodowane tym, że nie jestem prawidłowo rootowany. Nie mogę,su -
ponieważ ubuntu ma to wyłączone, więc wypróbowałem obasudo -i
isudo su
deep
tryb zawieszenia nie działa poprawnie, jeśli szyfrowanie dysku jest włączone w Ubuntu 18.04. dell.com/community/XPS/…su -
jakosudo -i
. Możesz także zmienić hasło rootasudo passwd
, jeśli tak wolisz administrować swoimi skrzynkami uniksowymi.Spróbuj utworzyć
/etc/systemd/sleep.conf
:I uruchom ponownie. Wydaje się, że to działa dla mnie, chociaż nie jestem pewien, czy nie poprawiłem się również dzięki
/etc/systemd/logind.conf
zmianie, którą zrobiłem jako pierwszy. W każdym razie, nie ma hałasu ciepła lub wentylator obserwuje się natomiast zawieszony z zamkniętymi pokrywy, a nie odpowiada na ping przez WiFi albo, co ja nie dostaję, z przerwami, przed.Żywotność baterii wciąż spada po zawieszeniu, prawdopodobnie dlatego, że działająca metoda zawieszenia jest po prostu mniej wydajna niż domyślna, idealna metoda, która najwyraźniej nie działa poprawnie, ale wydaje się lepsza niż zachowanie domyślne.
Wypróbowany na moim XPS 13 9370, nie wiem o starszych modelach, chociaż wydaje się prawdopodobne, że będą podobne.
Próbowałem zainstalować
pm-utils
i używaćpm-suspend
i wydawało się, że dość skutecznie się zawieszam, więc chciałem sprawdzić, czy mogęsystemd-suspend
zrobić to samo.Przejrzałem skrypty,
pm-utils
aby dowiedzieć się, co tak naprawdę robi, i wygląda na to, że w tej sytuacji to robiecho -n "mem" > /sys/power/state
. Więc stworzyłem/etc/systemd/sleep.conf
plik, jak pokazano powyżej, aby go dopasować.Nie jest do końca jasne, jakie jest domyślne zachowanie. Strona podręcznika dla
systemd-sleep.conf
mówi, że dystrybucja powinna zawierać/etc/systemd/sleep.conf
skomentowane domyślne ustawienia kompilacji, aby można było zobaczyć te informacje, ale w ubuntu brakuje tego pliku. Zauważyłem jednak, że jeślicat /sys/power/state
otrzymasz:Więc jestem zgadywania , że to, co robi domyślnie. Domyślam się, że
freeze
może zostać zaakceptowane, ponieważ nie generuje błędu, który w przeciwnym razie spowodowałby przejście do systemdmem
, ale być może nie działa właściwie lub niezawodnie, ze złożonych powodów, których nie jesteśmy w stanie określić. Więc wysyłaniemem
zamiast tego jest nadzieją na uniknięcie tego i zrobienie tego, co siępm-suspend
dzieje.Podejrzewam, że ustawienie SuspendMode jest w rzeczywistości zbędne i i tak nic nie robi. Podejrzewam, że to dlatego, że
cat /sys/power/disk
po prostu dostaje:Jestem nowym użytkownikiem, dlatego nie mogę komentować obserwacji, zmuszony przedstawić ją jako odpowiedź, jakbym był bardzo pewny siebie! Ale myślę, że to działa.
źródło
Pozostałe odpowiedzi tutaj są doskonałe, dogłębne i dobrze zbadane.
Niestety nie działały na mojej konkretnej maszynie :(
Jeśli masz grafikę nVidia, wydaje się, że istnieje poprawka, która działa dla dużej liczby osób, pomocniczo zapewniona przez cascagrossa w odpowiedzi na to pytanie: Ubuntu 18.04 ulega awarii po wznowieniu z zawieszenia
Podejrzewa się, że jest błędnym sterownikiem w stylu secesyjnym i może rozwiązać problemy z zawieszeniem, dodając nouveau.modeset = 0 do grub i zostało to potwierdzone w komentarzach za pomoc w rozwiązaniu problemu również dla innych.
Mam grafikę Intela na moim problematycznym komputerze i co ciekawe, nie miałem zawieszenia problemów z Ubuntu lub Kubuntu 18.04 na co najmniej 3 innych komputerach (mojego i mojego przyjaciela), więc dlaczego ta konkretna maszyna jest tak niespokojna? jest niejasne.
Polecam wszystkim, którzy napotykają tego rodzaju problemy, aby postępowali zgodnie z tymi krokami, aby pomóc zidentyfikować problem:
Czy masz grafikę nVidia? Jeśli tak, spróbuj sztuczki gruby nouveau.modeset = 0 .
Sprawdź, czy zawieszenie działa w ogóle. Jeśli zamykasz pokrywkę, a następnie otwierasz ją później i nie budzi się, może się wydawać, że nie „wznawia”.
Powinieneś być w stanie ręcznie wybrać opcję zawieszenia na dowolnym pulpicie, ale jest ona nieco ukryta w Gnome Shell - możesz albo długo nacisnąć przycisk zasilania z menu w prawym górnym rogu ekranu, albo kliknąć ten przycisk, przytrzymując klawisz Alt, lub nacisnąć klawisz Super i wpisać w „zawieszeniu”
Wybierając opcję zawieszenia, możesz sprawdzić, czy ekran się wyłączył , dioda LED zasilania miga tak, jak powinna, i można oczekiwać, że zatrzyma się również praca wentylatora . Jeśli to wszystko się dzieje, ale wtedy nie można dostać maszynę do obudzony wtedy wydaje się, że jest „resume” Problem raczej niż „zawiesić” problem.
Mój problem polegał na tym, że tak naprawdę nie zawiesza się, a Murray, który zadał oryginalne pytanie, gdy został poproszony przez kolizję Dwa o sprawdzenie, zdał sobie sprawę, że problem pojawiał się również podczas ręcznego zawieszania.
W moim przypadku (na jednym problematycznym laptopie) ekran gaśnie, ale dioda LED zasilania pozostaje włączona, a jeśli wentylator działa, nadal działa. Urządzenie nie reaguje na żadne naciśnięcia klawiszy, ruch touchpada, kliknięcia lub naciśnięcia przycisku zasilania. Jedyne, co można zrobić, to go wyłączyć.
Próbowałem odtwarzać muzykę, gdy byłem zawieszony (aby sprawdzić, czy nie tylko ekran gaśnie), ale muzyka się zatrzymuje i maszyna w zasadzie się zatrzymała.
Wypróbuj swoje urządzenie z Live USB 18.04 i sprawdź, czy masz podobne problemy z zawieszaniem.
To tylko potwierdzi, że problemy z zawieszaniem nie dotyczą żadnych zainstalowanych dodatkowych programów.
W moim przypadku podejrzewałem, że to dlatego, że zainstalowałem tlp, który mógł w jakiś sposób zakłócać tryb zawieszenia, ale to samo zachowanie wystąpiło w przypadku Live USB zarówno Ubuntu 18.04, jak i Kubuntu 18.04
Wypróbuj pozostałe dwa dobrze zbadane rozwiązania dostarczone przez monty47 i StrangeNoises i sprawdź, czy uzyskasz dobre wyniki.
Jeśli żadne z rozwiązań nie rozwiązuje problemów z zawieszeniem w dniu 18.04, spróbuj zaakceptować odpowiedź na to: Ubuntu 18.04 ulega awarii po wznowieniu z zawieszenia
Rozwiązaniem Matalaka (który również zadał to pytanie) było użycie UKUU do wypróbowania starszego jądra 4.14.
Mój problematyczny komputer nie miał problemów z zawieszeniem w Ubuntu 17.10 i Kubuntu 17.10, więc ma to sens, ponieważ 17.10 używa jądra 4.14. Teraz zawiesza się dobrze zarówno w Ubuntu 18.04, jak i Kubuntu 18.04, używając jądra 4.14.
Jeśli wypróbowałeś inne rozwiązania i mógłbyś tylko rozwiązać problemy z zawieszeniem, wracając do jądra 4.14, możesz zainteresować się raportem o błędzie: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/ 1774950
Wydaje się, że wpływa tylko na kilka komputerów z konkretną kombinacją sprzętu i może być trudny do zidentyfikowania wśród innych problemów związanych z nowymi wersjami lub problemów s2idle.
Wydaje się, że jest bardziej rozpowszechniony dla osób korzystających z Bay Trail Atom Celeron / Pentium, ale inni zgłosili podobny problem z innymi maszynami.
Jeśli jesteś w stanie sprawdzić swój kern.log po tym nieudanym zawieszeniu (tj. Po wyłączeniu komputera i ponownym uruchomieniu), możesz zauważyć, że jest napisane PM: zawiesić wpis (głębokie), a następnie nie masz żadnych innych wpisów oprócz wiele linii ponownego uruchamiania.
Obecnie istnieje łatka, która wydaje się rozwiązać problem.
Jeśli masz ochotę dodać swój głos do raportu o błędzie, dobrze byłoby zobaczyć, których komputerów dotyczy problem (i sprawdzić, czy łatka rozwiązuje problem dla wszystkich).
Również próba zebrania „Suspend Issues in 18.04” razem w tym wątku: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724
źródło
Uważam, że ten błąd jądra jest powiązany:
https://bugzilla.kernel.org/show_bug.cgi?id=199689
Zobacz w szczególności komentarz nr 3:
źródło
Chcę tylko dodać odpowiedź użytkownikom Thinkpad X1 Carbon 6. generacji, który ma podobny objaw, tj. Wyczerpanie baterii podczas zawieszenia, co jest również spowodowane brakiem przejścia w tryb głębokiego uśpienia.
Ten problem jest omawiany w tym wątku na forum Lenovo , krótko mówiąc, X1C6 zdecydował się na obsługę Windows Modern Standby. Jeśli dokładnie przeczytasz ten wątek, zobaczysz, że chociaż objaw jest wspólny, przyczyny źródłowe różnią się znacznie między XPS 13 9370 a X1C6 . np. wyjście
cat /sys/power/mem_sleep
X1C6 wskazywałoby jedynie[s2idle]
brak wsparcia dladeep
snu.Rozwiązania opublikowane do tej pory dotyczą tylko XPS 13, a nie X1C6. O ile rozumiem, najlepszym rozwiązaniem problemu trybu zawieszenia X1C6 jest zastosowanie
DSDT
poprawki najpierw podanej przez Delta Xi , a następnie zaktualizowanej przez PombeirP . W tym poście dowiesz się, jak zastosować poprawkę, ale upewnij się, że czytasz post i wszystkie jego aktualizacje przed podjęciem jakichkolwiek działań.Napisałem streszczenie dokumentujący problemy związane z instalacją Ubuntu 18.04 na Thinkpad X1 Carbon 6. generacji, w tym rozwiązania, które znalazłem na temat problemu powolnego rozruchu spowodowanego przez LVM, a także tego problemu głębokiego snu .
źródło
Korzystam z Lenovo ThinkPad Edge E531 i napotkałem podobny problem, gdy urządzenie nie mogło wejść w głęboki sen. Zachowanie było przerywane, a po wznowieniu czasami powodowało, że touchpad przestał działać na Wi-Fi, aby się rozłączyć.
Wypróbowałem kilkanaście poprawek sugerowanych online, ale jedynym rozwiązaniem, które mi pomogło, było zainstalowanie UKUU i uaktualnienie jądra do wersji 4.19.11-041911-generic.
źródło
Aby zakończyć to pytanie (mam nadzieję ...), właśnie (lipiec 2019) miałem aktualizację mojego 18.04 LTS z HWE, który twierdzi, że rozwiązał ten problem specjalnie dla Dell XPS 13 (w tym nie wchodząc w s2idle .)
źródło
FWIW, właśnie wymieniłem baterię na moim XPS 13 (9350) na Ubuntu 16.04 i kernél 4.14.12-04141412-generic (maszyna została skonfigurowana na początku 2016 r. Z 15.10, a niestandardowe jądro zaktualizowano do 16.04). Przed wymianą przykrywka wprowadziła Linuksa w tryb zawieszenia tak, jak powinna (chociaż jeśli podłączyłeś zasilacz podczas zawieszenia lub wyłączyłeś go, np. Zmieniłeś stan, w którym Linux działał, działałby bardzo wolno do ponownego uruchomienia) . W każdym razie po wymianie (spuchnięta bateria) notebook zrestartuje się, aby wykarczować, gdy pokrywa jest zamknięta.
Ustawienie zarządzania energią na „Standardowe” (z „Zaawansowanego”) w „Podstawowej konfiguracji baterii” w EFI BIOS Dell / AMI (które można wywołać przytrzymując Fn-F2 podczas rozruchu) wydaje się rozwiązać problem.
źródło
Przeszedłem przez wiele wymienionych rozwiązań i nic nie działało w popOSie na XPS 9560 :(
Dopóki nie zobaczyłem tej przezabawnej poprawki na stronie Dell, która pochodziła z postu LTT.
Działa teraz świetnie. . . .
źródło