Re: [FUG-BR] RES: RES: RES: Não usem FBSD-8x como router !!!
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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: RES: Não usem FBSD-8x como router !!!
Em 4 de março de 2011 12:26, Eduardo Schoedler eschoed...@viavale.com.brescreveu: Em 04/03/2011 12:13, Rodrigo Mosconi escreveu: É recomendável deixar os códigos de debug. Pretendo sim, principalmente depois do que venho passando... Nas séries mais antigas tinham umas outras flags que aumentavam consideravelmente o debug. Os NOTES devem conter-las -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: RES: Não usem FBSD-8x como router !!!
Pessoal. Não posso deixar de escrever algo sobre este assunto também. Até então não tive problemas de kernel panic em meus roteadores BGP, mas tive outros problemas nestes ambientes. Nos roteadores BGP com freebsd 7 e placas em e bge tive/tenho o seguinte problema: Se eu ativo o Full routing com os peer de saida o FreeBSD começa a ter erros de pacotes no input das placas de rede. Já tentei com kernel generic, kernel customizados, varias sysctls, com polling, sem polling mas o problema continua. Nestes mesmos roteadores se eu filtrar o full routing, ou seja, usar só rota padrão o problema desaparece. Já mandei relatos sobre este problema no ano passado para vocês. Como o upload não é o meu problema, preferi não usar full routing. Esses dias eu tava pensando em voltar a ver o problema e migrar para FreeBSD 8.2 mas fico pensativo com estes problemas que são relatados.. 2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 15:30, Klaus Schneider escreveu: Um bit pode causar um overflow. Não sou desenvolvedor, mas da pra imaginar que isso pode acontecer, principalmente se o quagga aceitar uma informação mal repassada que vai parar dentro do kernel, não fica reservado ao userland. Talvez nem seja problema com o bgpsimple, pode ser com o quagga. Acho que não é o caso, pois tirei a referência desse aplicativo da GTER MASOCH-L (não me recordo exatamente) e utilizaram por lá sem problemas. Já testou o bgpsimple com o openbgpd ou i386(citado pelo Patrik)? Ainda não, mas não tenho mais tanto tempo de sobra... esse foi um teste final. O 8.2-STABLE parou com panic depois que retirei a opção RADIX_MPATH do kernel. Acredito ser mais um bug no kernel relacionado à adição/remoção de rotas do que problema de quagga/bgpsimple./ -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- --- Matheus Cucoloto Unix Expertise Voip Expertise WiTec - Wi Telecom Fix: +55 44 36194211 Cel: +55 44 99216200 Sip: sip://1...@sipwicne1.grupoirapida.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
