[AsteriskBrasil] HP Proliant ML110 G6

Carlos Diego cdiego em gmail.com
Terça Setembro 20 20:44:38 BRT 2011


Boa Noite Luciano,

Não sei como são as opções padrões de compilação do kernel no Trixbox.
Na verdade nunca trabalhei com o Trixbox.

Mas minha recomendação é compilar um kernel mais novo, recomendo o
2.6.24, 2.6.26 ou 2.6.34.

Já tive problema parecido com os kernels antigos, em especial
anteriores ao 2.6.21.

Além disso, ao recompilar o kernel, no make menuconfigure configurar o seguinte

Processor type and Features -> Timer Frequency -> 1000Hz
Processor type and Features -> Preemption Model -> Preemptible Kernel

Um abraço e boa sorte!

-- 
Carlos Diego Russo Medeiros
iTFLEX Tecnologia - softwarelivre redes segurança
http://www.itflex.com.br - Joinville/SC - Brasil



Em 16 de setembro de 2011 10:08, Luciano Alves Barroso
<lucianodigivoice em gmail.com> escreveu:
> Bom dia AsteriskBrasil,
> gostaria de abrir uma discussão, toda ajuda é muito bem vinda.
> Recebemos uma reclamação de um cliente nosso (Henrique da Universidade de
> Caxias do Sul), ele possui varios sistemas baseados em Asterisk para Gateway
> e PBX. Em seus ambientes ele utiliza placas DigiVoice e placas de outros
> fabricantes.
> Em sua reclamação, Henrique comenta sobre os logs de "WARNING[3287]
> chan_dgv.c: EV_ERRORDETECTED card 1, data 1", aqui na lista a DigiVoice ja
> deu sua contribuição comentando sobre como é o processo de funcionamento de
> interrupções (IRQ).
> Efetuando um acesso remoto ao cliente, verificamos que a ocorrência dos logs
> acima comentados somente ocorria após +/- 36 horas de uptime do servidor,
> trata-se de um HP Proliant ML110 G6 (Linux trixbox1.localdomain
> 2.6.18-128.1.10.el5 #1 SMP Thu May 7 10:39:21 ETD 2009 i686 i686 i386
> GNU/Linux).
> Após inúmeras ocorrências deste log, efetuamos um teste básico, executamos
> um zttest no ambiente do cliente e percebemos que o driver zt_dummy estava
> registrado mas o mesmo não respondia com a temporização necessária para
> MeetMe e outras features do Asterisk. Solitamos ao cliente o reboot da
> maquina e após o reboot (antes das 36 horas) o zttest respondia com a
> temporização. Sim, após as 36 horas o mesmo parou!!!
> O cliente então removeu todos os drivers da DigiVoice, e até mesmo removeu a
> placa DigiVoice. Novamente, sim!!! o problema ocorreu identico.
> Como o cliente possuia placas da concorrência efetuamos o mesmo teste nestes
> ambientes, e novamente o problema ocorreu.
> Aqui venho solicitar a ajuda dos senhores, usuários linux, Asterisk,
> colaboradores, etc. Até então muitos na lista comentavam que esta fato
> ocorrido é problema da DigiVoice, mas olhando para todos os testes,
> verificamos que o problema ocorre no zt_dummy, dahdi_dummy, com placas
> DigiVoice e de outros participantes do mercado, com centos, openSuse,
> ubuntu, Debian e Redhat.
> Acredito que o problema esta relacionado a gerenciamento de energia, ou
> mesmo em algum driver que "perde" muito tempo para tratar algum dispositivo,
> onde o mesmo não deixa outras IRQs serem tratadas. Este fato faz com que a
> placa da DigiVoice avise através de logs que sua IRQ não esta sendo atendida
> de 2 em 2ms (pelo que vimos, a unica que gera este tipo de log), e como
> todos sabem se o zt/dahdi_test não responde, as temporizações do Asterisk
> serão prejudicadas resultando em baixa qualidade do audio e até mesmo
> picotes.
> Obs.: Tentamos contato com o fabricante HP, e a HP nos informou que somente
> sistemas homologados (versões Enterprise do Suse e RedHat) são suportados
> por eles, e desta forma eles não poderiam nos ajudar.
> Obrigado a todos.
> --
> Luciano Alves Barroso
> Equipe de Desenvolvimento DigiVoice Channel Driver & DigiVoice Meucci
> www.digivoice.com.br
> www.meucci.org


Mais detalhes sobre a lista de discussão AsteriskBrasil