Como determinar qual módulo mancha o kernel?

Question

Meu kernel entra em pânico quando conectado a uma determinada rede sem fio. Eu gostaria de enviar um relatório de bug, mas meu kernel aparentemente está corrompido. De /var/log/messages :

Apr 17 21:28:22 Eiger kernel: [13330.442453] Pid: 4095, comm: kworker/u:1 Tainted: G           O 3.8.4-102.fc17.x86_64 #1

e

[root@Eiger ~]# cat /proc/sys/kernel/tainted 
4096

Eu não consegui encontrar a documentação para o que a máscara de bit 4096 significa , mas o G sinalizador significa que um módulo GPL externo é carregado no kernel . Como descubro qual módulo está corrompendo o kernel?

Eu usei [Tt]aint em /var/log/messages ou dmesg e não encontro nada correspondente a quando um módulo é carregado. Meu kernel é o kernel mais recente do Fedora 17: 3.8.4-102.fc17.x86_64.

UPDATE : pode ser devido ao módulo rts5139 . Ele aparece em lsmod , mas modinfo rts5139 produz ERROR: Module rts5139 not found. Ao inicializar o kernel anterior, 3.8.3-103.fc17.x86_64, este módulo não está listado por lsmod e o kernel não está corrompido ( /proc/sys/kernel/taint é 0).

Eu tentei colocar esse módulo na lista negra

echo 'blacklist rts5139' >> /etc/modprobe.d/blacklist.conf

mas a reinicialização ainda mostra o kernel como corrompido.

    

Answer 1

Bem, eu não acredito que um pacote padrão do kernel do Fedora incluirá quaisquer módulos que possam desencadear essa corrupção, então a pergunta é: que outros módulos do kernel você instalou?

Os candidatos comuns seriam os drivers de gráficos (embora eu ache que eles configurem principalmente o bit "proprietário") e os drivers sem fio.

Se você encontrar algo na saída lsmod que você acha que pode ser uma candidata, execute modinfo <module-name> e veja se a saída inclui intree: Y como qualquer módulo sem que isso acione a mancha que você está vendo.

UPDATE : O módulo rts5139 que você está vendo em lsmod , mas que não parece estar no seu sistema, provavelmente está no initrd e está sendo carregado de lá no início o processo de inicialização antes do sistema de arquivos principal ser montado.

Isso também explica por que a lista negra não funciona, já que você teria que reconstruir o initrd com a lista negra atualizada. Reconstruir o initrd com dracut fará com que o módulo desapareça de qualquer maneira.

    

Answer 2

➜  ~  dmesg | grep -i 'taint'
[   10.029333] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[   10.029364] Disabling lock debugging due to kernel taint

    

Answer 3

Outra maneira de fazer isso é examinar o arquivo taint de cada módulo em /sys/module :

#!/bin/bash

cat /proc/modules |
while read module rest
do
    if [[ $(od -A n /sys/module/$module/taint) != " 000012" ]] ; then
        echo $module
    fi
done

Se um módulo não tiver nada, o arquivo taint conterá apenas uma nova linha, que od representa como " 000012 ". Você não pode verificar o tamanho do arquivo, pois os tamanhos estão todos listados como 4.096 bytes, independentemente do conteúdo real.

    

Answer 4

Isso pode ser (pelo menos em parte) o módulo do kernel vboxdrv do VirtualBox. É GPL, mas os mantenedores do kernel agora sinalizam os kernels carregados como contaminados. Consulte o link para obter informações.

Não tenho certeza se descarregar esse módulo irá "destruir" o kernel, mas se você o tiver carregado, provavelmente é o que está causando isso (pelo menos em parte).

Informações sobre o valor do número podem ser encontradas aqui: link Ele não diz qual módulo, mas você pode ver as razões. Basicamente, se o valor não for 0, está contaminado.

    

Answer 5

Verifique seu log de inicialização ou assista ao processo de inicialização no estágio inicial (antes que os discos sejam montados em RW). Este pode ser um módulo ruim em seu initrd.

Você tem DKMS ou algo parecido no lugar?