Possíveis problemas com a unidade SSD SATA3

4

Ao investigar o problema com meu disco SSD SATA3 sendo reconhecido como SATA2 (por algum motivo tive que mudar as portas SATA para corrigi-lo) notei as seguintes mensagens quando eu corro:

$ dmesg | grep ata3.00
[    0.980592] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    0.980594] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    0.980596] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    0.980712] ata3.00: supports DRM functions and may not be fully accessible
[    0.980795] ata3.00: failed to get NCQ Send/Recv Log Emask 0x1
[    0.980797] ata3.00: ATA-9: SAMSUNG MZ7PD128HAFV-000H7, XXXXXXX, max UDMA/133
[    0.980798] ata3.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    0.981070] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    0.981072] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    0.981073] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    0.981174] ata3.00: supports DRM functions and may not be fully accessible
[    0.981225] ata3.00: failed to get NCQ Send/Recv Log Emask 0x1
[    0.981227] ata3.00: configured for UDMA/133

Minha arquitetura:

$ uname
3.13.8-1-ARCH

Minha preocupação é com a linha em que diz que o sistema falhou ao obter o log de envio / recebimento de NCQ Emask 0x1

Isso é algo que eu preciso me preocupar?

Meu sistema é o Asrock Extreme4 mb com o drive SSD SATA3 da SAMSUNG MZ7PD128HAFV-000H7 no Arch Linux OS.

Atualização 1

Eu corro o SysLinux na minha máquina e abaixo está a saída do mesmo comando (sem mensagens de falha):

root@sysresccd /root % dmesg | grep ata3
[    1.166153] ata3: SATA max UDMA/133 abar m2048@0xf0336000 port 0xf0336200 irq 42
[    1.470696] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.471504] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    1.471507] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    1.471710] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    1.472032] ata3.00: supports DRM functions and may not be fully accessible
[    1.472166] ata3.00: ATA-9: SAMSUNG MZ7PD128HAFV-000H7, SN, max UDMA/133
[    1.472359] ata3.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    1.472760] ata3.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
[    1.472761] ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
[    1.472762] ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
[    1.472920] ata3.00: supports DRM functions and may not be fully accessible
[    1.472946] ata3.00: configured for UDMA/133

Eu comparei os perfis de energia SATA nos dois sistemas operacionais em /sys/class/scsi_host/host(0-7) e eles definiram como max_performance .

O que mais posso verificar em ambos os sistemas operacionais e configurar o Arch para que essa mensagem de falha desapareça?

Atualização 2 Parece que este problema aparece apenas nos novos kernels ...

Eu tentei com o Ubuntu Live CD 12.04, 13.10 e 14.04: Consegui ver esse problema em 14.04, mas não em outras duas versões.

Eu então executo o diff para os arquivos de configuração do kernel, mas não consigo descobrir a mudança exata que me afeta ...

arquivo de configuração do kernel do Ubuntu 13.10

arquivo de configuração do kernel do Ubuntu 14.04

    
por Timka 04.04.2014 / 05:26

1 resposta

3

Este é um erro conhecido nos SSDs da Samsung: as unidades não implementam corretamente os comandos de ajuste enfileirados.

No entanto, o Ubuntu (e provavelmente a maioria das outras distribuições Linux) agora implementam o trim como um cronjob para melhorar o desempenho, portanto, isso não é uma preocupação prática.

Para mais detalhes, veja o bug do kernel sobre isso: link

O motivo pelo qual o erro não apareceu nos kernels mais antigos é que eles não tentam usar a função de bugs da unidade, portanto, eles nunca vêem o erro. Mesmo os novos kernels (4.0 e forward) sabem que os drives possuem este erro, então o erro não será mostrado para o drive no futuro.

    
por 17.04.2015 / 10:01