[RESOLVIDO] Semp Toshiba IS-1454: suspender e hibernar não funcionam.

[dedalu]

Não sou iniciante em linux, mas nunca havia instalado um num notebook. 

Comprei o Semp Toshiba IS 1454 porque vinha com linux (um tal de Insigne, horrível!!!) e resolvi tentar o Intrepid Beta 64-bits. Tudo está muito bem, mas não consigo suspender nem hibernar de maneira alguma usando os recursos normais do Ubuntu.

Quando pressiono a tecla para suspender, o sistema sai para o console e trava. O LCD continua acesso, mas só um cursor piscante aparece. Nenhuma combinação de tecla funciona, mas CapsLock (Fixa) faz o led acender e apagar (não é kernel panic, portanto). O disco, acho, desliga também. Mas o computador não entra no modo de suspensão de modo algum. O único remédio é dar reboot.

No terminal, tentei o pm_suspend com vários quirks, mas nenhum deles funciona. O mais interessante é que consigo entrar no modo suspenso usando "sudo /etc/acpi/sleep.sh force".

Não sei o que está acontecendo. Tentei de tudo que encontrei nos fóruns. Até o procedimento de debug com RTC, mas não funcionou.

O que posso fazer? Agradeço qualquer conselho.

[Tota]

Bem, eu começaria analizando qual processo "trava" e não deixa o sistema ir em frente.

É conhecido nos EeePc que, ao desligar ou suspender, aconteça o mesmo causado pelo modulo Snd_hda_intel.

Sugestão apenas: entre na Bios, desbilite tudo ( menos o que impede o sistema em funcionar, som, usb, placas de rede etc, ) e tente suspender.

Eu editei meu /grub/menu.lst e retirei o argumento quiet, para ver os processos sendo carregados / descarregados, parou no Snd_intel e eu corri atras.

Se continuar travando verifique o log do sistema.

Pensamento tosco: se com um sabor de Linux funciona, Tem que funcionar em outro sabor. Só vai dar mais, ou menos trabalho.

Aí é só perseguir um "workaround" para o módulo mal comportado.

Se por alguma incrivel coincidência for o mesmo módulo intel, leia => http://ubuntuforum-br.org/index.php/topic,39896.msg236973.html#msg236973

[],s

[dedalu]

Valeu pela resposta. Não funcionou, mas andei um pouco mais. Os scripts em /usr/lib/pm-utils/sleep.d/ são todos processados e o /var/log/pm-suspend.log mostra "... performing suspend". Como na url que você passou propõem um script para desativar o alsa, tentei usar "/sbin/alsa suspend && pm-suspend" no modo single e deu na mesma...

O buraco é mais embaixo: o computador não chega nem a suspender. E minha BIOS é daquelas sem opção alguma...

Vou tentar descarregar os módulos um por um e ver se algum deles é culpado. Mas estou achando que é um bug na comunicação com a ACPI.

Computador novo é soda, é igual quebra-cabeças 

[dedalu]

EDITADO: ATENÇÃO: não fiz muitos testes! Causa, às vezes, uma falha que faz o processo events/0 tomar 100% da CPU!

Solução: descarregar o módulo rtl8187 configurando o pm-utils. Há algumas configurações específicas para o meu modelo Semp Toshiba IS-1454, mas acho que boa parte é comum a quem tem esse problema com o módulo rtl.

A seguir, os passos que usei para conseguir suspender e hibernar com sucesso (na maioria das vezes).

1) O primeiro problema é fazer o computador ir para o estado de suspensão. Para isso, é necessário remover o módulo da placa wireless:

Minha primeira tentativa foi criar o arquivo /etc/pm/config.d/10semp_toshiba_workarounds com o seguinte conteúdo:

Código Selecionar Expandir


SUSPEND_MODULES="rtl8187"


SUSPEND_MODULES faz com que o pm-suspend remova o módulo antes de suspender. Essa é a solução, digamos, canônica.

MAS não funcionou direito comigo, causando muito o problema com o events/0 já citado.

O que fiz, então, foi comentar aquela diretiva e criar o arquivo /etc/pm/sleep.d/09semp_toshiba_workarounds com o seguinte conteúdo:

Código Selecionar Expandir


#!/bin/sh
case "$1" in
    hibernate|suspend)
rmmod rtl8187
sleep 5
;;
    thaw|resume)
modprobe rtl8187
sleep 5
;;
    *) exit $NA
;;
esac


Notem que ele apenas se diferencia da diretiva SUSPEND_MODULES pela pausa de 5 segundos. Por algum motivo isso me ajudou. O nome do arquivo deve começar com um número menor que 10, pois ele deverá ser chamado imediatamente depois de /usr/lib/pm-utils/sleep.d/10NetworkManager no momento da suspensão; e imediatamente antes, no momento de acordar.

2) No console do linux o LCD não acendia de novo, então (isso é mais complicado) tive que ensinar o hal a passar --quirk-vbe-post para o pm-suspend:

Criei o arquivo /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-semp-toshiba.fdi com o seguinte conteúdo, específico para meu modelo (notem que deixei comentadas várias outras opções, para facilitar outras tentativas):

Código Selecionar Expandir


<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="Semp Toshiba">
      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" prefix="IS-1454">
        <!-- merge key="power_management.quirk.dpms_on" type="bool">true</merge-->
        <!-- merge key="power_management.quirk.pci_save" type="bool">true</merge-->
        <!-- merge key="power_management.quirk.s3_bios" type="bool">true</merge -->
        <!-- merge key="power_management.quirk.s3_mode" type="bool">true</merge -->
        <merge key="power_management.quirk.vbe_post" type="bool">true</merge>
        <!-- merge key="power_management.quirk.vbestate_restore" type="bool">true</merge -->
      </match>
    </match>
  </device>
</deviceinfo>


É isso.



Referência: http://people.freedesktop.org/~hughsient/quirk/ (muito boa!)
Bug report: Intrepid: cannot suspend with module rtl8187 loaded.



O próximo passo é fazer as teclas funcionarem.