Instalei o Debian 8 com o sysvinit e o Xfce em um ThinkPad X220. A placa de vídeo é Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) / Integrated Graphics Chipset: Intel(R) HD Graphics 3000 . As versões do kernel disponíveis para mim são o 4.7 de backports e o 3.16 (strongmente corrigido pela equipe de kernel da Canonical) da stable.
Quando eu hibernar usando o kernel puro ( echo disk > /sys/power/state feito pelo pm-hibernate executado pelo xfce4-pm-helper) e XScreenSaver desliga a tela, ao reiniciar a tela ainda está desligada (não apenas a luz de fundo: verifiquei com uma lanterna), e nada parece ativá-lo novamente (eu tentei Ctrl + Alt + F * sugerido em ThinkWiki e Alt + SysRq + V ), mas o o sistema restante parece estar a funcionar (pelo menos, quando faço um Alt + SysRq + E , I , S , U , B , posso encontrar mensagens de um currículo bem-sucedido e syslogd sendo finalizado pelo sinal 15 em /var/log/syslog ).
Consigo me conectar via ssh, mas chvt 1; chvt 7 e várias combinações de export DISPLAY=:0; xrandr --output LVDS1 --off; xrandr --output LVDS1 --auto não fazem nada. Desativei o LVDS1 e tentei reativá-lo. Eu obtive: xrandr: Configure crtc 0 failed e as seguintes linhas em dmesg :
[ 390.432051] [drm:drm_framebuffer_remove [drm]] *ERROR* failed to reset crtc ffff9ae6caa2f000 when fb was deleted
[ 390.432066] [drm:drm_plane_force_disable [drm]] *ERROR* failed to disable plane with busy fb
Algumas pessoas sugeriram ddccontrol , mas não detectam o DDC no meu sistema. A tela está ligada durante a hibernação, ela continua funcionando após a retomada.
Se eu instalar o uswsusp , o hibernate funciona (como bônus, recebo alguma forma de compactação e capacidade de cancelar a hibernação no último segundo), mas apenas a maior parte do tempo. O procedimento usual de retomada é assim:
resume: Loading image data pages (no modo de vídeo padrão) s2disk: returned to userspace , depois eu recebo a caixa de diálogo de bloqueio do XScreenSaver. Mais cedo ou mais tarde, logo após a tela Loading data pages ficar preta e o laptop ser redefinido (vejo o logotipo de inicialização da BIOS).
Instalei o grub-efi em um thumbdrive (para evitar o particionamento) em prol do pstore com backup. Durante uma semana, eu hibernei e retomei o laptop uma ou duas vezes por dia sem problemas e quase acreditei que a EFI resolveu o problema, mas a falha ocorreu novamente e não foram encontrados registros em /sys/fs/pstore ( pstore: Registered efi as persistent store backend é visível em dmesg). Eu acho que quando recomeçamos com sucesso pela última vez antes que o próximo falhasse, a tela não estava totalmente cheia de ruídos e uma listra preta era mais fácil na parte de baixo antes que eu recuperasse a tela returned to userspace e X.
Até onde eu sei, suspender para RAM funciona perfeitamente com echo mem > /sys/power/state e s2ram . Eu faço isso com mais frequência do que hibernando (várias vezes por dia) e, até o momento, não ocorreram falhas.
Por enquanto, configurei o XScreenSaver para nunca desligar a tela, evitando assim a causa mais comum da falha (bloqueio do XScreenSaver e desativação da tela antes da hibernação), mas ainda posso encontrar a falha fechando o tampa rápido o suficiente depois de escolher "hibernar".
UPD : Eu tenho usado o hibernate do kernel puro há algum tempo, e acabei de encontrar a mesma redefinição após carregar a imagem salva que está acontecendo comigo ao usar o uswsusp. Aparentemente eu nunca usei este X220 por tempo suficiente para que isso aconteça antes. Então, como se constata, eu não tenho maneiras confiáveis de hibernar: ambos echo disk > /sys/power/state e s2disk falham após 5-7 hibernações, mas o kernel puro também não restaura o estado da placa de vídeo corretamente.
O que mais posso tentar fazer com que alguma forma de hibernação funcione?
Com linux-image-amd64 versão 4.8.0-0.bpo.2 de jessie-backports Estive s2disk -hibernando o X220 em questão por 25 dias sem nenhuma reinicialização misteriosa após carregar a imagem (vou reinicializar agora para atualizar o kernel para 4.9.0-0.bpo.1 ).
Um relatório de erros foi arquivado sobre o problema da luz de fundo, mas é improvável que receber atividade, pois o método s2disk aparentemente funciona.