Kernel panic - por onde começar?

[fabinader]

Caros,

  Não sou um heavy-user Linux, portanto me perdorem se me referencio aos termos de forma incorreta.
  Sou um estudante de Mestrado, na área de Redes, e meu tema está relacionado a compressão de cabeçalhos IP para aplicações VoIP. O algoritmo comprime os cabeçalhos IP/UDP/RTP de todos os pacotes VoIP que trafegam entre nós de rede, e caso haja uma perda de pacote, ele "detecta" a perda e ignora todos os os demais pacotes comprimidos até que um pacote descomprimido seja enviado (coisa que é feita a cada 100 pacotes comprimidos). Num cenário ideal, sem perda de pacotes, a cada 100 pacotes enviados, 99 serão comprimidos. Num cenário real de redes sem fio, com perda de pacotes ocasionais, isso significa que alguns pacotes serão descartados até que um novo pacote descomprimido seja enviado.
  Para testar meu algoritmo, necessito "emular" uma rede sem fio, e para tanto, utilizo uma ferramenta chamada NS-2 para simulação de cenários de redes. Para alimentar o tráfego de pacotes nessa ferramenta, eu utilizo aplicações VoIP executando em terminais UML (User-Mode Linux). Abaixo segue uma figura demonstrando o "setup" deste ambiente:
[/url]
  O ambiente acima funciona perfeitamente por minutos a fio. Consigo "levantar" até 8 terminais UML sem queda perceptível de performance, e todos "colaboram" contibuindo com seu tráfego IP para a emulação de redes no NS-2. O problema começa quando eu incluo meu algoritmo de compressão no NS-2, e num caso bem particular.  Se eu incluo meu algoritmo de compressão num cenário com probabilidade de perda de pacotes igual a zero (mundo ideal), tudo funciona perfeitamente; o tráfego é comprimido, e as medições de ganho de largura de banda detectadas pelo "trace" do NS-2 batem com os resultados esperados. Porém, caso eu rode um cenário com compressão de cabeçalhos e com probabilidade de perda de pacote maior que zero (mundo real), logo após o primeiro evento de perda de pacote minha máquina acusa um KERNEL PANIC, e simplesmente trava.
  Vale ressaltar que se eu rodar o mesmo cenário com perda de pacotes mas sem meu algoritmo de compressão o mesmo erro não acontece, o que indica a mim que meu algoritmo colabora de certa forma para o acontecimento do KERNEL PANIC. Antes de mais nada, gostaria de informar que eu testei meu algoritmo fora do NS-2, usando tráfego capturado via tcpdump, e que utilizei o Valgrind para que eu possa afirmar que ele não causa memory leaks ou coisa do tipo.
  Vale ressaltar que aquele dump que o kernel panic dá só aparece quando eu alterno para um console (usando Ctl+Alt+F1) e executo a simulação do NS-2 de lá, pois se eu rodo de dentro de um terminal no Gnome ele não aparece. Já tentei redirecionar a saída do console para um arquivo, mas o dump do kernel panic não é gravado lá. Como a máquina trava após o kernel panic, e ele é jogado muito rápido no console, e este mesmo console tem um tamanho de tela limitado no Ubuntu, as linhas iniciais do dump que indicam o local do kernel panic são "roladas" antes que eu tenha a chance de lê-las, o que me impede de determinar o que pode estar causando o kernel panic.
  Estou usando Ubuntu 5.10, com um kernel 2.6.12 "vanilla", modificado apenas para aceitar pacotes Ethernet maiores que o convencional (e.g. 2312). Atualmente eu estou perdido, pois não tenho como debugar e tentar encontrar o causador do KERNEL PANIC porque eu teria de debugar três aplicações (o simulador NS-2 e as duas aplicações VoIP nos terminais UML) que são extremamente depenentes de timing. Minha idéia era utilizar algum debugador pro meu kernel e tentar identificar o motivo do kernel panic, para então pensar em alguma maneira de resolver isto. QUalquer ajuda em qualquer sentido será muito bem vinda!
[]'s
Fuad Abinader[/url]