Tego źródła nie należy podsumowywać jako „wyłącz funkcję Wake-on-LAN, aby naprawić zrywanie połączenia Intel I211”. Początkowy objaw przypominał awarię sieci, ale późniejsze dochodzenie wykazało, że zawieszał się również lokalny terminal, a system wielokrotnie zgłaszał błędy związane z oprogramowaniem układowym/procesorem. Problem stał się problemem ze stabilnością całej platformy.
Najmocniejsze potwierdzenie ze strony użytkownika pojawiło się po zmianach na poziomie BIOS-u. Użytkownik wyłączył Global C-State Control, ACPI Sleep/Suspend-to-RAM oraz SVM, a następnie zgłosił 3 dni, 15 godzin i 38 minut stabilnego czasu nieprzerwanej pracy oraz oznaczył problem jako pozornie rozwiązany. Planował ponownie włączać te zmiany pojedynczo, dlatego wątek nigdy nie ustalił, które konkretne ustawienie było odpowiedzialne za problem.
Początkowy objaw przypominał awarię połączenia sieciowego Intel I211
ZimaOS 1.5.3 tracił łączność co kilka godzin i wymagał ponownego uruchomienia. Ten sam komputer działał stabilnie pod kontrolą systemu Windows Server, podczas gdy inny, nowszy system ZimaOS w tej samej sieci działał stabilnie.
Wyłączenie funkcji Wake-on-LAN karty sieciowej było jednym z pierwszych testów społeczności
Wykorzystano rozwiązania problemów zaproponowane przez społeczność ethtool wyłączyć WOL i zasugerowano unikanie konfiguracji z dwoma statycznymi adresami IP. Były to rozsądne testy, ale komputer później ponownie się zawiesił.
Dlatego WOL nie można przedstawiać jako potwierdzonego ostatecznego rozwiązania.
Aktualizacja BIOS-u płyty głównej poprawiła czas nieprzerwanej pracy, ale nie rozwiązała problemu całkowicie
Użytkownik powiedział, że aktualizacja BIOS-u wydłużyła czas nieprzerwanej pracy z około trzech do ponad dziesięciu godzin. Problem później powrócił, co pokazuje, że poprawa i ostateczne rozwiązanie były odrębnymi etapami.
Awaria ostatecznie zawiesiła również lokalny terminal
Gdy problem powrócił, lokalnie podłączony terminal nie przyjmował poleceń. Konsola powtarzała błędy co około 15 sekund. Przesunęło to diagnozę z dala od problemu dotyczącego wyłącznie konfiguracji Ethernetu.
Błędy stanów zasilania oprogramowania układowego/ACPI stały się istotniejsze
Dzienniki zawierały powtarzające się ostrzeżenia o oprogramowaniu układowym ACPI dotyczącym stanów C MWAIT. Użytkownik odkrył również, że aktualizacja BIOS-u zmieniła sposób działania uśpienia ACPI. Następnie wyłączył kilka funkcji zarządzania energią i wirtualizacji w celu przeprowadzenia testów stabilności.
Źródło ustabilizowało się po wprowadzeniu trzech zmian w BIOS-ie
- Global C-State Control: wyłączone
- ACPI Sleep / Suspend to RAM: wyłączone
- SVM: wyłączone
Później użytkownik zgłosił ponad trzy dni stabilnej pracy.
Nie kopiuj tych ustawień bezkrytycznie. Wyłączenie SVM wyłącza również sprzętową wirtualizację AMD i może uniemożliwić działanie ZVM lub innych maszyn wirtualnych.
W źródle znajdowała się również nieobsługiwana gałąź sterownika NVIDIA GT 710
Logi wskazywały, że zainstalowany sterownik NVIDIA 580 ignorował GT 710, ponieważ ta karta graficzna należała do starszej gałęzi 470.xx. Był to rzeczywisty problem ze zgodnością, ale wątek nie dowodził, że powodował zawieszanie się systemu.
Zgodność z zewnętrznym sprzętem x86 obejmuje oprogramowanie układowe, nie tylko sterowniki
Obecna wersja ZimaOS obsługuje ogólną platformę x86-64, ale IceWhale wyraźnie ostrzega, że nie każda płyta główna, kontroler, karta graficzna ani karta sieciowa została zweryfikowana.
Przed zastosowaniem ustawień BIOS-u właściwych dla AB350 na innych platformach skorzystaj z aktualnych ram diagnostyki sprzętu innych producentów.
Bezpieczniejsza obecna diagnoza
- Po awarii zarejestruj logi z poprzedniego uruchomienia i logi jądra.
- Ustal, czy przestała działać tylko sieć, czy zawiesił się cały host.
- Aktualizuj oprogramowanie układowe w granicach obsługi procesora określonych przez producenta płyty głównej.
- W miarę możliwości testuj pojedynczo każdą zmianę dotyczącą stanów zasilania BIOS-u.
- Usuń lub wyłącz niezgodne urządzenia rozszerzeń, jeśli system może uruchomić się bez nich.
- Ponownie przetestuj wirtualizację dopiero po ustabilizowaniu podstawowej konfiguracji.
Zawieszenie lokalnej konsoli zmieniło diagnozę
Gdy problem początkowo wyglądał na zrywanie połączenia z kartą Intel I211, wyłączenie oszczędzania energii karty sieciowej i funkcji Wake-on-LAN było rozsądnym testem. Gdy przestał odpowiadać również lokalny terminal, wyjaśnienie ograniczające się wyłącznie do sterownika Ethernetu stało się znacznie mniej przekonujące.
To ogólna zasada diagnostyczna: gdy awarie obejmują niezależne podsystemy, należy poszerzyć zakres poszukiwania usterki.
Trzy ostatnie zmiany w BIOS-ie zastosowano jednocześnie
Użytkownik wyłączył Global C-State Control, ACPI Sleep/Suspend-to-RAM oraz SVM, a następnie zgłosił wielodniową stabilność. Ponieważ zmieniono kilka zmiennych jednocześnie, źródło nie pozwala ustalić, które pojedyncze ustawienie naprawiło komputer.
SVM to obsługa wirtualizacji AMD. Jej wyłączenie może uniemożliwić działanie maszyn wirtualnych, dlatego nie należy zalecać tego rozwiązania powszechnie tylko dlatego, że było częścią udanego testu opisanego w źródle.
Aktualizacja BIOS-u dostarczyła cennych dowodów, choć nie była ostatecznym rozwiązaniem
Aktualizacja oprogramowania układowego płyty głównej wydłużyła stabilny okres z około trzech godzin do ponad dziesięciu godzin. Sugeruje to, że zachowanie oprogramowania układowego lub zarządzania energią miało znaczenie, ale późniejszy nawrót problemu pokazuje, że sama aktualizacja nie wystarczyła.
Niezgodność sterownika GT 710 była rzeczywista, ale nie udowodniono, że powodowała zawieszanie się systemu
Z dzienników wynikało, że zainstalowana gałąź NVIDIA 580 nie obsługiwała starszej karty GT 710, która należy do wcześniejszej gałęzi sterowników. Może to zakłócać działanie GPU i powodować błędy, ale źródło nie wykazało, że samo usunięcie lub skorygowanie sterownika GPU naprawiło zawieszanie się sieci/systemu hosta.
Diagnozowanie bieżącego sprzętu innej firmy należy rozpocząć od ustawień domyślnych oprogramowania układowego
W przypadku starszej płyty AM4 zaktualizuj BIOS, zapisz pierwotne ustawienia, wyłącz agresywne funkcje uśpienia wyłącznie jako kontrolowany test i zbierz dzienniki z poprzedniego uruchomienia. Przed trwałym wyłączeniem funkcji uwzględnij wymagania dotyczące Ethernetu i wirtualizacji.
Po ustabilizowaniu systemu włączaj ponownie po jednej zmienionej funkcji naraz, jeśli chcesz ustalić minimalne obejście problemu.
Wielodniowy czas pracy zgłoszony przez źródło to mocne potwierdzenie użytkownika, a nie certyfikacja produktu
Trzy dni i piętnaście godzin bez wcześniejszej awarii to istotny dowód na to, że zmiany oprogramowania układowego poprawiły działanie tego komputera. Nie potwierdza to jednak poprawności działania każdej platformy AB350/I211 ani nie dowodzi ogólnej niezgodności ZimaOS z tym chipsetem.
FAQ dotyczące zaników sieci
Czy ostatecznym źródłem problemu była wyłącznie karta sieciowa Intel I211?
Nie. Zawiesił się również system lokalny, co wskazuje na szerszy problem ze stabilnością platformy.
Czy samo wyłączenie WOL rozwiązało problem?
Nie. Później awaria powróciła.
Która zmiana zbiegła się z końcowym okresem stabilności?
Użytkownik wyłączył Global C-States, ACPI suspend-to-RAM i SVM, a następnie zgłosił ponad trzy dni nieprzerwanej pracy.
