Esto funcionaba perfectamente en 17.10, pero después de actualizar a 18.04 ayer, cuando se cierra la tapa, la pantalla se apaga pero no se suspende correctamente.

Viajo mucho e inmediatamente noté el calor (y el agotamiento de la batería) al sacarlo del estuche de viaje.

He intentado descomentar estas líneas en /etc/systemd/logind.conf

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

y reinició pero no hizo ninguna diferencia.

Creo que logré averiguar qué estaba pasando, gracias a estas dos fuentes: Dell XPS 13 (9370) ArchLinux Install notes y Arch Linux Forum .

Por alguna razón, la computadora portátil ya no está durmiendo profundamente, sino más bien un s2idlemodo que es simplemente un tipo de suspensión de pantalla apagada.

Diagnóstico del problema.

Para confirmar si este es el caso de su sistema, suspenda la computadora portátil usando su método favorito (cierre la tapa, presione Fn+ End, escriba pm-suspenden un terminal si lo ha pm-utilsinstalado, o presione el Windowstipo de tecla suspendy presione la Entertecla).

Despertar del modo y tipo suspender en un terminal: sudo journalctl | grep "PM: suspend" | tail -2. Si la salida es

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

Entonces no estás entrando en un sueño profundo. También puede verificar cat /sys/power/mem_sleepcuál debe regresar

[s2idle] deep

que confirma que el modo de suspensión predeterminado es s2idle (ya que está resaltado entre paréntesis).

Arreglo temporal

Para probar una solución temporal, hazlo echo deep > /sys/power/mem_sleepcomo usuario root. Verifique que haya sido exitoso mirando la salida de la cat /sys/power/mem_sleepcual debería

s2idle [deep]

luego suspenda la computadora portátil y despierte nuevamente. Si sudo journalctl | grep "PM: suspend" | tail -2vuelve

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

entonces el problema debería ser solucionado. Puede poner su computadora en reposo durante un par de horas y verificar si la descarga de la batería mejoró.

Arreglo permanente

Para hacerlo permanente, debe editar su cmdline del gestor de arranque. Para hacerlo, edite como usuario root el archivo / etc / default / grub, ejecutando, por ejemplo sudo -H gedit /etc/default/grub. Reemplace la linea

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

con

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

y regenere su configuración de grub (ejecutar sudo grub-mkconfig -o /boot/grub/grub.cfg).

Intenta crear /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

Y reiniciar. Esto parece estar funcionando para mí, aunque no estoy seguro de que no haya mejorado con el /etc/systemd/logind.confcambio que hice primero. En cualquier caso, no se observa calor ni ruido del ventilador mientras está suspendido con la tapa cerrada, y tampoco responde al ping a través de wifi, que había estado recibiendo, intermitentemente, antes.

La duración de la batería sigue bajando mientras está suspendida, probablemente porque el método de trabajo de suspensión es menos eficiente que el método predeterminado, ideal, que aparentemente no funciona correctamente, pero parece mejor que el comportamiento predeterminado.

Probé en mi XPS 13 9370, no sé acerca de los modelos más antiguos, aunque parece probable que sean similares.

Intenté instalarlo pm-utilsy usarlo, pm-suspendy eso parecía estar suspendido de manera bastante efectiva, así que quería ver si podía hacer systemd-suspendlo mismo.

Revisé los guiones pm-utilspara descubrir qué estaba haciendo realmente, y parece que, en esta situación, estaba haciendo echo -n "mem" > /sys/power/state. Así que creé el /etc/systemd/sleep.confarchivo como se muestra arriba para que coincida.

No está del todo claro cuál es el comportamiento predeterminado. La página de manual systemd-sleep.confdice que la distribución debe incluir /etc/systemd/sleep.conflos valores predeterminados compilados comentados, para que pueda ver esta información, pero en ubuntu este archivo no se encuentra. Sin embargo, noté que si cat /sys/power/stateobtienes:

freeze mem

Así que estoy adivinando que esto es lo que está haciendo por defecto. Supongo que freezepuede estar siendo aceptado, ya que no arroja un error, lo que de otro modo haría que systemd avance mem, pero tal vez en realidad no funcione de manera adecuada o confiable, por razones complejas que parecemos incapaces de determinar. Entonces, solo enviar memes una puñalada esperanzadora para evitar eso y simplemente hacer lo que pm-suspendhace.

Sospecho que la configuración de SuspendMode es realmente superflua y no hace nada de todos modos. Sospecho esto porque cat /sys/power/disksolo te entiende:

[disabled]

¡Soy un nuevo usuario, por lo tanto incapaz de comentar con una observación, obligado a presentarlo como una respuesta como si tuviera mucha confianza en él! Pero creo que está funcionando.

