← Todos os posts
24 de jun. de 2026

PPiNAS: NAS de 6 baias no Raspberry Pi 5 e o travamento do ASM1166

TL;DR: O controlador PCIe do Pi 5 usa uma implementação proprietária de MSI (mip1) que aloca vetores de interrupção em endereços acima de 4 GB; o ASM1166 é um dispositivo 32-bit e não consegue endereçar esses vetores, então com drives conectados o controlador trava silenciosamente durante a enumeração PCIe — sem output do kernel, sem log de erro, apenas um sistema que nunca inicializa. Resolvido com duas linhas em /boot/firmware/config.txt: dtoverlay=pciex1-compat-pi5,no-mip faz fallback para um caminho de interrupção compatível com 32-bit, e dtparam=pciex1_gen=2 trava o link em Gen 2 para evitar uma classe separada de falhas de enumeração pelo adaptador X1001.

A lane PCIe nativa do Pi 5 é genuinamente útil para builds de NAS — sem USB, largura de banda dedicada por disco. O problema é que vários controladores SATA comuns, incluindo o ASM1166, são dispositivos 32-bit que não funcionam com a implementação MSI padrão do Pi 5. Este post cobre o hardware montado, o travamento silencioso que ele causou, a causa raiz no subsistema de interrupções do Pi 5 e a mudança de configuração que resolve o problema.

O Pi 5 inicializava normalmente. Conectei os discos. Nada — sem saída UART, sem padrão de pisca do LED, o LED verde simplesmente aceso enquanto o sistema nunca subia. O travamento não deixou log e não indicou em que ponto da inicialização tinha ocorrido. Esse silêncio é o problema todo: uma falha de enumeração PCIe nessa camada não produz nada que o usuário possa pesquisar.

Este post é para quem está rodando um Raspberry Pi 5 com um controlador SATA PCIe e batendo em um boot em branco idêntico. Você já deve estar confortável editando /boot/firmware/config.txt e lendo output do dmesg. A causa raiz está na implementação MSI do Pi 5, não nos discos, no firmware do controlador ou no cabo.

Índice

  1. Hardware
  2. Layout
  3. A enumeração PCIe trava silenciosamente com discos conectados — sem output, sem erro
  4. Por que o ASM1166 trava: dispositivos 32-bit não alcançam os vetores do mip1
  5. Duas linhas no config.txt restauram a enumeração normal
  6. A ordem de enumeração SATA não é garantida — /dev/sdX vai te trair
  7. Várias semanas de operação: consumo, spindown e uma ressalva importante
  8. Onde essa correção não se aplica e o que ela não resolve
  9. Referências

Hardware

ComponenteModelo
SBCRaspberry Pi 5 (4 GB)
Adaptador PCIeGeekworm X1001 (M.2 Key-M → PCIe x1)
Controlador SATAOLMaster 6 baias (ASM1166)
DiscosHDD 1 TB, HDD 512 GB, SSD 256 GB

O X1001 converte o conector FPC PCIe do Pi 5 para um slot M.2. O gabinete OLMaster usa esse slot para expor o ASM1166 — um controlador SATA de 6 portas da ASMedia.

Layout

RPi 5
└── Geekworm X1001 (PCIe FPC → M.2 → PCIe x1)
    └── Controlador SATA ASM1166 (OLMaster 6 baias)
        ├── sda → HDD 1 TB    → /mnt/media-server
        ├── sdc → SSD 256 GB  → /mnt/file-storage
        └── sdd → HDD 512 GB  → /mnt/backups

O 1 TB gira para o Jellyfin. O SSD cuida do armazenamento ativo de arquivos — rápido o suficiente para transferências via Samba. O 512 GB executa backups noturnos com rsync. Sem RAID.

A enumeração PCIe trava silenciosamente com discos conectados — sem output, sem erro

Primeiro boot com os discos conectados: nada. LED verde aceso, sem saída UART, sem sinal de vida. O sistema nunca subiu.

Fui removendo os discos um a um. Sem discos conectados, o Pi bootava normalmente. Com qualquer disco no ASM1166, travava antes de o kernel conseguir exibir qualquer coisa. Com o controlador no slot PCIe mas todos os cabos SATA desconectados — bootava. O travamento acontecia durante a enumeração PCIe do ASM1166 com discos conectados.

# Sem discos: controlador aparece normalmente
lspci -vvv
# 0000:01:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02)

Com discos, o sistema nunca chegava ao ponto onde lspci pudesse rodar.

Por que o ASM1166 trava: dispositivos 32-bit não alcançam os vetores do mip1

