Funzionava perfettamente su 17.10 ma dopo l'aggiornamento a 18.04 ieri, quando il coperchio è chiuso lo schermo si spegne ma non si sospende correttamente.

Viaggio molto e ho notato immediatamente il calore (e la batteria scarica) quando lo estraggo dalla custodia da viaggio.

Ho provato a decommentare queste righe in /etc/systemd/logind.conf

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

e riavviato ma non ha fatto alcuna differenza.

Penso di essere riuscito a capire cosa stava succedendo, grazie a queste due fonti: Dell XPS 13 (9370) ArchLinux Note di installazione e Arch Linux Forum .

Per qualche ragione, il laptop non sta più andando in s2idlemodalità di sospensione , ma piuttosto una modalità che è semplicemente uno schermo fuori dal tipo di sospensione.

Diagnosi del problema

Per confermare se questo è il caso per il tuo sistema, sospendi il laptop usando il tuo metodo preferito (chiudi il coperchio, premi Fn+ End, scrivi pm-suspendin un terminale se hai pm-utilsinstallato o premi il Windowstipo di chiave suspende premi la Enterchiave).

Esca dalla modalità e tipo di sospensione in un terminale: sudo journalctl | grep "PM: suspend" | tail -2. Se l'uscita è

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

Quindi non stai entrando nel sonno profondo. Puoi anche controllare cat /sys/power/mem_sleepquale dovrebbe tornare

[s2idle] deep

che conferma che la modalità di sospensione predefinita è s2idle (poiché è evidenziata tra parentesi).

Correzione temporanea

Per provare una correzione temporanea, fai echo deep > /sys/power/mem_sleepcome utente root. Verifica che abbia avuto successo osservando il risultato cat /sys/power/mem_sleepche dovrebbe essere

s2idle [deep]

quindi sospendi il laptop e svegliati di nuovo. Se sudo journalctl | grep "PM: suspend" | tail -2ritorna

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

quindi il problema dovrebbe essere risolto. Puoi mettere il computer in standby per un paio d'ore e verificare se il consumo della batteria è migliorato.

Correzione permanente

Per renderlo permanente, è necessario modificare il cmdline del bootloader. Per fare ciò, modificare come utente root il file / etc / default / grub, eseguendo ad esempio sudo -H gedit /etc/default/grub. Sostituisci la linea

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

con

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

e rigenerare la configurazione di grub (esegui sudo grub-mkconfig -o /boot/grub/grub.cfg).

Prova a creare /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

E riavvia. Questo sembra funzionare per me, anche se non sono sicuro di non aver ottenuto miglioramenti con il /etc/systemd/logind.confcambiamento che ho fatto prima. In ogni caso, nessun rumore di calore o ventilatore si osserva mentre sospeso con la chiusura del coperchio, e non risponde al ping tramite WiFi o, che io ero stato sempre, in modo intermittente, prima.

La durata della batteria continua a diminuire mentre è sospesa, probabilmente perché il metodo di sospensione è meno efficiente del metodo predefinito, ideale, che apparentemente non funziona correttamente, ma sembra migliore del comportamento predefinito.

Provato sul mio XPS 13 9370, non conosco modelli più vecchi, anche se sembra probabile che saranno simili.

Avevo provato a installare pm-utilse utilizzare pm-suspende sembrava sospendere abbastanza efficacemente, quindi volevo vedere se potevo systemd-suspendfare la stessa cosa.

Ho controllato gli script pm-utilsper capire cosa stesse realmente facendo, e sembra che, in questa situazione, stesse facendo echo -n "mem" > /sys/power/state. Quindi ho creato il /etc/systemd/sleep.conffile come mostrato sopra per abbinarlo.

Non è del tutto chiaro quale sia il comportamento predefinito. La manpage per systemd-sleep.confdice che la distro dovrebbe includere /etc/systemd/sleep.confcon le impostazioni predefinite compilate commentate, quindi puoi vedere queste informazioni, ma in Ubuntu questo file è mancante. Ho notato che se cat /sys/power/stateottieni:

freeze mem

Quindi suppongo che questo sia ciò che sta facendo di default. La mia ipotesi è che freezepotrebbe essere accettato, in quanto non genera un errore, che altrimenti causerebbe il passaggio di systemd mem, ma forse in realtà non funziona correttamente, o in modo affidabile, per ragioni complesse che non siamo in grado di determinare. Quindi, meminvece, l' invio è solo una speranza per evitarlo e fare semplicemente ciò che pm-suspendfa.

Ho il sospetto che l'impostazione SuspendMode sia effettivamente superflua e non fa comunque nulla. Lo sospetto perché cat /sys/power/diskti prende:

[disabled]

Sono un nuovo utente, quindi incapace di commentare con un'osservazione, costretto a presentarlo come una risposta come se fossi super fiducioso in esso! Ma penso che funzioni.

Le altre risposte qui sono eccellenti, approfondite e ben studiate.

