나는 최근에 기존 데비안 시스템을 Intel sandybridge 마더보드에서 실행되는 코어 i3 칩인 새 하드웨어로 마이그레이션했습니다. 매우 이상한 문제에 봉착했습니다. 라우터에 ping을 실행하면 패킷의 약 50%가 삭제됩니다.
테스트하는 데 시간을 보냈고 라우터가 아닌지 확인할 수 있습니다. 라우터의 동일한 이더넷 포트에 연결된 경우에도 여러 다른 컴퓨터에서 제대로 작동합니다. 반환된 핑 대기 시간은 방 반대편에 있는 라우터에서 예상할 수 있듯이 1밀리초 미만으로 매우 낮았습니다.
저는 Debian stable에서 커널 2.6.39를 사용하고 있습니다(백포트에서 커널을 얻었습니다). 시스템은 실행에 필요한 커널 및 일부 관련 패키지를 제외하고 100% Debian 6.0입니다. 커널은 네트워크 하드웨어를 감지하고 부팅 시 e1000e 드라이버를 로드합니다. 로그에는 이상한 점이 없습니다.
또 다른 점은 문제에도 불구하고 네트워크가 "작동"한다는 것입니다(그렇게 부를 수 있는 경우). 내 말은 야후와 구글에도 성공적으로 핑을 보낼 수 있다는 뜻이다. 물론 이 경우에는 패킷의 약 50%를 잃었지만 일부는예돌아왔다. 이 라우터에 연결된 다른 장치는 정상적으로 작동합니다. 저는 같은 라우터에 연결된 컴퓨터에서 이 글을 쓰고 있습니다.
저는 상대적으로 Linux에 대한 경험이 많지만 이 문제를 어디서부터 시작해야 할지 모르겠습니다. 제가 생각하는 유일한 것은 라우터가 기가비트가 아닌 10/100이라는 것입니다. 분명히 이것이 문제를 일으키지는 않지만 관련이 있을 수도 있습니다. OTOH, 나는 마지막 머신에도 기가비트 이더넷이 있었을 것이라고 확신합니다. 동일한 라우터의 동일한 포트에 연결되어 있습니다.
예, 라우터와 컴퓨터를 여러 번 다시 시작해 보았습니다.
여기 누군가가 아이디어를 갖고 있기를 바랍니다.
업데이트: @bdk가 좋은 제안을 했습니다...좋은 소식이 있기를 바랍니다! :(
더 많은 것을 시도했지만 아무것도 얻지 못했습니다. 또한 여기에 포함하기 위해 시스템에서 일부 출력을 가져왔습니다.
때로는 ping을 시도할 때 호스트를 전혀 찾지 못하는 경우가 있습니다. 다시 시도하면 연결될 수 있습니다. 내 생각엔 이것이 첫 번째 ping 실패인 것 같습니다. @bdk, 실패가 간헐적으로 발생하는 것 같습니다. 적어도 어떤 패턴도 볼 수 없습니다.
이것은 dmesg의 관련 줄입니다. 일부 위험 신호가 누락되었습니까?
[ 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
시도했지만 도움이 되지 않은 사항:
더 나은 펌웨어를 사용할 수 있는 경우 Install 을 사용합니다 linux-firmware-free( linux-firmware-nonfree사용할 수 없거나 적어도 커널이 찾지 못하는 경우).
BIOS에서 aspm을 사용하면 aspm이 e1000e 이더넷에 문제를 일으킨다고 보고한 사람들도 있습니다(도움이 되지 않음).
문제가 발생할 경우 커널에서 완전히 비활성화합니다. pcie_aspm(그렇지 않지만 비활성화하면 새로운 문제가 발생합니다.)
mii-tool이 칩이 지원하지 않는 것 같나요? 대신 사용할 수 있는 특별한 Intel 도구가 있습니까?
내가 살펴보니 tcpdump상황이 훨씬 더 암울해 보이기 시작했습니다. 일부 패킷은 성공적으로 반환되지 않을 뿐만 아니라 일부 패킷은 성공하지도 못합니다.나가!
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
요청 순서(1, 2, 3...9)에 주의하세요. ! 그 좋지 않다.
Sandy Bridge는 아직 상대적으로 새로운 제품이지만 Linux는 작동합니다...그렇죠?
하드웨어 불량일 수 있나요? 있을 수 없는 일이죠...그렇죠?
한숨을 쉬다....어쩌면 이전 시스템으로 돌아가야 할 수도 있습니다.
답변1
분명히 이 문제는 Ubuntu 사용자들에게 이미 알려져 있습니다. 그들에게 줘야 해!
우선, 문제를 신속하게 해결하세요. 다음과 같이 이더넷 속도를 10mpbs로 낮추면 시스템을 다시 실행할 수 있습니다.
sudo ethtool -s eth0 speed 10 autoneg off
(mii-tool은 이 이더넷 칩에서 작동하지 않습니다.)
실제로 아직 확정된 수정 사항을 얻지는 못했지만 분명히 아무도 확인하지 못했습니다. 제가 이 질문에 대답하기로 한 이유는 질문의 본질이 사람들이 알아야 할 것이기 때문입니다.
Ubuntu 버그 보고서에 따르면 이는 무작위 효과가 있는 하드웨어 결함입니다.일부만최신 인텔 이더넷 칩. 특정 모델이 아니라 특정 칩입니다. 즉, 어느 것이 좋고 어느 것이 나쁜지 알 수 있는 방법이 없습니다. Ubuntu 팀은 최소 82579V(내 칩) 및 82579LM이 영향을 받는 것을 확인했습니다. 얼마나 많은 다른 모델이 영향을 받는지 누가 알겠습니까?
적어도 문제의 정도가 완전히 이해될 때까지는 Intel 이더넷 칩을 사용하는 마더보드를 피하는 것이 현명할 수 있습니다.
결국 이것은 하드웨어 오류인 것 같습니다. 영구적인 소프트웨어 해결 방법이 포함된 최신 Intel 드라이버를 다운로드, 컴파일 및 설치할 수 있다는 소문이 있습니다. 다운로드된 항목은 다음과 같습니다.여기, 편집 및 설치는 독자의 연습 문제로 남겨집니다.
이 소프트웨어의 해결 방법이 무엇인지, 기능이나 성능이 영구적으로 저하되는지 궁금합니다. 약간의 절충안이 있어야 합니다. 그렇죠? 안타깝게도 반품 기간 내에 이 마더보드를 반품해야 하기 때문에 직접 시도해 볼 수는 없습니다.
우분투 버그 보고서 발견여기그리고여기. 훌륭한 Ubuntu 팀에게 많은 감사를 드립니다! 그들은 실제로 Linux 하드웨어 호환성을 위해 많은 훌륭한 일을 하고 있습니다.
나를 가장 놀라게 한 것은 분명히 내가 이 문제를 처음 접한 사람 중 한 명이라는 사실이었습니다. 이 글을 쓰는 시점에서 위의 Ubuntu 버그 보고서는 여전히 유효합니다. 예아무도Sandy Bridge에서 Linux를 사용하시나요? 나는 지구상에서 10/100 네트워크 하드웨어를 가진 유일한 사람입니까? 아마도 가장 가능성이 높은 원인은 최근에야 밝혀진 Intel 이더넷 하드웨어 문제일 것입니다.
——에릭