Sistema Debian 6.0 com kernel 2.6.39 descartando pacotes, hardware de ponte arenosa

Question

Eu recentemente migrei um sistema Debian existente para um novo hardware, um chip i3 principal rodando em uma placa-mãe intel sandy bridge. Estou com um problema muito estranho. quando eu ping pelo meu roteador, cerca de 50% dos pacotes estão sendo descartados.

Eu passei algum tempo testando e posso verificar se não é o roteador. Funciona bem com várias máquinas diferentes, mesmo quando conectado à mesma porta Ethernet no roteador. Os pings que retornam têm latência muito baixa, menos de 1 ms, como você esperaria do roteador sentado do outro lado da sala.

Eu estou usando o kernel 2.6.39, no Debian estável (eu obtive o kernel de backports). Além do kernel e de alguns pacotes relacionados necessários para funcionar, o sistema é 100% Debian 6.0. O kernel detecta o hardware da rede e carrega o driver e1000e na inicialização. Não há nada estranho nos logs.

Uma outra coisa: apesar do problema, a rede "funciona" se você pode chamar assim. O que quero dizer é que eu também posso pingar o yahoo e google com sucesso. É claro que eu também perco ~ 50% dos pacotes nesses casos também, mas alguns pacotes estão voltando. Os outros dispositivos conectados a este roteador estão funcionando bem. Estou digitando isso em uma máquina conectada ao mesmo roteador.

Eu tenho experiência relativamente no Linux, mas não tenho certeza onde começar com esse problema. A única outra coisa que posso pensar é que o roteador é 10/100, não gigabit. Obviamente, isso não deve causar esse problema, mas talvez esteja relacionado? OTOH, tenho certeza que a última máquina também tinha gigabit Ethernet. Ele foi conectado à mesma porta no mesmo roteador.

Sim, tentei reinicializar o roteador e a máquina várias vezes.

Espero que alguém tenha uma ideia.

ATUALIZAÇÃO: @bdk faz algumas boas sugestões ... gostaria de ter boas notícias! : (

Eu tentei mais coisas e não consegui nada. Eu também peguei algumas saídas do sistema para incluir aqui.

às vezes, quando tento pingar, não consigo encontrar o host. se eu tentar de novo, ele pode se conectar. Eu suponho que este é apenas o primeiro ping (s) falhando. @bdk, as falhas parecem intermitentes, pelo menos não consigo ver um padrão.

Aqui estão as linhas relevantes do dmesg, estou faltando alguma bandeira vermelha?

[    1.171187] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
[    1.171190] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[    1.171225] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    1.171236] e1000e 0000:00:19.0: setting latency timer to 64
[    1.171339] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[    1.460976] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) e0:69:95:dd:5d:d9
[    1.460979] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[    1.461015] e1000e 0000:00:19.0: eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
[   48.475222] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[   48.530979] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[   50.120859] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[   50.120863] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO

coisas que eu tentei que não ajudaram:

instalado linux-firmware-free , linux-firmware-nonfree , caso houvesse um firmware melhor disponível (não havia, ou pelo menos o kernel não o encontrou)

jogado com aspm na BIOS, outros relataram aspm causando problemas para ethernet e1000e (não ajudou)

completamente desativado pcie_aspm no kernel, no caso que estava causando o problema (não foi, mas desativá-lo introduziu novos problemas)

mii-tool aparentemente não é suportado por este chip? Existe uma ferramenta especial para usar em vez disso?

quando dei uma olhada em tcpdump , as coisas começaram a parecer mais sombrias. não apenas alguns dos pacotes não estão retornando, mas alguns não estão nem saindo!

14:25:01.162331 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 1, length 64
14:25:02.168630 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 2, length 64
14:25:02.228192 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 2, length 64
14:25:07.236359 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 3, length 64
14:25:07.259431 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 3, length 64
14:25:31.307707 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 9, length 64
14:25:32.316628 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 10, length 64
14:25:33.324623 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 11, length 64
14:25:33.349896 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 11, length 64
14:25:43.368625 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 17, length 64
14:25:43.394590 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 17, length 64
14:26:18.518391 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 30, length 64
14:26:18.537866 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 30, length 64
14:26:19.519554 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 31, length 64
14:26:20.518588 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 32, length 64
14:26:21.518559 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 33, length 64
14:26:21.538623 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 33, length 64
14:26:37.573641 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 35, length 64
14:26:38.580648 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 36, length 64
14:26:38.602195 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 36, length 64

observe a sequência do pedido, como vai 1, 2, 3 ... 9 ??! isso não pode ser bom.

Eu sei que o Sandy Bridge ainda é relativamente novo, mas o Linux funciona ... certo?

Isso pode ser um hardware ruim? De jeito nenhum ... certo?

suspiro .... talvez eu deva voltar ao sistema antigo.

    

Answer 1

Aparentemente, esse problema já é conhecido pelo pessoal do Ubuntu. Tem que entregá-lo para eles!

Para começar: o trabalho rápido ao redor. Você pode fazer o seu sistema funcionar novamente, diminuindo a velocidade da rede para 10 mpbs da seguinte forma:

sudo ethtool -s eth0 speed 10 autoneg off

(observe que a ferramenta mii NÃO funciona com este chip ethernet)

Eu realmente não tenho uma correção confirmada ainda, mas aparentemente ninguém faz. Escolhi responder a essa pergunta porque a natureza desse problema é algo de que as pessoas precisam estar cientes.

According to the Ubuntu bug report, this is a hardware fault that randomly affects only some recent Intel ethernet chips. Not some models, but certain chips. Meaning there's no way to tell which ones are good and which aren't. At a minimum, the 82579V (my chip) and the 82579LM are affected, Ubuntu team has confirmed those. Who knows how many other models are affected.

It may be wise to avoid motherboards that use Intel ethernet chips, at least until the extent of the problem is fully understood.

Portanto, parece que este é realmente um bug de hardware, afinal. Há rumores de que você pode baixar, compilar e instalar o driver Intel mais recente, que contém uma solução permanente de software. O download é aqui , compilar e instalar são deixados como um exercício para o leitor.

Estou curioso para saber o que é essa solução alternativa de software e se ela reduz permanentemente qualquer funcionalidade ou desempenho. Deve haver alguma troca, certo? Infelizmente, eu mesmo fui incapaz de experimentar isso, já que eu precisava mandar esta placa-mãe de volta para dentro da janela de retorno.

Os relatórios de erros do Ubuntu podem ser encontrados aqui e aqui . Muito obrigado ao incrível time do Ubuntu! Eles realmente fazem grandes coisas para compatibilidade de hardware Linux.

O que mais me surpreendeu foi que eu estava aparentemente entre os primeiros a encontrar essa questão. Os relatórios de bugs do Ubuntu acima ainda estão ativos até o momento desta publicação. Não existe ninguém usando o Linux no Sandy Bridge? Eu sou a única pessoa que resta no planeta com hardware de rede 10/100? Talvez a razão mais provável seja que o problema de hardware Ethernet da Intel só recentemente se manifestou.

- Eric