Sfortunatamente non hanno funzionato per la mia macchina particolare :(

Se hai la grafica nVidia, sembra esserci una soluzione che funziona per un buon numero di persone, fornita utile da Cascagrossa nella risposta a questa domanda: Ubuntu 18.04 si blocca quando riprende dalla sospensione

Si sospetta che sia un driver buggy nouveau e può risolvere i problemi di sospensione aggiungendo nouveau.modeset = 0 a grub ed è stato confermato nei commenti per aiutare a risolvere il problema anche per altri.

Ho la grafica Intel sulla mia macchina problematica e curiosamente non ho avuto problemi di sospensione con Ubuntu o Kubuntu 18.04 su almeno altre 3 macchine (quella di un mio amico e quella mia), quindi perché questa particolare macchina si sta facendo un tale schifo al riguardo non è chiaro.

Consiglio a chiunque abbia questo tipo di problema di seguire questi passaggi per aiutare a identificare il problema:

1. Hai una grafica nVidia? In tal caso, prova il trucco nouveau.modeset = 0 grub.

2. Controlla che la sospensione funzioni affatto. Se chiudi il coperchio e lo apri in un secondo momento e non si sta svegliando, potrebbe sembrare che non riesca a "riprendere".

   • Dovresti essere in grado di selezionare manualmente sospendi su qualsiasi desktop ma è leggermente nascosto in Gnome Shell: puoi premere a lungo il pulsante di accensione dal menu in alto a destra dello schermo o fare clic su quel pulsante mentre tieni premuto Alt o premi il tasto Super e digita in "sospensione"

   • Selezionando sospendi puoi verificare che lo schermo sia spento , il LED di alimentazione lampeggi come dovrebbe e ti aspetteresti che anche una ventola in funzione si fermi . Se tutto questo accade, ma poi non è possibile ottenere la vostra macchina per svegliato allora sembrerebbe essere un problema 'curriculum' piuttosto che un problema 'sospendere'.

   • Il mio problema è stato che in realtà non sta andando in sospensione e Murray che ha posto la domanda originale, quando gli è stato chiesto dalla collisione Due per verificarlo, si è reso conto che il problema si stava verificando anche durante la sospensione manuale.

   • Nel mio caso (sul laptop con un problema) , lo schermo si oscura ma il LED di alimentazione rimane acceso e se la ventola è in esecuzione continua a funzionare. La macchina non risponde a pressioni di tasti, movimenti del touchpad o clic o alla pressione dei pulsanti di accensione. L'unica cosa che si può fare è spegnerlo.

   • Ho provato a riprodurre musica mentre andavo in sospensione (per verificare che non fosse solo lo schermo che si oscura) ma la musica si interrompe e la macchina si è sostanzialmente bloccata.

3. Prova la tua macchina con un USB Live di 18.04 e verifica se hai problemi di sospensione simili.

   • Ciò confermerà semplicemente che i problemi di sospensione non riguardano i programmi aggiuntivi installati.

   • Nel mio caso sospettavo fosse perché avevo installato tlp che avrebbe potuto interferire in qualche modo con la modalità di sospensione, ma lo stesso comportamento si è verificato con un Live USB di Ubuntu 18.04 e Kubuntu 18.04

4. Prova le altre due soluzioni ben studiate fornite qui da monty47 e StrangeNoises e vedi se ottieni buoni risultati.

   • Sembrano aver aiutato un certo numero di persone a riavviare e funzionare correttamente il 18.04 e potrebbero avere più a che fare con la macchina che passa in uno stato s2idle piuttosto che con la modalità di sospensione (profonda) di una normale "sospensione".

5. Se nessuna delle soluzioni sta funzionando per risolvere i tuoi problemi di sospensione su 18.04, prova la risposta accettata a questo: Ubuntu 18.04 si arresta in modo anomalo alla ripresa dalla sospensione

   • La soluzione fornita da Matalak (che ha anche posto la domanda) era usare UKUU per provare un kernel 4.14 precedente.

   • La mia macchina problematica non ha avuto problemi di sospensione con Ubuntu 17.10 e Kubuntu 17.10, quindi ha senso dal 17.10 usa il kernel 4.14. Ora si sospende bene sia in Ubuntu 18.04 che in Kubuntu 18.04 usando il kernel 4.14.

6. Se hai provato le altre soluzioni e hai risolto i problemi di sospensione solo tornando a un kernel 4.14, potresti essere interessato alla segnalazione di bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/ 1774950

   • Sembra interessare solo alcune macchine con una specifica combinazione di hardware e può essere difficile identificarlo tra gli altri problemi relativi a nouveau o problemi s2idle.

   • Sembra essere più diffuso per coloro che gestiscono un Bay Trail Atom Celeron / Pentium, ma altri hanno segnalato un problema simile con altre macchine.

   • Se riesci a controllare il tuo kern.log dopo questa sospensione fallita (cioè una volta che hai dovuto spegnere la macchina e riavviare) potresti notare che dice PM: sospendi la voce (in profondità) e quindi non hai altre voci a parte le molte linee di riavvio.

   • Al momento esiste una patch che sembra risolvere il problema.

   • Se hai voglia di aggiungere la tua voce alla segnalazione di bug, sarebbe interessante vedere quali macchine particolari sono interessate (e verificare che la patch risolva il problema per tutti).

Anche tentando di raccogliere "Suspend Issues in 18.04" insieme in questo thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Credo che questo bug del kernel sia correlato:

https://bugzilla.kernel.org/show_bug.cgi?id=199689

Vedi il commento n. 3 in particolare:

[…] In realtà è intenzionale usare s2idle su questa macchina con l'ultimo kernel upstream.

Voglio solo aggiungere una risposta agli utenti di Thinkpad X1 Carbon 6th Gen che ha un sintomo simile, ad esempio il consumo della batteria mentre è sospeso, causato anche dal fatto di non entrare in modalità di sospensione profonda .

Questo problema è discusso su questo thread sul forum di Lenovo , in breve l'X1C6 ha optato per supportare Windows Modern Standby. Se leggi attentamente quel thread, vedresti che sebbene il sintomo sia condiviso, le cause alla radice variano notevolmente tra l'XPS 13 9370 e l'X1C6 . ad es. l'uscita di cat /sys/power/mem_sleepsu X1C6 indicherebbe solo il [s2idle]supporto mancante per il deepsonno.

Le soluzioni pubblicate finora per questa domanda si applicano solo all'XPS 13 e non all'X1C6. Per quanto ho capito, la migliore soluzione al problema della modalità di sospensione dell'X1C6 è applicare una DSDTpatch prima data da Delta Xi e successivamente aggiornata da PombeirP . Questo post ti spiega come applicare la patch, ma assicurati di leggere il post e tutti i suoi aggiornamenti prima di qualsiasi azione.

Ho scritto un documento che documenta i problemi relativi all'installazione di Ubuntu 18.04 sul Thinkpad X1 Carbon 6th Gen, comprese le soluzioni che ho riscontrato sul problema di avvio lento causato da LVM e su questo problema del sonno profondo .

Sto utilizzando un Lenovo ThinkPad Edge E531 e ho riscontrato un problema simile in cui la macchina non era in grado di entrare in modalità di sospensione. Il comportamento era intermittente e, al riavvio, a volte faceva sì che il touchpad smettesse di funzionare sul wifi per disconnettersi.

Ho provato una dozzina di correzioni suggerite online, ma l'unica soluzione che ha funzionato per me è stata l' installazione di UKUU e l'aggiornamento del kernel al 4.19.11-041911-generico.

Solo per concludere questa domanda (si spera ...), ho appena (luglio 2019) avuto un aggiornamento al mio LTS 18.04 con HWE che afferma di risolvere questo problema specificamente per il Dell XPS 13 (incluso non andare in s2idle .)

FWIW, ho appena sostituito la batteria del mio XPS 13 (9350) del 2016 con Ubuntu 16.04 e kernel 4.14.12-041412-generico (la macchina è stata installata all'inizio del 2016 con 15.10 e un kernel personalizzato è stato quindi aggiornato a 16.04). Prima della sostituzione, il coperchio ha messo Linux in modalità di sospensione come dovrebbe (anche se se si collegasse l'alimentatore durante la sospensione o lo si scollegasse, ad esempio cambiando lo stato in cui Linux pensava che funzionasse, sarebbe estremamente lento fino al riavvio) . Ad ogni modo, dopo la sostituzione (batteria gonfia), il notebook si riavvierebbe per rimanere a vuoto quando il coperchio è chiuso.

L'impostazione della gestione dell'alimentazione su "Standard" (da "Avanzate") in "Configurazione batteria principale" nel BIOS EFI di Dell / AMI (che è possibile visualizzare tenendo premuto Fn-F2 durante l'avvio) sembra aver risolto il problema.

Sono passate molte delle soluzioni elencate e niente ha funzionato per popOS su xps 9560 :(

Fino a quando ho visto questa soluzione divertente sul sito Web dell's che stava prendendo da un post LTT.

Quindi, la mia soluzione provvisoria che sembra funzionare finora è: attivare e disattivare alcune impostazioni del BIOS. So che sembra decisamente idiota, ma giuro che sembra funzionare da quello che ho testato finora.

In particolare, ho disattivato le impostazioni e / o selezionato un'opzione diversa per un'impostazione, applicata, quindi ripristinata e applicata. Le impostazioni che ho commutato avanti e indietro erano:

• Configurazione del sistema> Touchscreen (disattivato, quindi riacceso)

• Risparmio energia> Tempo di accensione automatica (impostato su un'altra opzione, quindi di nuovo su Disabilitato)

• Risparmio energia> Wake on Dell USB-C Docks (disattivato, quindi attivato)

Funziona benissimo ora. . . .