Users Guide
Desconexão do cabo de rede com o ethtool -p em execução
Nas versões de kernel 2.6.32 e mais recentes, a desconexão do cabo de rede com o ethtool -p em execução fará com
que o sistema pare de responder aos comandos do teclado, exceto para control-alt-delete. Reiniciar o sistema será a
única solução.
Erros de alocação de página de RX
Podem ocorrer erros order: 0 de falha na alocação da página sob stress com os kernels 2.6.25 e superior. Isso é
causado pela maneira como o kernel do Linux relata esta condição de stress.
Desabilitar a GRO durante o roteamento/ponte
Por causa de um problema do kernel detectado, a GRO deve ser desativada durante o roteamento/ponte. A GRO pode
ser desativada através da ethtool.
ethtool -K ethX gro off
onde ethX é a interface Ethernet que você está tentando modificar.
Desempenho abaixo do esperado
Alguns slots PCI-E x8 são efetivamente configurados como slots x4. Esses slots dispõem de largura de banda
insuficiente para a velocidade total da linha 10GbE com dispositivos de portas duplas e quádruplas 10GbE. Além
disso, se você colocar um adaptador PCIe de terceira geração no slot de uma PCIe de segunda geração, não será
possível obter a largura de banda total. O driver pode detectar essa situação e gravará a seguinte mensagem no
registro do sistema : "A largura de banda de PCI Express disponível para esta placa não é suficiente para garantir um
desempenho perfeito. Para obter o desempenho perfeito, é necessário um slot x8 PCI-Express.”
Se esse erro ocorrer, mover o adaptador para um slot realmente x8 solucionará o problema.
O ethtool poderá exibir incorretamente o módulo de fibra SFP+ como cabo conectado diretamente
Devido a limitações do kernel, o tipo de porta só pode ser exibido corretamente no kernel 2.6.33 ou superior.
A execução do comando ethtool -t ethX ocasiona uma parada entre o PF e o Cliente de Teste
Quando existirem VFs ativos, "ethtool -t" só executará o teste de link. O driver também registrará no syslog que os VFs
devem ser desligados para executar um teste de diagnóstico completo.
Habilitar o SR-IOV em um SO convidado de 32 ou 64 bits Microsoft* Windows* Server 2008/R2 baseada
em KVM Linux
O KVM Hypervisor/VMM suporta atribuição direta de um dispositivo PCIe a uma VM. Isso inclui dispositivos PCIe
tradicionais, bem como dispositivos compatíveis com SR-IOV que utilizam controladores Intel baseados em X540 e
82599.
Apesar do bom funcionamento da uma VM baseada em Linux, executando um kernel 2.6.32 ou superior, à qual tenha
sido atribuída diretamente um dispositivo PCIe ou de uma Função Virtual (Virtual Function - VF) SR-IOV, há um
problema conhecido com a VM do Microsoft Windows Server 2008/R2 que resulta em um erro do tipo "yellow bang"
(ponto de exclamação amarelo). Esse é um problema do KVM VMM em si, e não do driver Intel ou da lógica SR-IOV
da VMM, mas aquele KVM emula um modelo de CPU mais antigo para os convidados, e este modelo de CPU mais
antigo não suporta interrupções no MSI-X, o que é requisito para o Intel SR-IOV.
Se você quiser usar controladores Intel baseados em X540 ou 82599 no modo SR-IOV com o KVM e um convidado
Microsoft Windows Server 2008/R2, experimente a solução alternativa a seguir. A solução alternativa é usar um
comando para o KVM emular um modelo diferente de CPU quando usar qemu para criar o convidado KVM:
"-cpu qemu64,model=13"