On Mar 15, 2011, at 9:24 AM, kmkz bleh wrote: >> >>> gw# vmstat -i >>> interrupt total rate >>> irq28: ciss0 73109 67 >>> irq1: atkbd0 10 0 >>> irq17: atapci0+ 242 0 >>> irq22: uhci0 2 0 >>> cpu0: timer 2152906 1998 >>> irq256: em0 2386318 2215 >>> irq257: em0 21311 19 >>> irq258: em0 2 0 >>> irq259: em1 665 0 >>> irq260: bce0 11311742 10503 >> >> O rate de interrupcoes nessa placa esta bem alto, experimenta ligar o >> polling nessa interface e faça alguns testes de como ela se comporta. >> > > Exatamente. Está muito alto mesmo. Acho que já usei polling a uns tempos > atrás mas parece que a situação piorou... comecei a ter mais perda de > pacote. Não digo com certeza porque já faz algum tempo, mas vou ver se ativo > polling denovo pra ver. > > A propósito, bce suporta polling? >
É... a bce não suporta polling... porém há uma luz no fim do tunel.. parece que tem um firmware novo disponível para ela. A má noticia é que isso só esta disponível no -current, mas você pode copiar os drivers na mão para o 8-stable (ou 8-release tanto faz..): cp /current/src/sys/dev/bce/* /stable/src/sys/dev/bce (isso vai acontecer naturalmente como parte do processo de desenvolvimento - mas não tem dia para acontecer). Uma outra coisa que importante para redes gigabit é _NUNCA_ (repito NUNCA) force a velocidade nessas portas. As interfaces gigabit PRECISAM da auto-negociação ativa para o correto funcionamento. O formato dessas interfaces é diferente das antigas 10/100 que geralmente funcionavam melhor com velocidades fixas. Na portas gigabit há necessidade que uma ponta seja nomeada como MASTER e a outra ponta SLAVE e nem todos drivers suportam essas configurações feitas manualmente. Se sua conexão gigabit não funciona em 'autoselect' você tem algum 'outro' problema ai (cabos, a própria interface de rede, switches, etc.). Voltando a bce, aqui esta uma lista das ultimas correções nesse driver: ------------------------------------------------------------------------ r218529 | davidch | 2011-02-10 22:41:49 -0200 (Thu, 10 Feb 2011) | 4 lines - Updated firmware which improves small packet performance. MFC after: 2 weeks ------------------------------------------------------------------------ r218527 | davidch | 2011-02-10 20:36:23 -0200 (Thu, 10 Feb 2011) | 6 lines - Added error checking to nvram read functions. - Minor style updates. Submitted by: gcoo...@freebsd.org MFC after: 2 weeks ------------------------------------------------------------------------ r218423 | davidch | 2011-02-07 21:00:24 -0200 (Mon, 07 Feb 2011) | 12 lines - Added systcls for header splitting, RX/TX buffer count, interrupt coalescing, strict RX MTU, verbose output, and shared memory debug. - Added additional debug counters (VLAN tags and split header frames). - Updated debug counters to 64 bit definitions. - Updated l2fhdr bit definitions. - Combined RX buffer sizing into a single function. - Added buffer size and interrupt coalescing settings to adapter info printout. Submitted by: davidch MFC after: 2 weeks [snip] > >> >> >>> irq261: bce1 59430 55 >>> irq262: em2 1954193 1814 >>> irq263: em2 2460842 2284 >>> irq264: em2 1 0 >>> irq265: em3 6807389 6320 >>> irq266: em3 6870682 6379 >>> irq267: em3 14 0 >> >> Aqui também pode compensar... >> >>> irq268: bge0 1936273 1797 >>> irq269: bge1 1504853 1397 >>> cpu2: timer 2144394 1991 >>> cpu3: timer 2144549 1991 >>> cpu1: timer 2144367 1991 >>> Total 43973294 40829 >>> Outra coisa, vi que meu servidor deu PANIC com a msg abaixo: >>> >>> reboot after panic: kmem_malloc(4096): kmem_map too small: 335544320 >> total >>> allocated >>> >>> Com 4GB de RAM, o que eu devo fazer pra resolver esse problema? Qual >> valor >>> devo colocar no KVA_PAGES pra compilar o kernel, seria 1024? Meu kernel >> ta >>> compilado com a opção PAE. >> >> >> >> Só uma pergunta... você esta utilizando ZFS nesse servidor ? (esse erro >> "kmem_map too small" é muito comum nessa situação, embora eu não acredite >> que você esteja utilizando ZFS em um router...) >> >> Não faz isso não... O PAE não faz o que você pensa que ele faz... por favor >> remova ele... é melhor você não aproveitar toda a memória em i386 do que >> utilizar o PAE (geralmente). Fiquei com o i386 - sem PAE - ou vá para o >> amd64 de vez. >> >> No amd64 você não terá problemas (ou no máximo, como se faz com o ZFS, será >> preciso limitar o valor máximo para o kernel). >> > > Não, não estou usando ZFS não. > > Eu vi mesmo que o pessoal que teve esse problema utilizava ZFS. Não é o meu > caso. Vi também que tem uma sysctl pra aumentar via loader.conf, mas que pra > utiliza-la precisa setar o KVA_PAGES no kernel. > > O problema é que mesmo sem o PAE ocorre o panic, pelo menos no FreeBSD 8.2 > aconteceu... > Ok... Tente adicionar isso ai: # cat /boot/loader.conf vm.kmem_size="6G" Mas ajustando o tamanho máximo para o seu ambiente (um pouco menos que a memória disponível - esse exemplo é de um servidor com 8G de RAM, ZFS e amd64). No caso do sistema de 32bits você pode limitar esse valor um pouco abaixo dos 2GB (limite de memória do kernel). Att., Luiz ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
