De repente, o seu HP Microserver Gen8 começa a travar aleatoriamente com Linux mais recente: luz de saúde piscando em vermelho, console congelado e, às vezes, só volta à vida depois de tirar o cabo da PSU. Nos logs, a pista aparece pouco antes do colapso: “NMI: IOCK error (debug interrupt?) for reason 71 (ou 61) on CPU 0”. Foi exatamente assim que um usuário descreveu o problema após atualizar do kernel 6.1 para a série 6.12 — o caso foi levado à LKML por Uwe Kleine-König e envolve nomes de peso como Thomas Gleixner e Rafael J. Wysocki.
A causa provável: C-states profundos demais
Tudo aponta para uma instabilidade quando a CPU entra em C-states mais profundos durante ocioso — isto é, um “sono” profundo do processador do qual ele nem sempre acorda direito. O backtrace visto no relato bate no caminho de intel_idle e cpuidle_enter_state, reforçando a tese. Em outras palavras: não parece ser disco, rede ou driver aleatório, e sim gestão de energia em idle em kernels recentes.
A solução: limitar os C-states
A recomendação prática que já vem mostrando efeito é limitar a profundidade do C-state do driver intel_idle. Na linha de comando do kernel, adicione:
intel_idle.max_cstate=2Essa foi a orientação passada na discussão — começar com =2 (se persistir, testar =1 ou até =0). Um dos afetados relatou quatro dias sem travar após aplicar o parâmetro, muito acima da “média” de crashes que via antes.
Dica extra (se ainda ver alerta, mas sem crash)
Alguns usuários notaram que desligar o IOMMU (intel_iommu=off) impediu o travamento fatal — a iLO ainda pisca vermelho, o kernel registra o NMI: IOCK error, mas o servidor permanece rodando. É possível testar sem esse parâmetro depois, uma vez estabilizado com intel_idle.max_cstate=2, para isolar a causa.
Por que isso importa agora
O problema foi notado após atualização (ex.: de 6.1 para 6.12) em Debian nas máquinas Gen8, e há relatos semelhantes em outras distros desde versões anteriores — reforçando que não é um caso isolado e que a combinação “hardware antigo + políticas de energia novas do kernel” pode acentuar o bug. Se você administra home-labs ou pequenos servidores, isso explica aqueles “hangs” fantasmagóricos que desafiam o seu roteiro de manutenção.
Passo a passo rápido
- Edite a linha de comando do kernel no seu bootloader e inclua intel_idle.max_cstate=2 (mantenha outros parâmetros).
- Reinicie e monitore logs e estabilidade por alguns dias.
- Se persistirem travamentos, teste =1 ou =0; se apenas alertas aparecerem, avalie retirar intel_iommu=off (se usado) para confirmar o verdadeiro “culpado”. (bugs.debian.org)
