No artigo anterior, Pop!_OS não mantém o perfil Performance após reiniciar: uma investigação (parte 1), o problema principal foi resolvido através da criação de um pequeno serviço systemd responsável por reaplicar o perfil de energia Performance após a inicialização do sistema.
O caso parecia encerrado.
Entretanto, durante a análise dos logs do system76-power, uma mensagem continuava aparecendo a cada boot:
failed to set link time power management policymed_power_with_dipm on host5Operation not supported
Como o perfil passou a funcionar corretamente, seria perfeitamente razoável ignorar esse aviso.
Mas algumas perguntas permaneceram sem resposta.
O que era o host5?
Por que apenas ele gerava erros?
E, principalmente, por que um problema aparentemente relacionado ao gerenciamento de energia estava mencionando uma porta SATA?
Foi a tentativa de responder essas perguntas que deu início a uma segunda investigação — uma investigação que acabou revelando uma interação pouco conhecida entre o slot M.2 da placa-mãe e a controladora SATA do chipset Intel Z97.
O ponto de partida
A primeira hipótese parecia bastante razoável.
Talvez algum SSD ou HD conectado ao sistema não suportasse a política de gerenciamento de energia que o system76-power tentava aplicar durante a inicialização.
O erro mencionava:
med_power_with_dipm
uma política relacionada ao gerenciamento de energia de dispositivos SATA.
Se algum dispositivo fosse incompatível com esse recurso, a mensagem faria sentido.
Mas antes de tirar conclusões, era necessário descobrir qual dispositivo estava associado ao misterioso host5.
Mapeando os hosts SATA
O Linux expõe os dispositivos SATA através de hosts SCSI virtuais.
Utilizando informações presentes em /sys, foi possível mapear a topologia da máquina:
| Host | Porta ATA | Dispositivo |
|---|---|---|
| host0 | ata1 | HD Western Digital 1 TB |
| host1 | ata2 | SSD Crucial MX300 1 TB |
| host2 | ata3 | SSD KingFast 512 GB |
| host3 | ata4 | ? |
| host4 | ata5 | SSD do sistema |
| host5 | ata6 | ? |
Os hosts 3 e 5 chamaram atenção imediatamente por não possuírem dispositivos associados.
A hipótese seguinte foi simples:
Talvez o system76-power estivesse tentando aplicar configurações em portas SATA sem nenhum disco conectado.
Reproduzindo o erro
Para testar essa hipótese, foi feita uma tentativa manual de aplicar a mesma política utilizada pelo daemon:
echo med_power_with_dipm | sudo tee \/sys/class/scsi_host/host5/link_power_management_policy
O resultado foi imediato:
Operation not supported
Exatamente a mesma mensagem observada nos logs.
O mesmo teste foi repetido em host3, produzindo o mesmo comportamento.
Até aquele momento parecia apenas um caso de portas SATA sem dispositivos conectados.
Mas a investigação ainda reservava uma surpresa.
A descoberta inesperada
Durante a análise das mensagens de inicialização do kernel surgiu uma informação extremamente relevante:
ahci 0000:00:1f.2: 4/6 ports implemented (port mask 0x17)
Essa única linha mudou completamente o rumo da investigação.
Embora a controladora AHCI suportasse seis portas SATA, apenas quatro estavam efetivamente implementadas.
Pouco depois, o kernel registrava:
ata4: DUMMYata6: DUMMY
Isso significava que aquelas portas não estavam apenas vazias.
Do ponto de vista do controlador AHCI, elas não eram portas SATA operacionais.
O que significa uma porta DUMMY?
Inicialmente pensei que as portas simplesmente estivessem sem dispositivos conectados.
Mas existe uma diferença importante.
Quando uma porta SATA existe fisicamente, mas não possui nenhum dispositivo conectado, o kernel normalmente registra mensagens como:
ataX: SATA link down
Já no meu caso o kernel registrava:
ata4: DUMMYata6: DUMMY
Uma porta sem cabo continua sendo uma porta válida.
Uma porta DUMMY, por outro lado, é uma porta que o próprio controlador não considera implementada operacionalmente.
Essa distinção acabou sendo a chave para entender todo o comportamento observado.
Confirmando a topologia
Outras mensagens do kernel reforçaram a descoberta:
ata1: SATA ...ata2: SATA ...ata3: SATA ...ata4: DUMMYata5: SATA ...ata6: DUMMY
A distribuição das portas passou a ser:
| Porta | Estado |
|---|---|
| ata1 | Implementada |
| ata2 | Implementada |
| ata3 | Implementada |
| ata4 | DUMMY |
| ata5 | Implementada |
| ata6 | DUMMY |
A correspondência era perfeita com a informação fornecida pelo controlador:
4/6 ports implemented
Observação
Durante toda esta investigação não foram encontrados indícios de defeito em discos, cabos SATA ou na controladora de armazenamento.
O objetivo passou a ser compreender por que determinadas portas eram identificadas pelo kernel como DUMMY e por que o system76-power tentava configurá-las.
A pista no manual da placa-mãe
Foi então que uma observação antiga do manual da MSI Z97M-G43 voltou à memória.
A documentação informa que determinadas portas SATA tornam-se indisponíveis quando um dispositivo M.2 está instalado.
E justamente nesta máquina existe um SSD M.2 contendo os sistemas Pop!_OS e Windows.
As peças começaram a se encaixar.
Conectando os pontos
O cenário mais provável passou a ser:
SSD M.2 instalado ↓Chipset compartilha recursos SATA ↓Algumas portas são desabilitadas ↓AHCI informa apenas 4 portas implementadas ↓Kernel cria ata4 e ata6 como DUMMY ↓system76-power tenta aplicar DIPM ↓Operation not supported
O mais importante é que essa descoberta eliminou uma série de suspeitas iniciais.
Não havia evidências de:
- SSD defeituoso;
- HD com problemas;
- Cabo SATA defeituoso;
- Falha da controladora;
- Incompatibilidade dos dispositivos de armazenamento.
Na realidade, o daemon estava tentando aplicar configurações em portas que o próprio controlador não considerava operacionais.
A relação com o erro original
Curiosamente, ainda não foi possível afirmar com absoluta certeza que essa condição era a causa direta da não restauração do perfil Performance observada no artigo anterior.
Entretanto, a coincidência é difícil de ignorar.
O aviso aparecia exatamente durante a tentativa de inicialização do perfil de energia e desaparecia dos registros relevantes após a solução adotada com o serviço systemd.
Mesmo que não tenha sido a causa principal, ficou claro que o system76-power estava encontrando uma situação que não tratava de forma totalmente elegante.
Conclusão
Nem toda mensagem de erro indica um defeito.
Neste caso, o aviso registrado pelo system76-power não apontava para um SSD defeituoso, um cabo SATA com problemas ou uma controladora falhando.
Na realidade, ele refletia uma característica da própria arquitetura da máquina: o compartilhamento de recursos entre o slot M.2 e determinadas portas SATA da MSI Z97M-G43.
A investigação mostrou que o controlador AHCI expunha apenas quatro das seis portas possíveis, marcando as demais como DUMMY. Quando o system76-power tentava aplicar políticas de gerenciamento de energia nessas portas não implementadas, o resultado era o já conhecido:
Operation not supported
O problema original já havia sido resolvido no artigo anterior. Ainda assim, seguir essa pista permitiu compreender melhor o funcionamento do Linux, da controladora AHCI, do chipset Intel Z97 e das decisões de projeto adotadas pela placa-mãe.
E talvez essa seja uma das partes mais interessantes da computação.
Às vezes começamos tentando corrigir um comportamento aparentemente simples e terminamos aprendendo algo novo sobre a arquitetura da máquina que usamos todos os dias.
16 de Junho de 2026 – Alan Alves Alievi
Deixe uma resposta