Como depurar suspensão?

Estou usando o Ubuntu há cerca de cinco anos e ainda não consigo suspendê-lo quando quero. É bastante irritante que eu possa programar uma tempestade, invadir a máquina de várias outras maneiras e, no entanto, quando tento suspendê-la ou depurá-la, falho miseravelmente.

Eu preciso de ajuda.

Onde começo a encontrar o problema? O que faço para corrigi-lo? Estou colocando uma recompensa por isso, porque literalmente perdi horas da minha vida com esse problema, e deixar meu computador ligado o tempo todo é terrível.

Os sintomas:

• Pressionar suspender leva meu computador a um estado em que ele tem um cursor piscando, os fãs estão funcionando, parece que o HD foi desligado (eu acho) e não posso fazer nada para trazê-lo de volta desse estado (menos de uma reinicialização forçada).
• Possivelmente relacionado: meus fãs ficam ligados mesmo após um desligamento e, mesmo assim, tenho que pressionar o botão liga / desliga por cinco segundos antes de poder iniciá-lo novamente.
• Não sei quais logs examinar para depurar o problema, e imagino que eles seriam danificados na reinicialização de qualquer maneira.

Por favor, ajude. Isso me deixa completamente louco, e eu moro com isso há mais de um ano.

Em https://wiki.ubuntu.com/UnderstandingSuspend

• O maior problema é o hardware gráfico
• tente suspender sem dispositivos restritos (nvidia, fglrx)
• o kernel não sabe como lidar com dispositivos gráficos
• BIOS sabe como restaurar o estado dos gráficos
  • via modo segmentado de 16 bits, C000: xxxx contém a ROM de vídeo visível de 64k.
  • iniciando a execução em C000: 0003, normalmente re-POST o BIOS do vídeo (/ usr / sbin / vbetool post)
    • mais difícil no modo de 64 bits, pois as chamadas de 16 bits precisam ser emuladas.
    • alguma memória está no intervalo 3-4G, o que requer remapeamento ao emular para evitar atingir o kernel mapeado no mesmo espaço. o BIOS de vídeo pode ter paginado o código POST pela janela C000. O BIOS da nvidia reescreve a ROM para retornar para interromper o re-POST e tentar suspender do console (via /etc/acpi/sleep.sh)
  • verifique se você está desconectado do Xorg (ou execute sleep.sh com o argumento "force")
  • se o BIOS do vídeo não for deixado em bom estado, retornar ao Xorg pode travar o hardware
  • testa o capslock no currículo (se não houver capslock, o kernel travou)
  • se a luz de fundo não voltar, o BIOS de vídeo provavelmente não reinicializou
  • se a tela estiver em branco, mas tiver uma luz de fundo, tente pressionar enter ou alternar entre terminais virtuais
  • tente no modo de usuário único (anexando "single" às ​​opções de inicialização do kernel do grub)
  • para obter detalhes sobre ações, tente bash -x /etc/acpi/sleep.sh> /root/sleep.log 2> & 1
  • consulte as informações do dmidecode que correspondem às configurações em /usr/share/acpi-support/*.config
  • se o console do modo de usuário único suspender ou retomar falhar
  • Rastreamento de PM (eco "1"> / sys / power / pm_trace) que gravará os hashes do dispositivo no timer do sistema
  • tentativa de suspender
  • após a falha, na reinicialização, examine a saída dmesg para entradas de "hash do dispositivo" para rastrear o dispositivo que travou o sistema durante a retomada.
  • ciente de que isso redefinirá o relógio do sistema, e o fsck surtará ("ficou sem fsck por 31337 dias"). considere tune2fs -c 0 / dev / your / filesystems.

Você pode encontrar muitas orientações / conselhos aqui e aqui .

Na sua descrição, parece que o seu ACPI não está funcionando corretamente ou os drivers do kernel estão impedindo uma suspensão total. O segundo link mostra como lidar com esse tipo de problema.

Os sintomas:

• Pressionar suspender leva meu computador a um estado em que ele tem um cursor piscando, os fãs estão funcionando, parece que o HD foi desligado (eu acho) e não posso fazer nada para trazê-lo de volta desse estado (menos de uma reinicialização forçada).
• Possivelmente relacionado: meus fãs ficam ligados mesmo após um desligamento e, mesmo assim, tenho que pressionar o botão liga / desliga por cinco segundos antes de poder iniciá-lo novamente.
• Não sei quais logs examinar para depurar o problema, e imagino que eles seriam danificados na reinicialização de qualquer maneira.

Meu site para muitos problemas de Linux é o Arch Linux. Aqui está o que é publicado sobre problemas de suspensão / retomada semelhantes ao seu:

Ativações instantâneas de suspensão

Para alguns sistemas Intel Haswell com o chipset LynxPoint e LynxPoint-LP, são relatadas ativações instantâneas após a suspensão. Eles estão vinculados a implementações incorretas do BIOS ACPI e a como o xhci_hcdmódulo o interpreta durante a inicialização. Como solução alternativa, os sistemas afetados são adicionados a uma lista negra (nomeada XHCI_SPURIOUS_WAKEUP) pelo kernel, caso a caso. [ 2 ]

A retomada instantânea pode ocorrer, por exemplo, se um dispositivo USB for conectado durante a suspensão e os gatilhos de ativação da ACPI estiverem ativados. Uma solução viável para esse sistema, se ainda não estiver na lista negra, é desativar os gatilhos de ativação. Um exemplo para desativar a ativação por USB é descrito a seguir. [ 3 ]

Para visualizar a configuração atual:

$ cat /proc/acpi/wakeup

Device  S-state   Status   Sysfs node
...
EHC1      S3    *enabled  pci:0000:00:1d.0
EHC2      S3    *enabled  pci:0000:00:1a.0
XHC       S3    *enabled  pci:0000:00:14.0

...

Os dispositivos relevantes são EHC1, EHC2e XHC(para USB 3.0). Para alternar o estado deles, é necessário ecoar o nome do dispositivo no arquivo como raiz.

# echo EHC1 > /proc/acpi/wakeup
# echo EHC2 > /proc/acpi/wakeup
# echo XHC > /proc/acpi/wakeup

Isso deve resultar na suspensão do trabalho novamente. No entanto, essas configurações são apenas temporárias e precisam ser definidas a cada reinicialização. Para automatizar isso, dê uma olhada no systemd # Escrevendo arquivos da unidade . Consulte o tópico BBS para obter uma solução possível e mais informações.

O artigo inteiro do Arch Linux acima sobre Suspend / Resume é uma ótima referência para muitas áreas:

1 Low level interfaces
    1.1 kernel (swsusp)
    1.2 uswsusp
2 High level interfaces
    2.1 systemd
3 Hibernation
    3.1 About swap partition/file size
    3.2 Required kernel parameters
        3.2.1 Hibernation into swap file
    3.3 Configure the initramfs
4 Troubleshooting
    4.1 ACPI_OS_NAME
    4.2 VAIO Users
    4.3 Suspend/hibernate doesn't work, or not consistently
    4.4 Wake-on-LAN
    4.5 Instantaneous wakeups from suspend