Linux 6.17+ pode “inventar” portas SATA e drenar bateria em Intel recentes

Uma regressão no subsistema libata/AHCI do Linux está afetando máquinas com o Intel Raptor Lake SATA AHCI Controller (8086:7a62). Em kernels mais novos que 6.14 (casos relatados em 6.17 e 6.18), o sistema passa a expor hosts SCSI a mais do que deveria e, na prática, “cria” portas SATA que não existem.

Na prática, isso aparece assim: em vez de apenas as portas reais da placa-mãe, o kernel lista 8 hosts SCSI, sendo que 4 deles ficam com o SATA Link Power Management (LPM) preso em max_performance e não aceitam alteração via sysfs. O resultado é silencioso e chato: a plataforma perde os estados mais profundos de economia e o consumo em idle sobe.

O sintoma que denuncia o bug

O relato descreve um padrão bem específico:

8 hosts SCSI aparecem no sistema, mesmo com placa-mãe tendo 4 portas SATA físicas
4/8 hosts ficam travados em max_performance
tentativa de mudar o policy falha com “Operation not supported”
powertop marca 4 tunables de SATA LPM como “Bad” permanentemente
o pacote da CPU fica preso em C3, sem atingir C8 (ou mais profundo)
aumento de consumo em idle de aproximadamente +4 W

Se você usa Intel recente e percebeu piora de bateria/temperatura do nada após atualizar o kernel, esse padrão é o tipo de coisa que vale investigar.

Por que “portas fantasmas” viram drenagem de energia

O ponto central é o seguinte: o driver AHCI acaba lidando com portas não implementadas como se fossem válidas. Esse detalhe é crítico porque o fluxo de gerenciamento de energia do link (HIPM/DIPM e políticas de LPM) depende de o controlador e o driver conseguirem negociar estados mais econômicos.

Quando metade desses “hosts” está efetivamente em uma condição inválida e o kernel força max_performance, você perde o efeito cascata que normalmente permite que a plataforma inteira “relaxe” em idle. A consequência aparece no topo da pilha, na CPU: o pacote deixa de cair para estados profundos e fica preso em algo como C3, o que tende a manter consumo e calor acima do normal.

Como checar se você foi afetado agora

Confirme o controlador SATA (procure por 8086:7a62):

Bash

lspci -nn | grep -i -E 'sata|ahci'

lspci -nn | grep -i -E 'sata|ahci'

Veja quantos hosts SCSI existem e qual policy de LPM cada um está usando:

Bash

for h in /sys/class/scsi_host/host*; do
  printf "%s: " "$(basename "$h")"
  cat "$h/link_power_management_policy" 2>/dev/null || echo "N/A"
done

for h in /sys/class/scsi_host/host*; do
  printf "%s: " "$(basename "$h")"
  cat "$h/link_power_management_policy" 2>/dev/null || echo "N/A"
done

Se você enxergar algo parecido com metade em max_performance e metade em med_power_with_dipm, acende o alerta.

No powertop, olhe os tunables ligados a SATA LPM (e se ficam “Bad” sem chance de ajuste).

O patch que mira o problema na raiz

Após o bug report, Niklas Cassel publicou uma série de correções “misc LPM related fixes”. A mais importante para esse caso é direta e cirúrgica: não ler a área “per-port” de portas não implementadas, porque a própria especificação AHCI proíbe esse acesso.

A série também inclui ajustes relacionados a como LPM e recursos são configurados e exibidos (incluindo pontos envolvendo dispositivos ATAPI), mas o que conversa diretamente com o comportamento de “portas fantasmas” é impedir que o driver trate como real aquilo que o hardware não implementa.

O que fazer enquanto a correção não chega no seu kernel

Se você confirmou o padrão (hosts a mais e LPM travado), a medida mais conservadora no curto prazo é ficar em um kernel 6.14.x (ou outro que você já validou como “OK” no seu hardware) até a correção cair na sua árvore/distro.
Acompanhe a thread e os patches na lista (links no final) para saber quando a correção foi mesclada e quando pode virar backport para stable ou para o kernel do seu fornecedor.
Use powertop como termômetro. Se o sistema voltar a alcançar C-states profundos e os tunables de SATA LPM deixarem de ficar presos em “Bad”, você tende a ver o consumo voltar ao normal.