Cette source ne doit pas être résumée par « désactiver le Wake-on-LAN pour résoudre les pertes de connexion de l’Intel I211 ». Le symptôme initial ressemblait à une panne réseau, mais l’enquête a ensuite montré que le terminal local se bloquait également et que le système émettait de façon répétée des erreurs liées au micrologiciel et au processeur. Le problème était devenu un problème de stabilité de l’ensemble de la plateforme.
La vérification la plus probante par l’utilisateur est survenue après des modifications au niveau du BIOS. L’utilisateur a désactivé Global C-State Control, ACPI Sleep/Suspend-to-RAM et SVM, puis a signalé 3 jours, 15 heures et 38 minutes de fonctionnement stable, considérant que le problème semblait résolu. Il prévoyait de réactiver les options une par une ; la discussion n’a donc jamais permis d’identifier le paramètre individuel responsable.
Le symptôme initial ressemblait à une perte de connexion réseau due à une puce Intel I211
ZimaOS 1.5.3 perdait sa connectivité toutes les quelques heures et nécessitait un redémarrage. La même machine était restée stable sous Windows Server, tandis qu’un autre système ZimaOS plus récent sur le même réseau était stable.
La désactivation de la fonction Wake-on-LAN de la carte réseau a été un premier test effectué par la communauté
Dépannage utilisé par la communauté ethtool pour désactiver le WOL et a suggéré d’éviter une configuration avec une double adresse IP statique. Il s’agissait de tests raisonnables, mais la machine s’est de nouveau bloquée par la suite.
Par conséquent, le WOL ne peut pas être présenté comme la solution finale confirmée.
Une mise à jour du BIOS de la carte mère a amélioré l’autonomie de fonctionnement, sans toutefois résoudre complètement le problème
L’utilisateur a indiqué qu’une mise à jour du BIOS avait fait passer l’autonomie de fonctionnement d’environ trois heures à plus de dix heures. Le problème est ensuite réapparu, montrant que cette amélioration et la résolution définitive étaient deux étapes différentes.
La panne a fini par bloquer également le terminal local
Lorsque le problème est réapparu, un terminal connecté localement n’acceptait plus les commandes. La console répétait des erreurs toutes les ~15 secondes. Le diagnostic s’est ainsi éloigné d’un simple problème de configuration Ethernet.
Les erreurs de micrologiciel liées à l’ACPI et aux états d’alimentation sont devenues plus pertinentes
Les journaux contenaient des avertissements répétés du micrologiciel ACPI concernant l’état C MWAIT. L’utilisateur a également découvert qu’une mise à jour du BIOS avait modifié le comportement de la mise en veille ACPI. Il a ensuite désactivé plusieurs fonctionnalités d’alimentation et de virtualisation pour effectuer des tests de stabilité.
La source est devenue stable après trois modifications du BIOS
- Contrôle global des états C : désactivé
- Veille ACPI / suspension vers la RAM : désactivée
- SVM : désactivé
Par la suite, l’utilisateur a signalé plus de trois jours de fonctionnement stable.
Ne copiez pas ces paramètres de manière universelle. La désactivation de SVM désactive également la virtualisation matérielle AMD et peut empêcher ZVM ou d’autres machines virtuelles de fonctionner.
La source utilisait également une branche de pilote NVIDIA GT 710 non prise en charge
Les journaux indiquaient que le pilote NVIDIA 580 installé ignorait la GT 710, car ce GPU appartenait à la branche legacy 470.xx. Il s’agissait d’un véritable problème de compatibilité, mais le fil de discussion n’a pas démontré qu’il était à l’origine des blocages.
La compatibilité x86 tierce inclut le micrologiciel, pas uniquement les pilotes
ZimaOS prend actuellement en charge le x86-64 générique, mais IceWhale avertit explicitement que toutes les cartes mères, tous les contrôleurs, périphériques graphiques ou interfaces réseau ne sont pas validés.
Utilisez le cadre actuel de dépannage du matériel x86 tiers avant d’appliquer des paramètres BIOS spécifiques à l’AB350 sur des plateformes sans rapport.
Diagnostic actuel plus sûr
- Capturez les journaux du démarrage précédent et du noyau après la défaillance.
- Déterminez si seule la connexion réseau a échoué ou si l’hôte entier s’est figé.
- Mettez à jour le micrologiciel dans les limites de prise en charge du processeur définies par le fabricant de la carte mère.
- Testez une seule modification de l’état d’alimentation du BIOS à la fois, lorsque c’est possible.
- Retirez ou désactivez les périphériques d’extension incompatibles si le système peut démarrer sans eux.
- Ne retestez la virtualisation qu’une fois la stabilité de base établie.
Le gel de la console locale a changé le diagnostic
Lorsque le problème ressemblait d’abord à une perte de liaison de l’Intel I211, les options d’économie d’énergie de la carte réseau et le Wake-on-LAN constituaient des tests raisonnables. Dès que le terminal local a également cessé de répondre, l’hypothèse d’un simple problème de pilote Ethernet est devenue beaucoup moins convaincante.
Il s’agit d’un principe général de diagnostic : élargir le domaine de la panne lorsque les défaillances touchent des sous-systèmes indépendants.
Les trois dernières modifications du BIOS ont été appliquées simultanément
L’utilisateur a désactivé Global C-State Control, ACPI Sleep/Suspend-to-RAM et SVM, puis a signalé plusieurs jours de stabilité. Comme plusieurs variables ont été modifiées simultanément, la source ne permet pas d’identifier le paramètre unique qui a corrigé le problème.
SVM est la prise en charge de la virtualisation AMD. Sa désactivation peut empêcher les charges de travail des machines virtuelles ; elle ne doit donc pas être recommandée systématiquement simplement parce qu’elle faisait partie du test concluant décrit par cette source.
La mise à jour du BIOS a fourni des éléments utiles, même si elle n’était pas la solution finale
La mise à jour du micrologiciel de la carte mère a prolongé la période de stabilité, qui est passée d’environ trois heures à plus de dix heures. Cela suggère que le comportement du micrologiciel ou de la gestion de l’alimentation a joué un rôle, mais la réapparition ultérieure du problème montre que la mise à jour seule était insuffisante.
L’incompatibilité de pilote de la GT 710 était réelle, mais il n’a pas été prouvé qu’elle causait le gel
Les journaux indiquaient que la branche NVIDIA 580 installée ne prenait pas en charge la GT 710, qui appartient à une branche de pilotes plus ancienne. Cela peut interrompre le fonctionnement du GPU et générer des erreurs, mais la source n’a pas démontré que la suppression ou la correction du pilote du GPU avait à elle seule résolu les blocages du réseau ou de l’hôte.
Le diagnostic actuel du matériel tiers doit commencer par les paramètres par défaut du micrologiciel
Sur une ancienne carte mère AM4, mettez le BIOS à jour, notez les paramètres d’origine, désactivez les fonctions de mise en veille agressive uniquement comme test contrôlé et recueillez les journaux du démarrage précédent. Tenez compte des besoins en Ethernet et en virtualisation avant de désactiver définitivement certaines fonctions.
Une fois le système stable, réactivez une fonctionnalité modifiée à la fois si vous devez isoler le contournement minimal.
La disponibilité de plusieurs jours rapportée par la source constitue une validation solide par l’utilisateur, pas une certification du produit
Trois jours et quinze heures sans le plantage précédent constituent un élément probant : les modifications du micrologiciel ont amélioré le fonctionnement de cette machine. Cela ne certifie pas toutes les plateformes AB350/I211 et ne prouve pas que ZimaOS soit généralement incompatible avec ce chipset.
FAQ sur les pertes réseau
Le problème initial était-il finalement dû uniquement à la carte réseau Intel I211 ?
Non. Le système local s’est également figé, ce qui indique un problème plus large de stabilité de la plateforme.
La désactivation de WOL seule a-t-elle résolu le problème ?
Non. La panne est revenue par la suite.
Quel changement a coïncidé avec la dernière période de stabilité ?
L’utilisateur a désactivé Global C-States, ACPI suspend-to-RAM et SVM, puis a signalé une disponibilité de plus de trois jours.
