Depurando um kernel desligado?

Question

Estou no Linux 4.2.0, o kernel do Ubuntu Wily HWE para o Ubuntu 14.04 (que é o que estou executando).

Há um bug desagradável nos modelos MacBook 11,4 e 11,5 onde os laptops venceram. Na verdade, nunca desligue, eles parecem alcançar a mensagem do kernel Power down e, em seguida, apenas desligue sem desligar. Esse bug provavelmente está impedindo a suspensão e o reinício também. Curiosamente, não se manifesta quando reboot é chamado, apenas quando se tenta apenas parar a máquina.

Os detalhes não são tão relevantes, mas o que é relevante é como eu poderia depurar isso. Existe uma maneira de strace ou depurar o kernel enquanto ele está desligando e observar a saída de alguma forma? Tenho quase certeza de que a lógica de desligamento está fazendo um syscall que está pendurado para sempre e não retorna por algum motivo estranho. Se eu puder descobrir qual syscall não está funcionando, eu poderia continuar em frente para descobrir por que ele não está funcionando e o que especificamente sobre o hardware está fazendo com que o desligamento falhe.

Existe uma prática padrão para depurar um kernel desligado? Preciso de hardware especial? Estou bem escrevendo correções para o kernel, mas nem sei onde começar a procurar por esse problema, a menos que eu possa encontrar o syscall que não está funcionando.

    

Answer 1

Um resumo do que você pode precisar fazer:

1. Faça o download do código-fonte e compile o kernel para habilitar a depuração (configuração - > kernel hacking)
2. Instalar patches do kgdb
3. Conecte-se ao destino por meio de uma porta serial de outra máquina. O alvo poderia ser uma máquina diferente ou poderia ser um emulador como o qemu ou bochs.
4. No código-fonte, identifique a rotina para o encerramento
5. Defina um ponto de interrupção no gdb e percorra até ver o jeito.

Você pode encontrar mais informações sobre essas etapas pesquisando a depuração do kernel usando o kgdb.

Este guia pode ajudá-lo a configurar seu ambiente de depuração. / p>     

Answer 2

Verifique o log do kernel:

nano /var/log/kern.log

Ele terá todas as informações relevantes se o encerramento foi feito corretamente e deve fornecer as informações de depuração necessárias.

Você também pode verificar o dmesg

nano /var/log/dmesg

Você também verá backups destes a partir de inicializações / desligamentos anteriores que serão anexados assim

dmesg.0 kern.log.1

E há arquivos voltando para lá também.

Você pode torná-los mais detalhados adicionando mais opções em seu kernel:

• CONFIG_PRINTK_TIME - adiciona carimbos de hora ao dmesg

• CONFIG_DEBUG_KERNEL - ativa a depuração do kernel

• CONFIG_DETECT_HUNG_TASK - bom para descobrir o que está causando um problema congelamento do kernel

• CONFIG_DEBUG_INFO - garante que você possa decodificar o kernel

• CONFIG_EARLY_PRINTK

• CONFIG_LOG_BUF_SHIFT = 21 - define o tamanho do log do buffer do kernel para o maior buffer

• CONFIG_NETCONSOLE = m - compila o netconsole como um módulo

Answer 3

Eu diria que o problema é que um driver de dispositivo não retorna da chamada de mudança de estado de energia ou algo semelhante - portanto, não haverá mensagens de depuração úteis, a menos que você seja liberal com o printk.

Para confirmar isso usando um hack rápido e sujo, inclua em blacklist todos os drivers não essenciais em sua linha de comando de inicialização do kernel (como presente no grub.cfg) - como wi-fi, rede, etc. para identificar qualquer código de driver mal comportado.