이 소스를 “Wake-on-LAN을 비활성화하면 Intel I211 끊김이 해결된다”라고 요약해서는 안 됩니다. 초기 증상은 네트워크 장애처럼 보였지만, 이후 조사에서 로컬 터미널도 멈추고 시스템이 펌웨어/CPU 관련 오류를 반복적으로 출력한다는 사실이 밝혀졌습니다. 문제는 플랫폼 전체의 안정성 문제로 확대되었습니다.
가장 확실한 사용자 검증은 BIOS 수준의 변경 후에 이루어졌습니다. 소스 사용자는 Global C-State Control, ACPI Sleep/Suspend-to-RAM, SVM을 비활성화한 뒤 3일 15시간 38분 동안 안정적으로 작동했다고 보고했으며, 문제가 해결된 것으로 보인다고 표시했습니다. 설정을 하나씩 다시 활성화할 계획이었으므로, 이 스레드에서는 어떤 개별 설정이 원인이었는지 끝내 특정하지 못했습니다.
처음에는 Intel I211 네트워크 끊김처럼 보였던 증상
ZimaOS 1.5.3은 몇 시간마다 연결이 끊겼고 재시작이 필요했습니다. 동일한 시스템은 Windows Server에서 안정적으로 작동했으며, 같은 네트워크에 연결된 더 최신의 다른 ZimaOS 시스템은 안정적이었습니다.
NIC Wake-on-LAN 비활성화는 커뮤니티에서 초기에 진행한 테스트였습니다
커뮤니티에서 사용한 문제 해결 방법 ethtool WOL을 비활성화하고 이중 고정 IP 구성을 피하라고 제안했습니다. 이는 합리적인 테스트였지만, 이후 시스템이 다시 잠겼습니다.
따라서 WOL을 최종 원인 해결책으로 확정해 제시할 수는 없습니다.
메인보드 BIOS 업데이트로 가동 시간은 늘었지만 완전히 해결되지는 않음
사용자는 BIOS 업데이트 후 가동 시간이 약 3시간에서 10시간 이상으로 늘었다고 말했습니다. 그러나 이후 문제가 다시 발생했으므로, 개선과 최종 해결은 서로 다른 단계였습니다.
결국 로컬 터미널까지 멈춘 장애
문제가 재발했을 때 로컬로 연결된 터미널에서도 명령을 입력할 수 없었습니다. 콘솔에는 약 15초마다 오류가 반복해서 표시되었습니다. 이에 따라 진단 방향은 단순한 이더넷 구성 문제에서 벗어났습니다.
펌웨어/ACPI 전원 상태 오류의 관련성이 더 커짐
로그에는 ACPI MWAIT C-state 펌웨어 경고가 반복해서 기록되었습니다. 사용자는 BIOS 업데이트로 ACPI 절전 동작이 변경된 사실도 발견했습니다. 이후 안정성 테스트를 위해 여러 전원 관리 및 가상화 기능을 비활성화했습니다.
원문 시스템은 세 가지 BIOS 변경 후 안정화되었습니다
- 전역 C-State 제어: 비활성화
- ACPI 절전 / RAM 일시 중단: 비활성화
- SVM: 비활성화
이후 사용자는 3일 넘게 안정적으로 가동되었다고 보고했습니다.
이 설정을 모든 시스템에 보편적으로 적용하지 마세요. SVM을 비활성화하면 AMD 하드웨어 가상화도 비활성화되어 ZVM 또는 다른 VM이 작동하지 않을 수 있습니다.
원문에는 지원되지 않는 NVIDIA GT 710 드라이버 브랜치도 있었습니다
로그에 따르면 설치된 NVIDIA 580 드라이버가 GT 710을 무시한 이유는 해당 GPU가 레거시 470.xx 브랜치에 속하기 때문이었습니다. 이는 실제 호환성 문제였지만, 해당 스레드만으로 이것이 멈춤 현상의 원인이라고 입증되지는 않았습니다.
타사 x86 호환성에는 드라이버뿐 아니라 펌웨어도 포함됩니다
현재 ZimaOS는 일반적인 x86-64를 지원하지만, IceWhale은 모든 마더보드, 컨트롤러, 그래픽 장치 또는 네트워크 인터페이스가 검증된 것은 아니라고 명시적으로 경고합니다.
관련 없는 플랫폼에 AB350 전용 BIOS 설정을 적용하기 전에 현재의 타사 하드웨어 문제 해결 프레임워크를 사용하세요.
현재 진단을 더 안전하게 수행하기
- 장애 발생 후 이전 부팅 및 커널 로그를 수집하세요.
- 네트워킹만 실패했는지, 아니면 호스트 전체가 멈췄는지 확인하세요.
- 마더보드 제조업체의 CPU 지원 범위 내에서 펌웨어를 업데이트하세요.
- 가능하면 BIOS 전원 상태를 한 번에 하나씩 변경하여 테스트하세요.
- 시스템이 해당 장치 없이 부팅할 수 있다면 호환되지 않는 확장 장치를 제거하거나 비활성화하세요.
- 기본 안정성이 확보된 후에만 가상화를 다시 테스트하세요.
로컬 콘솔 멈춤으로 진단이 달라졌습니다
문제가 처음 Intel I211 링크 끊김처럼 보였을 때는 NIC 절전 및 Wake-on-LAN을 테스트하는 것이 합리적이었습니다. 하지만 로컬 터미널도 응답을 멈추자 단순한 이더넷 드라이버 문제라는 설명의 설득력은 크게 떨어졌습니다.
이는 일반적인 진단 원칙입니다. 장애가 서로 독립적인 하위 시스템에 걸쳐 발생하면 장애 범위를 넓혀야 합니다.
최종 세 가지 BIOS 변경 사항이 함께 적용되었습니다
사용자는 Global C-State Control, ACPI Sleep/Suspend-to-RAM 및 SVM을 비활성화한 후 며칠간 안정적으로 사용했다고 보고했습니다. 여러 변수가 동시에 변경되었으므로, 이 소스만으로는 어떤 단일 설정이 시스템을 안정화했는지 확인할 수 없습니다.
SVM은 AMD 가상화 지원 기능입니다. SVM을 비활성화하면 VM 워크로드가 작동하지 않을 수 있으므로, 이 사례에서 성공한 테스트의 일부였다는 이유만으로 모든 경우에 권장해서는 안 됩니다.
BIOS 업데이트는 최종 해결책은 아니었지만 유용한 증거였습니다
마더보드 펌웨어를 업데이트하자 안정적인 기간이 약 3시간에서 10시간 이상으로 늘어났습니다. 이는 펌웨어 및 전원 관리 동작이 영향을 미쳤음을 시사하지만, 이후 문제가 다시 발생했으므로 업데이트만으로는 충분하지 않았습니다.
GT 710 드라이버 불일치는 실제였지만 멈춤의 원인이라는 사실은 입증되지 않았습니다
로그에 따르면 설치된 NVIDIA 580 브랜치는 이전 드라이버 브랜치에 속하는 구형 GT 710을 지원하지 않았습니다. 이로 인해 GPU 기능이 작동하지 않고 오류가 발생할 수 있지만, 소스에서는 GPU 드라이버만 제거하거나 수정하면 네트워크 또는 호스트 멈춤 문제가 해결된다는 점을 입증하지 않았습니다.
현재 서드파티 하드웨어 진단은 펌웨어 기본값에서 시작해야 합니다
구형 AM4 보드에서는 BIOS를 업데이트하고, 원래 설정을 기록하며, 공격적인 절전 기능은 통제된 테스트로만 비활성화하고, 이전 부팅 로그를 수집하세요. 기능을 영구적으로 비활성화하기 전에 이더넷 및 가상화 요구 사항을 고려하세요.
안정화된 후 최소한의 해결 방법을 확인해야 한다면, 변경한 기능을 한 번에 하나씩 다시 활성화하세요.
소스에서 확인된 며칠간의 가동 시간은 강력한 사용자 검증이지 제품 인증이 아닙니다
이전 충돌 없이 3일 15시간을 가동한 것은 펌웨어 변경으로 해당 시스템이 개선되었다는 의미 있는 증거입니다. 그러나 이것이 모든 AB350/I211 플랫폼을 인증하거나 ZimaOS가 해당 칩셋과 일반적으로 호환되지 않는다는 사실을 입증하는 것은 아닙니다.
네트워크 끊김 FAQ
최종적인 원인이 순전히 Intel I211 NIC이었나요?
아니요. 로컬 시스템도 멈췄으므로, 더 광범위한 플랫폼 안정성 문제였습니다.
WOL만 비활성화해서 문제가 해결되었나요?
아니요. 이후 문제가 다시 발생했습니다.
최종적으로 안정적인 기간과 일치한 변경 사항은 무엇이었나요?
사용자는 Global C-States, ACPI suspend-to-RAM 및 SVM을 비활성화한 후 3일 넘게 가동되었다고 보고했습니다.
