[FUG-BR] RES: RES: RES: Não usem FBSD-8x como router !!!

Luiz Otavio O Souza lists.br em gmail.com
Terça Março 8 08:58:43 BRT 2011


On Mar 7, 2011, at 10:39 AM, Eduardo Schoedler wrote:
> Em 05/03/2011 11:12, Luiz Otavio O Souza escreveu:
>> Eu (IMHO) recomendo, ao menos, utilizar as opções que estão no kernel
>> GENERIC (e remover as opções não default):
>> 
>> makeoptions     DEBUG=-g    # Build kernel with gdb(1) debug symbols
>> options         KDB         # Kernel debugger related code
>> options         KDB_TRACE   # Print a stack trace for a panic
>> 
>> Já no -current, o GENERIC tem por default as seguintes opções de debug
>> (apenas para comparação):
>> <snip>
> 
> Encontrei mais alguns options no GENERIC, o que você me diz de:
> 
> options         KTRACE        # ktrace(1) support
> options         STACK         # stack(9) support
> 
> Aqui eu tirei, não houveram problemas de compilação, mas também não sei se o
> kernel irá gerar os backtraces quando der panic novamente.
> Por enquanto fiquei só com KDB e KDB_TRACE.
> 

As opções do kernel GENERIC são suficientes para gerar as informações de debug da mesma forma que você já o fez para gerar o PR (não é preciso recompilar o kernel GENERIC para debugar um problema).

O KDB é o kernel debugger e o KDB_TRACE é responsável por gerar o backtrace automaticamente, sem precisar do 'call doadump' que eu comentei em outro email.

O KTRACE é utilizado para rastrear (e logar) as chamadas (e outras operações) feitas ao kernel por qualquer programa (não é utilizado para debugar problemas do kernel).

O ktrace é interessante para você ver o que aquele programa binário (legado) esta fazendo, quais arquivos de configuração ele esta tentando ler e assim identificar falhas de configuração, arquivos que estão faltando, etc., mesmo quando não há uma mensagem de erro.

Para você ver como isso funciona:

# ktrace ls
# kdump -f ktrace.out | less

Onde 'ls' pode ser qualquer programa rodando no FreeBSD (evite programas muito grandes... a quantidade de informação retornada por esses programas é enorme).

Já a opção STACK é necessária para o debug do kernel. É ela que transforma (quando possível) a instrução problemática do kernel de volta para a função que a originou (aquela lista de funções retornadas no backtrace).

Se me lembro bem, sem ela você teria só os offsets do ponto de falha (e isso pode variar de kernel para kernel, dependendo das opções selecionadas na compilação), o que tornaria o debug remoto muito dificil, senão impossível (para cada configuração de kernel, haveria um backtrace com offsets diferentes para o mesmo problema).

[]'s
Luiz


Mais detalhes sobre a lista de discussão freebsd