Eu tenho duas sugestões para começar.
A primeira que você não vai gostar. Não importa quão estável você acha que seu sistema com overclock é, seria meu primeiro suspeito. E qualquer desenvolvedor que você reportar o problema dirá a mesma coisa. Sua carga de trabalho de teste estável não está necessariamente usando as mesmas instruções, enfatizando muito o subsistema de memória, seja qual for. Pare de overclock. Se você quer que as pessoas acreditem que o problema não é overclock, então faça acontecer quando não estiver fazendo overclock, para que você possa obter um relatório de bug limpo. Isso fará uma enorme diferença em quanto esforço outras pessoas investirão na solução desse problema. Ter software livre de bugs é um ponto de orgulho, mas os relatórios de pessoas com configurações de hardware particularmente questionáveis são frustrantes que provavelmente não envolvem um bug real.
O segundo é pegar os dados oops, que, como você percebeu, não vai para nenhum dos lugares que você mencionou. Se o travamento acontece apenas durante a execução do X11, acho que o console local está bem fora (é uma dor de qualquer maneira), então você precisa fazer isso em um console serial, pela rede ou salvando em disco local (o que é mais complicado do que pode parecer porque você não quer que um kernel não confiável corrompa seu sistema de arquivos). Aqui estão algumas maneiras de fazer isso:
- use netdump para salvar em um servidor pela rede. Eu não faço isso há anos, então eu não tenho certeza se este software ainda está por aí e trabalhando com kernels modernos, mas é fácil o suficiente para valer a pena.
- inicializar usando um console serial ; você precisará de uma porta serial livre em ambas as máquinas (seja uma velha escola ou um adaptador serial USB) e um cabo de modem nulo; você configuraria a outra máquina para salvar a saída.
- O kdump parece ser o que as crianças legais usam hoje em dia, e parece bastante flexível, embora não fosse Não seja minha preferência, porque parece complexo para configurar. Em suma, envolve a inicialização de um kernel diferente que pode fazer qualquer coisa e inspecionar o conteúdo da memória do kernel anterior, mas você tem que essencialmente construir todo o processo e não vejo muitas opções enlatadas por aí. Atualização: Na verdade, existem algumas coisas boas na distribuição; no Ubuntu, linux-crashdump
Depois de obter as informações de depuração, há uma ferramenta chamada ksymoops que pode ser usada para transformar os endereços em nomes de símbolos e comece a ter uma ideia de como seu kernel travou. E se o despejo simbolizado não significa nada para você, pelo menos isso é algo útil para relatar aqui ou talvez na lista de discussão / rastreador de bugs da sua distribuição Linux.
A partir de crash no seu crashdump, você pode tentar digitar log e bt para obter um pouco mais de informação (coisas registradas durante o pânico e um backtrace de pilha). Seu Fatal Machine check parece estar vindo de aqui , embora. Ao analisar o código, seu processador relatou uma Exceção de verificação de máquina - um problema de hardware. Mais uma vez, minha primeira aposta seria devido ao overclocking. Parece que pode haver uma mensagem mais específica na saída log que poderia lhe dizer mais.
Também a partir desse código, parece que se você inicializar com o parâmetro mce=3 kernel, ele parará de funcionar ... mas eu não recomendaria isso, exceto como uma etapa de diagnóstico. Se o kernel do Linux acha que vale a pena perder esse erro, provavelmente está certo.