O controlador PCIe do Pi 5 usa uma implementação proprietária de MSI (Message Signaled Interrupts) chamada mip1. Ela aloca vetores de interrupção em endereços acima de 4 GB. O ASM1166 é um dispositivo de 32 bits — não consegue endereçar memória acima desse limite. Quando o kernel tenta atribuir vetores MSI usando o mip1, o controlador trava. Nenhum erro é gerado, nenhum log é gravado. O barramento para silenciosamente.

Isso está documentado em raspberrypi/linux#6214. Vários controladores SATA e NVMe sofrem o mesmo problema pelo mesmo motivo.

Duas linhas no config.txt restauram a enumeração normal

Duas linhas em /boot/firmware/config.txt:

dtparam=pciex1_gen=2
dtoverlay=pciex1-compat-pi5,no-mip

no-mip desativa a implementação MSI mip1 e faz fallback para um caminho de interrupção compatível com 32 bits. Essa é a correção. O ASM1166 agora recebe vetores de interrupção dentro do alcance que ele consegue endereçar, e a enumeração conclui normalmente.

pciex1_gen=2 trava o link em Gen 2. O ASM1166 via X1001 não negocia Gen 3 de forma confiável, então isso previne uma classe separada de falhas de enumeração.

Após essas duas linhas:

[    3.241] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.251] ata2: SATA link up 6.0 Gbps (SStatus 123 SControl 300)
[    3.261] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.271] ata4: SATA link down (SStatus 0 SControl 300)
[    3.281] ata5: SATA link down (SStatus 0 SControl 300)
[    3.291] ata6: SATA link down (SStatus 0 SControl 300)

Três portas com discos, três vazias. Todos os discos visíveis.

A ordem de enumeração SATA não é garantida — /dev/sdX vai te trair

A ordem de enumeração SATA não é garantida. Depende do timing de link-up, que varia com a velocidade de spin-up dos discos e o estado do controlador. Um disco que era sdb no último boot pode ser sdd no próximo. Usar caminhos de dispositivo no fstab vai montar o sistema de arquivos errado na melhor das hipóteses, e corromper dados na pior.

blkid /dev/sda
# /dev/sda: UUID="a1b2c3d4-..." TYPE="ext4"
# /etc/fstab
UUID=<uuid1>  /mnt/media-server  ext4  defaults,nofail  0  2
UUID=<uuid2>  /mnt/file-storage  ext4  defaults,nofail  0  2
UUID=<uuid3>  /mnt/backups       ext4  defaults,nofail  0  2

nofail instrui o systemd a não travar o boot se uma montagem falhar. Sem isso, um disco ausente ou lento para girar causa um timeout de 90 segundos seguido de modo de emergência — o que importa quando você reinicia a máquina remotamente.

Várias semanas de operação: consumo, spindown e uma ressalva importante

Consumo em idle com os três discos girando: ~8 W. Com HDDs em spindown via hdparm -S: ~5 W.

O setup está rodando há várias semanas com Jellyfin, Samba e rsync noturno sem problemas. Uma ressalva: não faça hot-plug de discos. Com o workaround no-mip ativo, o hot-plug não trava o sistema, mas a enumeração fica inconsistente.

Se você está montando o mesmo setup, adicione as duas linhas do config.txt antes de conectar qualquer disco. O travamento no boot não produz logs e não é óbvio de diagnosticar partindo do zero.

Onde essa correção não se aplica e o que ela não resolve

O workaround no-mip é necessário porque a implementação mip1 do Pi 5 aloca vetores de interrupção fora do espaço de endereçamento de 32 bits. Qualquer dispositivo PCIe de 32 bits vai ter esse problema, não só o ASM1166. Se você trocar por outro controlador SATA e ver o mesmo travamento silencioso, verifique a largura de endereçamento do dispositivo com lspci -vvv — procure DevCap: ... 32-bit na lista de capacidades. Se estiver lá, a mesma correção se aplica.

O que isso não resolve: o Pi 5 continua sendo um caminho PCIe Gen 2 de uma lane só depois de aplicar pciex1_gen=2. Saturar todas as seis portas SATA ao mesmo tempo vai expor esse gargalo. Para streaming de mídia e backups por rsync em três discos, não é um problema na prática — leituras sequenciais de um único HDD ficam bem abaixo da banda do PCIe Gen 2. Uma carga de trabalho que escreve em múltiplos discos ao mesmo tempo tem um teto aqui.

O hot-plug continua pouco confiável com no-mip ativo. Se você precisa trocar discos sem reiniciar, este setup não é a escolha certa. O workaround troca a capacidade de hot-plug por enumeração estável no boot — as duas coisas não coexistem bem no firmware atual do Pi 5.

Referências


Breno Zanato Detomini
Breno Zanato Detomini

Engenheiro de sistemas embarcados e redes, baseado no Brasil.

← Todos os posts