Resposta rápida:
Isso parece relacionado ao erro do kernel # 13998 (veja abaixo como cheguei a essa conclusão) , que não foi reproduzido em versões posteriores do kernel. Se este for o caso, atualizando para um kernel mais novo (ou uma versão mais nova do CentOS, a mesma diferença), deve resolver o problema que está relacionado ao módulo fscache
.
Pistas para fscache
sendo o problema:
PANIC: "BUG: unable to handle kernel NULL pointer dereference at 000000000000002"
Significa que o kernel tentou carregar um endereço de memória que não fazia sentido.
COMMAND: "kslowd002"
Este é o comando que o kernel estava tentando executar quando entrou em pânico. Isso não significa necessariamente que esse foi o comando que causou a falha, mas é um bom ponto de partida. O que é kslowd
? Leia sobre isso aqui .
No backtrace:
#9 [ffff880100003dd8] fscache_object_slow_work_execute at ffffffffa0460e9f [fscache]
É o último procedimento que é executado antes:
[exception RIP: unknown or invalid address]
Este é o ponteiro NULL que o kernel não pôde desreferenciar, em outras palavras, o lugar que o kernel tentou procurar na memória, mas não conseguiu porque não existe. Este é um bug conhecido com fscache
que aparentemente foi resolvido em versões posteriores do kernel.
Aqui é um relatório de bug específico do CentOS-6 (# 0007782) para o mesmo problema que foi não resolvido. A recomendação do CentOS é também certificar-se de que o kernel é a mais nova versão disponível, o que pode, no seu caso, requerer uma atualização para a próxima versão principal estável do CentOS.
Para mais informações sobre a leitura desses despejos de memória, recomendo este tutorial: link