Como entender a saída de descarga do kernel panic kernel?

3

Esta é a saída que recebo quando executo um dos meus aplicativos:

Kernel bug detected[#1]:
Cpu 0
$ 0   : 00000000 00000000 0fffff00 0fffff00
$ 4   : c6800000 850b7780 8b0043c0 00000040
$ 8   : 000004ac 000004ac 00000002 844e8000
$12   : 00000000 feced300 8430d2ac 0000000a
$16   : 00000040 000000fc 8b759300 00000001
$20   : 00000012 84370000 00000004 00000009
$24   : 00000000 8403d4f4                  
$28   : 8b1c0000 8b1c3ee0 0000000a 84255764
Hi    : 003d08ef
Lo    : 79432700
epc   : 840a754c 0x840a754c
    Tainted: P          
ra    : 84255764 0x84255764
Status: 1100dc03    KERNEL EXL IE 
Cause : 00800034
PrId  : 00019749 (MIPS 74Kc)
Modules linked in: em8xxxcursor(P) em8xxxfb em8xxxcopybit(P) pmem_rua em8xxx(P) llad(P)
Process events/0 (pid: 4, threadinfo=8b1c0000, task=8b0323d8, tls=00000000)
Stack : 8b0323d8 8402d074 843d0c68 843d10e8 8b1c3f80 8b0323d8 843d0cc8 8b2d6de8
        8b2d6de8 8402d194 00000003 00000000 00000000 84300000 84374104 8b124c80
        84255238 fffffffc efffffff 8431d16c 8431d1a4 00000000 00000000 8404c364
        8404cc6c 00000001 8b124c88 8b124c80 8b124c88 8b124c80 8b1c3f80 00000000
        00000000 00000000 00000000 8404cc04 8b03254c 8b03254c 84051638 00000000
        ...
Call Trace:[<8402d074>] 0x8402d074
[<8402d194>] 0x8402d194
[<84255238>] 0x84255238
[<8404c364>] 0x8404c364
[<8404cc6c>] 0x8404cc6c
[<8404cc04>] 0x8404cc04
[<84051638>] 0x84051638
[<84051b14>] 0x84051b14
[<8404cba8>] 0x8404cba8
[<84051650>] 0x84051650
[<8401504c>] 0x8401504c


Code: 3c030fff  3463ff00  00431024 <00028036> 09029cfd  24050001  27bdffc8  0085102b  afb7002c 
Kernel panic - not syncing: Fatal exception in interrupt

Eu sou capaz de obter algumas informações sobre esse problema que está fazendo isso acontecer?

    
por Sen 06.01.2011 / 14:38

1 resposta

2

Os core dumps são mais fáceis de ler se você puder associá-los a uma tabela de símbolos. Dessa forma, uma ferramenta de depuração pode traduzir endereços de mapas de memória em mnemônicos, ou seja, estruturas de dados, nomes de funções, variáveis globais e assim por diante. O rastreamento de chamadas acima, por exemplo, seria muito mais útil.

Para um dump induzido pelo pânico, a maneira usual de ler um dump central é rastrear a falha até uma causa provável. A trilha mais provável a seguir é o processo que estava sendo executado no ponto de falha. Na maioria dos kernels, com as informações apropriadas do símbolo de depuração disponíveis, você pode voltar atrás, instrução por instrução, para encontrar um valor ruim.

Eu não estou familiarizado com a apresentação desta saída, mas parece que o seu kernel recebeu uma interrupção em um estado no qual afirmou que nenhuma interrupção deveria chegar. Esse tipo de regra é uma proteção contra a computação em dados quando não parece seguro fazê-lo, então o kernel entra em pânico para se proteger contra invasões. Apenas um palpite da minha parte, no entanto.

Muitos kernels são executados com todas as informações de símbolos removidas para que fiquem o mais leves possível. Parece que você teria que compilar estes valores em seu kernel para obter uma saída de pânico mais facilmente digerível.

    
por 13.01.2011 / 17:28