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.

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 s2idletryb, 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, napisz pm-suspendw terminalu, jeśli masz pm-utilszainstalowany, lub naciśnij Windowstyp klucza suspendi naciśnij Enterklawisz).

Obudzić się z trybu zawieszenia i wpisać w terminalu: sudo journalctl | grep "PM: suspend" | tail -2. Jeśli dane wyjściowe to

May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit

Wtedy nie wchodzisz w głęboki sen. Możesz także sprawdzić, cat /sys/power/mem_sleepktóre powinny zostać zwrócone

[s2idle] deep

co 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_sleepjako użytkownik root. Sprawdź, czy się powiodło, patrząc na wynik, cat /sys/power/mem_sleepktóry powinien być

s2idle [deep]

następnie zawieś laptopa i obudź się ponownie. Jeśli sudo journalctl | grep "PM: suspend" | tail -2powróci

May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit

wtedy 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ę

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

z

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

i zregeneruj swoją konfigurację grub (uruchom sudo grub-mkconfig -o /boot/grub/grub.cfg).

Spróbuj utworzyć /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

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.confzmianie, 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-utilsi używać pm-suspendi wydawało się, że dość skutecznie się zawieszam, więc chciałem sprawdzić, czy mogę systemd-suspendzrobić to samo.

Przejrzałem skrypty, pm-utilsaby dowiedzieć się, co tak naprawdę robi, i wygląda na to, że w tej sytuacji to robi echo -n "mem" > /sys/power/state. Więc stworzyłem /etc/systemd/sleep.confplik, jak pokazano powyżej, aby go dopasować.

Nie jest do końca jasne, jakie jest domyślne zachowanie. Strona podręcznika dla systemd-sleep.confmówi, że dystrybucja powinna zawierać /etc/systemd/sleep.confskomentowane domyślne ustawienia kompilacji, aby można było zobaczyć te informacje, ale w ubuntu brakuje tego pliku. Zauważyłem jednak, że jeśli cat /sys/power/stateotrzymasz:

freeze mem

Więc jestem zgadywania , że to, co robi domyślnie. Domyślam się, że freezemoże zostać zaakceptowane, ponieważ nie generuje błędu, który w przeciwnym razie spowodowałby przejście do systemd mem, 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łanie memzamiast tego jest nadzieją na uniknięcie tego i zrobienie tego, co się pm-suspenddzieje.

Podejrzewam, że ustawienie SuspendMode jest w rzeczywistości zbędne i i tak nic nie robi. Podejrzewam, że to dlatego, że cat /sys/power/diskpo prostu dostaje:

[disabled]

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.

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:

1. Czy masz grafikę nVidia? Jeśli tak, spróbuj sztuczki gruby nouveau.modeset = 0 .

2. 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.

3. 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

4. Wypróbuj pozostałe dwa dobrze zbadane rozwiązania dostarczone przez monty47 i StrangeNoises i sprawdź, czy uzyskasz dobre wyniki.

   • Wydaje się, że pomogły pewnej liczbie osób w ponownym zawieszeniu się i poprawnym uruchomieniu w dniu 18.04 i mogą być bardziej związane z przejściem maszyny w stan s2idle, a nie w tryb uśpienia (głębokiego) zwykłego „zawieszenia”.

5. 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.

6. 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

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:

[…] Celowe jest używanie s2idle na tym komputerze z najnowszym jądrem.

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_sleepX1C6 wskazywałoby jedynie [s2idle]brak wsparcia dla deepsnu.

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 DSDTpoprawki 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 .

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.

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 .)

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.

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.

Tak więc moje wstępne rozwiązanie, które wydaje się działać do tej pory, to: włączanie i wyłączanie niektórych ustawień BIOS-u. Wiem, że to brzmi wręcz idiotycznie, ale przysięgam, że wydawało się, że działa z tego, co testowałem do tej pory.

W szczególności albo wyłączyłem ustawienia i / lub wybrałem inną opcję dla ustawienia, zastosowałem je, a następnie przywróciłem i zastosowałem. Ustawienia, które przełączałem w tę i z powrotem, to:

• Konfiguracja systemu> Ekran dotykowy (wyłączony, a następnie włączony ponownie)

• Zarządzanie energią> Auto On Time (Przełączono na inną opcję, a następnie z powrotem na Wyłączone)

• Zarządzanie energią> Obudź się w dokach Dell USB-C (Wyłączone, a następnie Włączone)

Działa teraz świetnie. . . .