Den här källan bör inte sammanfattas som ”inaktivera Wake-on-LAN för att åtgärda bortfall på Intel I211”. Det ursprungliga symtomet såg ut som ett nätverksfel, men undersökningen visade senare att även den lokala terminalen låste sig och att systemet upprepade gånger genererade firmware- och processorrelaterade fel. Problemet hade blivit ett stabilitetsproblem för hela plattformen.
Den starkaste verifieringen från användaren kom efter ändringar på BIOS-nivå. Källanvändaren inaktiverade Global C-State Control, ACPI Sleep/Suspend-to-RAM och SVM och rapporterade 3 dagar, 15 timmar och 38 minuters stabil drifttid samt markerade problemet som till synes löst. De planerade att aktivera ändringarna en i taget igen, så tråden fastställde aldrig vilken enskild inställning som var ansvarig.
Det ursprungliga symtomet såg ut som ett nätverksbortfall på Intel I211
ZimaOS 1.5.3 förlorade anslutningen med några timmars mellanrum och krävde omstart. Samma dator hade varit stabil under Windows Server, medan ett annat nyare ZimaOS-system i samma nätverk var stabilt.
Att inaktivera NIC:s Wake-on-LAN var ett tidigt test i communityn
Användes vid felsökning i communityn ethtool att inaktivera WOL och föreslog att man skulle undvika en konfiguration med dubbla statiska IP-adresser. Detta var rimliga tester, men datorn låste sig senare igen.
Därför kan WOL inte presenteras som den bekräftade slutliga lösningen.
En BIOS-uppdatering av moderkortet förbättrade drifttiden men löste inte problemet helt
Användaren uppgav att en BIOS-uppdatering ökade drifttiden från ungefär tre timmar till mer än tio timmar. Problemet återkom senare, vilket visade att förbättring och slutgiltig lösning var olika milstolpar.
Felet låste till slut även den lokala terminalen
När problemet återkom accepterade en lokalt ansluten terminal inga kommandon. Konsolen upprepade fel ungefär var 15:e sekund. Detta flyttade diagnosen bort från att enbart gälla ett Ethernet-konfigurationsproblem.
Fel i firmware/ACPI-strömtillstånd blev mer relevanta
Loggarna innehöll upprepade ACPI MWAIT-varningar om firmware och C-tillstånd. Användaren upptäckte också att en BIOS-uppdatering hade ändrat ACPI:s vilolägesbeteende. Därefter inaktiverade de flera ström- och virtualiseringsfunktioner för stabilitetstester.
Källan blev stabil efter tre BIOS-ändringar
- Global C-State Control: Inaktiverad
- ACPI-vila/avstängning till RAM: Inaktiverad
- SVM: Inaktiverad
Därefter rapporterade användaren mer än tre dagars stabil drifttid.
Kopiera inte dessa inställningar universellt. Om SVM inaktiveras inaktiveras även AMD:s maskinvaruvirtualisering, vilket kan hindra ZVM och andra virtuella maskiner från att fungera.
Källan hade även en NVIDIA GT 710-drivrutinsgren som inte stöddes
Loggarna visade att den installerade NVIDIA 580-drivrutinen ignorerade GT 710 eftersom grafikprocessorn tillhörde den äldre 470.xx-grenen. Detta var ett verkligt kompatibilitetsproblem, men tråden bevisade inte att det orsakade låsningarna.
Kompatibilitet med x86-maskinvara från tredje part omfattar fast programvara, inte bara drivrutiner
Aktuella ZimaOS stöder generisk x86-64, men IceWhale varnar uttryckligen för att inte alla moderkort, styrenheter, grafikenheter eller nätverksgränssnitt har validerats.
Använd det aktuella felsökningsramverket för maskinvara från tredje part innan du tillämpar AB350-specifika BIOS-inställningar på andra plattformar.
Säkrare aktuell diagnos
- Samla in loggar från föregående start och kärnan efter felet.
- Fastställ om endast nätverket slutade fungera eller om hela värdsystemet frös.
- Uppdatera den fasta programvaran inom moderkortstillverkarens gränser för CPU-stöd.
- Testa en BIOS-ändring för strömläge i taget när det är möjligt.
- Ta bort eller inaktivera inkompatibla expansionsenheter om systemet kan starta utan dem.
- Testa virtualisering igen först när baslinjestabiliteten har fastställts.
Frysningen av den lokala konsolen ändrade diagnosen
När problemet först såg ut som ett avbrott i Intel I211-länken var energisparfunktioner för nätverkskortet och Wake-on-LAN rimliga tester. När den lokala terminalen också slutade svara blev en renodlad Ethernet-drivrutinsförklaring betydligt mindre övertygande.
Detta är en allmän diagnostisk princip: utöka felområdet när fel uppstår i oberoende delsystem.
De tre sista BIOS-ändringarna tillämpades tillsammans
Användaren inaktiverade Global C-State Control, ACPI Sleep/Suspend-to-RAM och SVM och rapporterade sedan stabilitet i flera dygn. Eftersom flera variabler ändrades samtidigt kan källan inte fastställa vilken enskild inställning som löste problemet.
SVM är AMD:s stöd för virtualisering. Om du inaktiverar det kan virtuella maskiner sluta fungera, så det bör inte rekommenderas generellt bara för att det ingick i källans lyckade test.
BIOS-uppdateringen gav värdefulla belägg även om den inte var den slutliga lösningen
En uppdatering av moderkortets firmware ökade den stabila perioden från ungefär tre timmar till mer än tio timmar. Det tyder på att firmware- eller strömhanteringsbeteende spelade roll, men det senare återkommande felet visar att uppdateringen ensam inte var tillräcklig.
Drivrutinsmismatchen för GT 710 var verklig, men det bevisades inte att den orsakade frysningen
Loggarna visade att den installerade NVIDIA 580-drivrutinsgrenen inte stödde det äldre GT 710, som hör till den äldre drivrutinsgrenen. Det kan slå ut GPU-funktioner och orsaka fel, men källan visade inte att nätverks- eller värdlåsningarna löstes enbart genom att ta bort eller korrigera GPU-drivrutinen.
Diagnostik av aktuell maskinvara från tredje part bör börja med standardinställningar för firmware
På ett äldre AM4-moderkort bör du uppdatera BIOS, dokumentera de ursprungliga inställningarna, inaktivera aggressiva vilolägesfunktioner endast som ett kontrollerat test och samla in loggar från tidigare starter. Ta hänsyn till dina krav på Ethernet och virtualisering innan du inaktiverar funktioner permanent.
När systemet är stabilt kan du återaktivera en ändrad funktion i taget om du behöver isolera den minsta nödvändiga åtgärden.
Källans drifttid på flera dygn är stark användarverifiering, inte produktcertifiering
Tre dygn och femton timmar utan den tidigare kraschen är meningsfulla belägg för att firmwareändringarna förbättrade den maskinen. Det bekräftar inte att alla AB350/I211-plattformar fungerar så och bevisar inte att ZimaOS generellt är inkompatibelt med det kretskortet.
Vanliga frågor om nätverksbortfall
Var det underliggande problemet slutligen enbart Intel I211-nätverkskortet?
Nej. Det lokala systemet frös också, vilket gjorde detta till ett bredare problem med plattformsstabiliteten.
Löste det problemet att bara inaktivera WOL?
Nej. Felet återkom senare.
Vilken ändring sammanföll med den slutliga stabila perioden?
Användaren inaktiverade Global C-States, ACPI Suspend-to-RAM och SVM och rapporterade sedan mer än tre dygns drifttid.
