Problèmes possibles avec le lecteur SSD SATA3

Lors de l'enquête sur le problème avec mon disque SSD SATA3 reconnu comme SATA2 (pour une raison quelconque, j'ai dû changer les ports SATA pour le réparer), j'ai remarqué les messages suivants lorsque je cours:

$ 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 

Mon architecture:

 $ uname 3.13.8-1-ARCH 

Ma préoccupation est la ligne où il est dit que le système n'a pas réussi à get NCQ Send / Recv Log Emask 0x1

Est-ce quelque chose dont je dois m'inquiéter?

Mon système est Asrock Extreme4 mb avec le lecteur SAMSUNG MZ7PD128HAFV-000H7 SSD SATA3 sur Arch Linux OS.

Mise à jour 1

J'exécute SysLinux sur ma machine et en dessous la sortie de la même command (pas de messages d'échec):

 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 

J'ai comparé les profils d'alimentation SATA sur les deux systèmes d'exploitation sous /sys/class/scsi_host/host(0-7) et ils ont défini max_performance .

Que puis-je vérifier d'autre sur les deux systèmes d'exploitation et configurer Arch afin que ce message d'échec disparaisse?

Mise à jour 2 On dirait que ce problème n'apparaît que dans les nouveaux kernelx …

J'ai essayé avec Ubuntu Live CD 12.04, 13.10 et 14.04: J'ai pu voir ce problème dans 14.04 mais pas dans les 2 autres versions.

Je lance ensuite diff pour les files de configuration du kernel mais je n'arrive pas à comprendre le changement exact qui m'affecte …

Fichier de configuration du kernel Ubuntu 13.10

Ubuntu 14.04 file de configuration du kernel

Il s'agit d'une erreur connue dans les SSD Samsung: Les lecteurs n'implémentent pas correctement les commands de mise en queue.

Cependant, Ubuntu (et probablement la plupart des autres dissortingbutions Linux) implémente désormais la fonction de découpage en tant que cronjob afin d'améliorer les performances. Il ne s'agit donc pas d'une préoccupation pratique.

Pour plus de détails, voir le bug du kernel sur ceci: https://bugzilla.kernel.org/show_bug.cgi?id=72341

La raison pour laquelle l'erreur n'apparaît pas dans les kernelx plus anciens est que ceux-ci n'essaient pas d'utiliser la fonction buggy du disque, ils ne voient donc jamais l'erreur. Même les nouveaux kernelx (4.0 et avant) savent que les disques ont cette erreur, de sorte que l'erreur ne sera plus affichée pour le disque dans le futur.