Esta fonte não deve ser resumida como «desative o Wake-on-LAN para corrigir as falhas do Intel I211». O sintoma inicial parecia uma falha de rede, mas a investigação mostrou mais tarde que o terminal local também bloqueava e que o sistema emitia repetidamente erros relacionados com o firmware/CPU. O problema tinha-se tornado um problema de estabilidade de toda a plataforma.
A confirmação mais forte do utilizador surgiu após alterações ao nível da BIOS. O utilizador desativou o Global C-State Control, o ACPI Sleep/Suspend-to-RAM e o SVM e, em seguida, comunicou 3 dias, 15 horas e 38 minutos de tempo de funcionamento estável, assinalando o problema como aparentemente resolvido. Planeava reativar as opções uma a uma, pelo que a discussão nunca isolou qual definição individual era responsável.
O sintoma original parecia uma falha de rede do Intel I211
O ZimaOS 1.5.3 perdia a conectividade a cada poucas horas e exigia um reinício. A mesma máquina tinha permanecido estável com o Windows Server, enquanto outro sistema ZimaOS mais recente na mesma rede permanecia estável.
A desativação do Wake-on-LAN da NIC foi um dos primeiros testes da comunidade
Utilizado na resolução de problemas pela comunidade ethtool para desativar o WOL e sugeriu evitar uma configuração com dois IP estáticos. Estes foram testes razoáveis, mas a máquina voltou a bloquear.
Por isso, o WOL não pode ser apresentado como a solução final confirmada.
Uma atualização da BIOS da placa-mãe melhorou o tempo de funcionamento, mas não resolveu totalmente o problema
O utilizador afirmou que uma atualização da BIOS aumentou o tempo de funcionamento contínuo de aproximadamente três horas para mais de dez horas. O problema voltou mais tarde, mostrando que a melhoria e a resolução final foram marcos diferentes.
A falha acabou também por bloquear o terminal local
Quando o problema voltou, um terminal ligado localmente não aceitava comandos. A consola repetia erros a cada ~15 segundos. Isto afastou o diagnóstico de um problema exclusivamente relacionado com a configuração Ethernet.
Os erros de energia e estado de suspensão do firmware/ACPI tornaram-se mais relevantes
Os registos continham avisos repetidos do firmware ACPI sobre o estado C MWAIT. O utilizador também descobriu que uma atualização da BIOS tinha alterado o comportamento de suspensão do ACPI. Em seguida, desativou várias funcionalidades de gestão de energia/virtualização para testar a estabilidade.
A fonte ficou estável após três alterações à BIOS
- Controlo global dos estados C: Desativado
- Suspensão ACPI / Suspender para RAM: Desativado
- SVM: Desativado
Posteriormente, o utilizador comunicou mais de três dias de funcionamento estável.
Não copie estas definições universalmente. Desativar o SVM também desativa a virtualização de hardware da AMD e pode impedir o funcionamento do ZVM e de outras máquinas virtuais.
A fonte também tinha um ramo de controlador NVIDIA GT 710 não suportado
Os registos indicavam que o controlador NVIDIA 580 instalado ignorava a GT 710, porque essa GPU pertencia ao ramo legado 470.xx. Tratava-se de um problema de compatibilidade real, mas o tópico não provou que este causasse os bloqueios.
A compatibilidade x86 de terceiros inclui o firmware, não apenas os controladores
O ZimaOS atual suporta x86-64 genérico, mas a IceWhale avisa explicitamente que nem todas as placas-mãe, controladores, dispositivos gráficos ou interfaces de rede foram validados.
Utilize a estrutura atual de resolução de problemas de hardware x86 de terceiros antes de aplicar definições da BIOS específicas da AB350 a plataformas não relacionadas.
Diagnóstico atual mais seguro
- Recolha os registos do arranque anterior e do kernel após a falha.
- Determine se apenas a rede falhou ou se todo o anfitrião bloqueou.
- Atualize o firmware dentro dos limites de suporte do processador definidos pelo fabricante da placa-mãe.
- Teste uma alteração de estado de energia da BIOS de cada vez, sempre que possível.
- Remova ou desative dispositivos de expansão incompatíveis, se o sistema conseguir arrancar sem eles.
- Volte a testar a virtualização apenas depois de estabelecer a estabilidade de base.
O bloqueio da consola local alterou o diagnóstico
Quando o problema parecia inicialmente uma queda de ligação da Intel I211, a poupança de energia da NIC e o Wake-on-LAN eram testes razoáveis. Quando o terminal local também deixou de responder, uma explicação exclusivamente relacionada com o controlador Ethernet tornou-se muito menos convincente.
Este é um princípio geral de diagnóstico: alargue o domínio da falha quando as falhas atravessam subsistemas independentes.
As três alterações finais à BIOS foram aplicadas em conjunto
O utilizador desativou Global C-State Control, ACPI Sleep/Suspend-to-RAM e SVM e, de seguida, comunicou estabilidade durante vários dias. Como várias variáveis foram alteradas em simultâneo, a fonte não permite identificar qual foi a única definição que resolveu o problema da máquina.
SVM é o suporte de virtualização da AMD. Desativá-lo pode impedir cargas de trabalho de máquinas virtuais, pelo que não deve ser recomendado universalmente apenas por ter feito parte do teste bem-sucedido desta fonte.
A atualização da BIOS forneceu evidências úteis, embora não tenha sido a solução final
A atualização do firmware da placa-mãe aumentou o período de estabilidade de aproximadamente três horas para mais de dez horas. Isso sugere que o comportamento do firmware/da gestão de energia era relevante, mas a recorrência posterior mostra que a atualização, por si só, foi insuficiente.
A incompatibilidade do controlador da GT 710 era real, mas não foi provado que causasse o bloqueio
Os registos indicaram que o ramo 580 do controlador NVIDIA instalado não suportava a GT 710 antiga, que pertence a um ramo de controladores anterior. Isso pode comprometer a funcionalidade da GPU e produzir erros, mas a fonte não demonstrou que a remoção ou correção isolada do controlador da GPU tenha resolvido os bloqueios da rede/do anfitrião.
O diagnóstico atual de hardware de terceiros deve começar pelas predefinições do firmware
Numa placa AM4 mais antiga, atualize a BIOS, registe as definições originais, desative as funcionalidades agressivas de suspensão apenas como teste controlado e recolha os registos do arranque anterior. Tenha em conta os requisitos de Ethernet e virtualização antes de desativar funcionalidades permanentemente.
Depois de obter estabilidade, volte a ativar uma funcionalidade alterada de cada vez, se precisar de isolar a solução alternativa mínima.
O funcionamento contínuo de vários dias da fonte é uma forte validação por parte do utilizador, não uma certificação do produto
Três dias e quinze horas sem a falha anterior constituem uma evidência relevante de que as alterações de firmware melhoraram o funcionamento dessa máquina. Isso não certifica todas as plataformas AB350/I211 nem prova que o ZimaOS tenha uma incompatibilidade geral com esse chipset.
FAQ sobre falhas de rede
A causa final do problema era exclusivamente a placa de rede Intel I211?
Não. O sistema local também bloqueou, o que aponta para um problema mais abrangente de estabilidade da plataforma.
Desativar apenas o WOL resolveu o problema?
Não. O problema voltou mais tarde.
Que alteração coincidiu com o período final de estabilidade?
O utilizador desativou Global C-States, ACPI suspend-to-RAM e SVM e, de seguida, comunicou mais de três dias de funcionamento contínuo.