Las otras respuestas aquí son excelentes, en profundidad y bien investigadas.

Desafortunadamente no funcionaron para mi máquina en particular :(

Si tiene gráficos nVidia, parece que hay una solución que está funcionando para un buen número de personas, proporcionada por cascagrossa en la respuesta a esta pregunta: Ubuntu 18.04 se bloquea al reanudar la suspensión

Se sospecha que es un controlador nouveau con errores y puede solucionar los problemas de suspensión agregando nouveau.modeset = 0 a grub y se ha confirmado en los comentarios para ayudar a solucionar el problema para otros también.

Tengo gráficos de Intel en mi máquina problemática y, curiosamente, no he tenido problemas de suspensión con Ubuntu o Kubuntu 18.04 en al menos otras 3 máquinas (las de mi amigo y las mías), entonces, ¿por qué esta máquina en particular está siendo tan tonta al respecto? no esta claro.

Recomiendo a cualquiera que experimente este tipo de problema que siga estos pasos para ayudar a identificar el problema:

1. ¿Tienes gráficos nVidia? Si es así, prueba el truco nouveau.modeset = 0 grub.

2. Compruebe que suspender funciona en absoluto. Si está cerrando la tapa y luego abriéndola más tarde y no se está despertando, puede parecer que no se está 'reanudando'.

   • Debería poder seleccionar suspender manualmente en cualquier escritorio, pero está ligeramente oculto en Gnome Shell: puede presionar prolongadamente el botón de encendido desde el menú superior derecho de la pantalla, o hacer clic en ese botón mientras mantiene presionada la tecla Alt o presionar la tecla Súper y escribir en 'suspender'

   • Al seleccionar suspender, puede comprobar que la pantalla se ha apagado , el LED de alimentación parpadea como debería y esperaría que cualquier ventilador en funcionamiento también se detenga . Si todo esto sucede, pero entonces no se puede conseguir el equipo para que despierten entonces parece ser un problema 'curriculum vitae' en lugar de un problema de 'suspender'.

   • Mi problema ha sido que en realidad no se suspenderá y Murray, quien hizo la pregunta original, cuando Collision le pidió que lo verificara, se dio cuenta de que el problema surgía al suspender manualmente también.

   • En mi caso (en la computadora portátil con un problema) , la pantalla se queda en blanco pero el LED de encendido permanece encendido y si el ventilador está funcionando, continúa funcionando. La máquina no responde a ninguna pulsación de tecla, movimiento del panel táctil o clics o pulsaciones del botón de encendido. Lo único que se puede hacer es apagarlo.

   • Intenté reproducir música al suspender (para comprobar que no se trata solo de que la pantalla se quede en blanco), sino que la música se detiene y la máquina básicamente se ha bloqueado.

3. Pruebe su máquina con un USB en vivo de 18.04 y verifique si tiene problemas de suspensión similares.

   • Esto solo confirmará que los problemas de suspensión no tienen que ver con ningún programa adicional que haya instalado.

   • En mi caso, sospeché que era porque había instalado tlp que podría haber estado interfiriendo de alguna manera con el modo de suspensión, pero el mismo comportamiento ocurrió con un Live USB de Ubuntu 18.04 y Kubuntu 18.04

4. Pruebe las otras dos soluciones bien investigadas proporcionadas aquí por monty47 y StrangeNoises y vea si obtiene buenos resultados.

   • Parecen haber ayudado a varias personas a que la suspensión vuelva a funcionar correctamente el 18.04 y puede que tenga más que ver con que la máquina entre en un estado inactivo en lugar del modo de suspensión (profunda) de una "suspensión" habitual.

5. Si ninguna de las soluciones funciona para resolver sus problemas de suspensión en 18.04, intente con la respuesta aceptada: Ubuntu 18.04 se bloquea al reanudar la suspensión

   • La solución provista por Matalak (quien también hizo la pregunta) fue usar UKUU para probar un kernel 4.14 más antiguo.

   • Mi máquina con problemas no tenía problemas de suspensión con Ubuntu 17.10 y Kubuntu 17.10, por lo que tiene sentido ya que 17.10 usa el kernel 4.14. Ahora se suspende bien tanto en Ubuntu 18.04 como en Kubuntu 18.04 usando el kernel 4.14.

6. Si probó las otras soluciones y solo pudo solucionar sus problemas de suspensión volviendo a un kernel 4.14, es posible que le interese el informe de error: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/ 1774950

   • Parece que solo afecta a algunas máquinas con una combinación específica de hardware y puede ser difícil de identificar entre otros problemas relacionados con nouveau o problemas de s2idle.

   • Parece ser más frecuente para aquellos que ejecutan un Bay Trail Atom Celeron / Pentium, pero otros han informado un problema similar con otras máquinas.

   • Si puede verificar su kern.log después de esta suspensión fallida (es decir, una vez que haya tenido que apagar su máquina y reiniciar) , puede notar que dice PM: suspender la entrada (profunda) y luego no tiene más entradas aparte de Las muchas líneas de arranque de nuevo.

   • Actualmente hay un parche que parece resolver el problema.

   • Si desea agregar su voz al informe de errores, sería interesante ver qué máquinas en particular están afectadas (y verifique que el parche solucione el problema para todos).

También intentando reunir 'Suspender problemas en 18.04' en este hilo: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Creo que este error del kernel está relacionado:

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

Ver comentario # 3 en particular:

[…] En realidad es intencional usar s2idle en esta máquina con el último kernel ascendente.

Solo quiero agregar una respuesta a los usuarios de Thinkpad X1 Carbon 6th Gen que tiene un síntoma similar, es decir, el agotamiento de la batería mientras está suspendido, que también se produce al no entrar en el modo de reposo profundo .

Este problema se discute en este hilo en el foro de Lenovo , en resumen, el X1C6 optó por admitir Windows Modern Standby. Si lee ese hilo cuidadosamente, verá que aunque el síntoma es compartido, las causas principales varían mucho entre el XPS 13 9370 y el X1C6 . Por ejemplo, la salida de cat /sys/power/mem_sleepX1C6 solo [s2idle]indicaría que falta soporte para deepdormir.

Las soluciones publicadas hasta ahora para esta pregunta se aplican solo al XPS 13, y no al X1C6. Hasta donde entiendo, la mejor solución para el problema del modo de suspensión del X1C6 es aplicar un DSDTparche primero proporcionado por Delta Xi y posteriormente actualizado por PombeirP . Esta publicación le muestra cómo aplicar el parche, pero asegúrese de leer la publicación y todas sus actualizaciones antes de cualquier acción.

Escribí un resumen que documenta los problemas relacionados con la instalación de Ubuntu 18.04 en el Thinkpad X1 Carbon 6th Gen, incluidas las soluciones que encontré sobre el problema de arranque lento causado por LVM, así como este problema de sueño profundo .

Estoy usando un Lenovo ThinkPad Edge E531 y experimenté un problema similar en el que la máquina no pudo entrar en reposo profundo. El comportamiento fue intermitente y, al reanudarlo, a veces causaba que el panel táctil dejara de funcionar en el wifi para desconectarse.

Intenté una docena de soluciones sugeridas en línea, pero la única solución que funcionó para mí fue instalar UKUU y actualizar el kernel a 4.19.11-041911-generic.

Solo para cerrar esta pregunta (con suerte ...), acabo de (julio de 2019) tener una actualización de mi LTS 18.04 con HWE que dice solucionar este problema específicamente para el Dell XPS 13 (incluyendo no entrar en s2idle .)

FWIW, acabo de reemplazar la batería de mi XPS 13 2016 (9350) con Ubuntu 16.04 y kernél 4.14.12-041412-generic (la máquina se configuró a principios de 2016 con 15.10 y un kernel personalizado y luego se actualizó a 16.04). Antes del reemplazo, la tapa puso Linux en modo de suspensión como debería (aunque si enchufó la fuente de alimentación mientras estaba suspendida o la desconectó, por ejemplo, cambió el estado en el que Linux pensaba que funcionaría, funcionaría extremadamente lento hasta que se reinicie) . De todos modos, después del reemplazo (batería hinchada), la computadora portátil se reiniciará cuando la tapa esté cerrada.

La configuración de la administración de energía a "Estándar" (desde "Avanzado") en "Configuración de batería primaria" en el BIOS EFI de Dell / AMI (que puede abrir manteniendo presionado Fn-F2 durante el arranque) parece haber resuelto el problema.

Pasé por muchas de las soluciones enumeradas y nada funcionó para popOS en xps 9560 :(

Hasta que vi esta solución hilarante en el sitio web de Dell que estaba tomando de una publicación LTT.

Entonces, mi solución tentativa que parece funcionar hasta ahora es: activar y desactivar ciertas configuraciones de BIOS. Sé que suena francamente idiota, pero juro que parecía funcionar por lo que he probado hasta ahora.

Específicamente, apagué la configuración y / o seleccioné una opción diferente para una configuración, la apliqué, luego la volví a configurar y la apliqué. Las configuraciones que alterné de ida y vuelta fueron:

• Configuración del sistema> Pantalla táctil (desactivado, luego activado nuevamente)

• Administración de energía> Hora de encendido automático (lo cambió a una opción diferente y luego volvió a Desactivado)

• Administración de energía> Activación en muelles USB-C de Dell (apagado, luego encendido)

Funciona muy bien ahora. . . .