Isso estava funcionando perfeitamente em 17.10, mas após a atualização para 18.04 ontem, quando a tampa está fechada, a tela desliga, mas não é suspensa corretamente.

Viajo muito e imediatamente notei o calor (e a carga da bateria) ao retirá-lo do estojo de viagem.

Tentei descomentar essas linhas no /etc/systemd/logind.conf

HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend

e reiniciado, mas não fez nenhuma diferença.

Acho que consegui descobrir o que estava acontecendo, graças a essas duas fontes: Notas de instalação do Dell XPS 13 (9370) ArchLinux e Fórum do Arch Linux .

Por alguma razão, o laptop não está mais em sono profundo, mas em um s2idlemodo que é apenas um tipo de suspensão de tela desativada.

Diagnóstico do problema

Para confirmar se esse é o caso do seu sistema, suspenda o laptop usando seu método favorito (feche a tampa, pressione Fn+ End, escreva pm-suspendem um terminal se você tiver pm-utilsinstalado ou pressione o Windowstipo de tecla suspende pressione a Entertecla).

Acordar do modo e tipo de suspensão em um terminal: sudo journalctl | grep "PM: suspend" | tail -2. Se a saída for

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

Então você não está entrando no sono profundo. Você também pode verificar cat /sys/power/mem_sleepqual deve retornar

[s2idle] deep

que confirma que o modo de suspensão padrão é s2idle (pois é destacado entre colchetes).

Reparo provisório

Para tentar uma correção temporária, faça echo deep > /sys/power/mem_sleepcomo usuário root. Verifique se foi bem-sucedido observando a saída da cat /sys/power/mem_sleepqual deve ser

s2idle [deep]

depois suspenda o laptop e acorde novamente. Se sudo journalctl | grep "PM: suspend" | tail -2retorna

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

então o problema deve ser corrigido. Você pode colocar o computador em suspensão por algumas horas e verificar se o consumo de bateria melhorou.

Correção permanente

Para torná-lo permanente, você deve editar o cmdline do seu carregador de inicialização. Para fazer isso, edite como usuário root o arquivo / etc / default / grub, executando, por exemplo sudo -H gedit /etc/default/grub. Substitua a linha

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

com

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

e regenere sua configuração do grub (execução sudo grub-mkconfig -o /boot/grub/grub.cfg).

Tente criar /etc/systemd/sleep.conf:

[Sleep]
SuspendMode=
SuspendState=mem

E reinicie. Isso parece estar funcionando para mim, embora não tenha certeza de que também não melhorei com a /etc/systemd/logind.confalteração que fiz primeiro. Em qualquer caso, nenhum calor ou ventilador ruído é observado enquanto suspenso com a tampa fechada, e ele não responde a pingue sobre wi-fi tanto, que eu tinha recebido, de forma intermitente, antes.

A duração da bateria ainda diminui enquanto suspensa, provavelmente porque o método de trabalho de suspensão é apenas menos eficiente que o método padrão ideal, que aparentemente não está funcionando corretamente, mas parece melhor que o comportamento padrão.

Tentei no meu XPS 13 9370, não sei sobre modelos mais antigos, embora pareça provável que eles sejam semelhantes.

Eu tinha tentado instalar pm-utilse usar pm-suspende isso parecia estar suspendendo bastante efetivamente, então eu queria ver se eu poderia systemd-suspendfazer a mesma coisa.

Examinei os scripts pm-utilspara descobrir o que estava realmente fazendo, e parece que, nessa situação, estava fazendo echo -n "mem" > /sys/power/state. Então, eu criei o /etc/systemd/sleep.confarquivo como mostrado acima para combiná-lo.

Não está totalmente claro qual é o comportamento padrão. A página de manual systemd-sleep.confdiz que a distribuição deve incluir /etc/systemd/sleep.confos padrões compilados comentados, para que você possa ver essas informações, mas no ubuntu esse arquivo está ausente. Notei, porém, que se cat /sys/power/statevocê receber:

freeze mem

Então, eu estou supondo que este é o que está fazendo por padrão. Meu palpite é que isso freezepode estar sendo aceito, na medida em que não gera um erro, o que faria com que o systemd seguisse em frente mem, mas talvez não funcione corretamente, ou de forma confiável, por razões complexas que parecemos incapazes de determinar. Portanto, apenas enviar memé uma tentativa de evitar isso e fazer o que pm-suspendfaz.

Eu suspeito que a configuração SuspendMode é realmente supérflua e não faz nada de qualquer maneira. Eu suspeito disso porque cat /sys/power/diskvocê recebe:

[disabled]

Sou um novo usuário, portanto, incapaz de comentar com uma observação, forçado a apresentá-la como uma resposta, como se estivesse super confiante nela! Mas acho que está funcionando.

As outras respostas aqui são excelentes, aprofundadas e bem pesquisadas.

Infelizmente eles não funcionaram para minha máquina específica :(

Se você tiver gráficos da nVidia, parece haver uma correção que está funcionando para um bom número de pessoas, fornecida por cascagrossa na resposta a esta pergunta: O Ubuntu 18.04 falha ao retomar a suspensão

Suspeita-se de ser um driver nouveau com erros e pode resolver problemas de suspensão adicionando nouveau.modeset = 0 ao grub e foi confirmado nos comentários por ajudar a corrigir o problema também para outros.

Tenho gráficos Intel na minha máquina com problemas e, curiosamente, não tive problemas de suspensão com o Ubuntu ou o Kubuntu 18.04 em pelo menos três outras máquinas (da minha amiga e da minha), então por que essa máquina em particular está sendo tão idiota com isso? não é claro.

Eu recomendo que qualquer pessoa com esse tipo de problema siga estas etapas para ajudar a identificar o problema:

1. Você tem gráficos da nVidia? Nesse caso, tente o truque nouveau.modeset = 0 grub.

2. Verifique se a suspensão funciona mesmo. Se você estiver fechando a tampa e abrindo-a mais tarde e não estiver acordando, pode parecer que não está sendo retomado.

   • Você deve poder selecionar manualmente a suspensão em qualquer área de trabalho, mas está um pouco oculta no Gnome Shell - você pode pressionar longamente o botão liga / desliga no menu superior direito da tela ou clicar nesse botão enquanto mantém pressionada a tecla Alt ou pressionar a tecla Super e digitar em 'suspender'

   • Ao selecionar suspender, você pode verificar se a tela foi desligada , o LED de energia está piscando como deveria e você espera que qualquer ventilador que esteja funcionando também pare . Se tudo isso acontece, mas então você não pode obter a sua máquina para despertar em seguida, ele parece ser um problema 'currículo', em vez de um problema 'suspender'.

   • Meu problema é que ele não está realmente sendo suspenso e Murray, que fez a pergunta original, quando solicitado pela colisão Dois para verificar isso, percebeu que o problema estava surgindo ao suspender manualmente também.

   • No meu caso (no laptop com um problema) , a tela fica em branco, mas o LED de energia permanece aceso e, se o ventilador estiver funcionando, ele continuará funcionando. A máquina não responde a nenhum pressionamento de tecla, movimento do touchpad ou cliques ou pressionamentos do botão liga / desliga. A única coisa que pode ser feita é desligá-lo.

   • Eu tentei tocar música enquanto suspendia (para verificar se não é apenas a tela que fica em branco), mas a música para e a máquina basicamente se agarra.

3. Experimente sua máquina com um Live USB de 18.04 e verifique se há problemas de suspensão semelhantes.

   • Isso apenas confirmará que os problemas de suspensão não estão relacionados aos programas adicionais que você instalou.

   • No meu caso, suspeitei que fosse porque eu havia instalado o TLP, o que poderia estar interferindo no modo de suspensão, mas o mesmo comportamento ocorreu com um Live USB do Ubuntu 18.04 e do Kubuntu 18.04.

4. Experimente as outras duas soluções bem pesquisadas fornecidas aqui por monty47 e StrangeNoises e veja se você obtém bons resultados.

   • Eles parecem ter ajudado várias pessoas a suspender o funcionamento novamente no 18.04 e podem ter mais a ver com a máquina entrando no estado s2idle do que no modo de suspensão (profundo) de uma 'suspensão' usual.

5. Se nenhuma das soluções estiver funcionando para resolver os problemas de suspensão no 18.04, tente a resposta aceita: o Ubuntu 18.04 trava ao retomar a suspensão

   • A solução fornecida por Matalak (que também fez a pergunta) foi usar o UKUU para tentar um kernel 4.14 mais antigo.

   • Minha máquina com problemas não teve problemas de suspensão com o Ubuntu 17.10 e o Kubuntu 17.10, por isso faz sentido, já que o 17.10 usa o kernel 4.14. Agora ele suspende bem o Ubuntu 18.04 e o Kubuntu 18.04 usando o kernel 4.14.

6. Se você tentou as outras soluções e só conseguiu corrigir os problemas de suspensão voltando ao kernel 4.14, pode estar interessado no relatório de erros: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/ 1774950

   • Parece afetar apenas algumas máquinas com uma combinação específica de hardware e pode ser difícil identificá-lo entre outros problemas relacionados ao nouveau ou s2idle.

   • Parece ser mais prevalente para aqueles que executam um Bay Trail Atom Celeron / Pentium, mas outros relataram um problema semelhante com outras máquinas.

   • Se você conseguir verificar o seu kern.log após esta falha na suspensão (ou seja, depois de desligar a máquina e reiniciar), poderá notar que diz PM: suspender a entrada (profunda) e, em seguida, não há outras entradas além de as muitas linhas de inicialização novamente.

   • Atualmente, existe um patch que parece resolver o problema.

   • Se você deseja adicionar sua voz ao relatório de erros, seria interessante ver quais máquinas específicas são afetadas (e verifique se o patch corrige o problema para todos).

Também tentando reunir 'Suspend Issues in 18.04' neste tópico: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724

Eu acredito que este bug do kernel esteja relacionado:

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

Veja o comentário # 3 em particular:

[…] É realmente intencional usar o s2idle nesta máquina com o kernel upstream mais recente.

Só quero adicionar uma resposta aos usuários do Thinkpad X1 Carbon 6th Gen que tenham um sintoma semelhante, ou seja, o consumo de bateria enquanto estiver suspenso, causado também por não entrar no modo de sono profundo .

Esta questão é discutida neste tópico no fórum da Lenovo . Em resumo, o X1C6 optou por oferecer suporte ao Windows Modern Standby. Se você ler atentamente esse encadeamento, verá que, embora o sintoma seja compartilhado, as causas principais variam muito entre o XPS 13 9370 e o X1C6 . Por exemplo, a saída do cat /sys/power/mem_sleepX1C6 [s2idle]indica apenas falta de suporte para deepsuspensão.

As soluções postadas até o momento para esta pergunta se aplicam somente ao XPS 13 e não ao X1C6. Tanto quanto eu entendo, a melhor solução para o problema do modo de suspensão do X1C6 é aplicar um DSDTpatch primeiro fornecido pelo Delta Xi e posteriormente atualizado pelo PombeirP . Esta postagem mostra como aplicar o patch, mas leia a postagem e todas as atualizações antes de qualquer ação.

Eu escrevi uma essência documentando problemas relacionados à instalação do Ubuntu 18.04 no Thinkpad X1 Carbon 6th Gen, incluindo soluções que encontrei sobre o problema de inicialização lenta causado pelo LVM e esse problema de sono profundo .

Estou usando um Lenovo ThinkPad Edge E531 e tive um problema semelhante em que a máquina não conseguiu entrar em sono profundo. O comportamento era intermitente e, em resumo, às vezes fazia com que o touchpad parasse de funcionar no wifi para desconectar.

Tentei uma dúzia de correções sugeridas on-line, mas a única solução que funcionou para mim foi instalar o UKUU e atualizar o kernel para 4.19.11-041911-generic.

Apenas para encerrar esta questão (espero ...), eu acabei de (julho de 2019) ter uma atualização para o meu 18.04 LTS com HWE, que afirma corrigir esse problema especificamente para o Dell XPS 13 (incluindo não entrar no s2idle .)

FWIW, substituí a bateria do meu 2016 XPS 13 (9350) pelo Ubuntu 16.04 e pelo kernél 4.14.12-041412-generic (a máquina foi configurada no início de 2016 com 15.10 e um kernel personalizado foi atualizado para 16.04). Antes da substituição, a tampa colocava o Linux no modo de suspensão como deveria (embora, se você conectasse o PSU enquanto estava em suspensão ou o desconectasse, por exemplo, altere o estado em que o Linux pensava que funcionava, ficaria extremamente lento até a reinicialização) . De qualquer forma, após a substituição (bateria inchada), o notebook seria reiniciado para arrancar quando a tampa estiver fechada.

Definir o gerenciamento de energia como "Padrão" (de "Avançado") em "Configuração da bateria primária" no BIOS EFI da Dell / AMI (que você pode ativar mantendo Fn-F2 durante a inicialização) parece ter resolvido o problema.

Passei por muitas das soluções listadas e nada funcionou para o popOS no xps 9560 :(

Até que vi essa correção hilária no site da dell, que estava sendo retirada de um post do LTT.

Portanto, minha solução provisória que parece funcionar até agora é: ativar e desativar determinadas configurações do BIOS. Sei que parece absolutamente idiota, mas juro que pareceu funcionar com o que testei até agora.

Especificamente, eu desliguei as configurações e / ou selecionei uma opção diferente para uma configuração, apliquei-a e, em seguida, configurei-a novamente. As configurações que eu alternava eram:

• Configuração do sistema> Tela sensível ao toque (desativado e depois ativado)

• Gerenciamento de energia> Tempo de ativação automática (alternou para uma opção diferente e depois para Desativado)

• Gerenciamento de energia> Ativar nas estações USB-C da Dell (desativado e ativado)

Funciona muito bem agora. . . .