réinitialisation matérielle exception lien Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe figée

8

Situation suivante:

Un serveur Linux Debian 7 productif avec noyau 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux

Fabricant: Supermicro Nom du produit: X10SLL-F Version:1.02

Contrôleur SATA: Intel Corporation Lynx Point 6-port SATA Controller 1 [AHCI mode] (rev 04)

2x SSD, 2x hdd

chaque disque peut faire Sata Rev3 (6.0Gb / s)

hdparm -I /dev/sd[a-d]|egrep "Model|speed|Transport"
    Model Number:       TOSHIBA THNSNH128GBST                   
    Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    SMART Command Transport (SCT) feature set
    Model Number:       TOSHIBA THNSNH128GBST                   
    Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    SMART Command Transport (SCT) feature set
    Model Number:       ST2000VX000-1CU164                      
    Transport:          Serial, SATA Rev 3.0
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    SMART Command Transport (SCT) feature set
    Model Number:       ST2000VX000-1CU164                      
    Transport:          Serial, SATA Rev 3.0
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    SMART Command Transport (SCT) feature set

Les messages du noyau suggèrent (au moins pour moi) un problème avec les 4 disques, ce qui m'amène à croire que c'est le contrôleur SATA qui pourrait être en faute.

ata1: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
ata1: irq_stat 0x00400040, connection status changed
ata1: SError: { HostInt PHYRdyChg 10B8B DevExch }
ata1: hard resetting link
ata2: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
ata2: irq_stat 0x00400040, connection status changed
ata2: SError: { HostInt PHYRdyChg 10B8B DevExch }
ata2: hard resetting link
ata4: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
ata4: irq_stat 0x00400040, connection status changed
ata4: SError: { HostInt PHYRdyChg 10B8B DevExch }
ata4: hard resetting link
ata3: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
ata3: irq_stat 0x00400040, connection status changed
ata3: SError: { HostInt PHYRdyChg 10B8B DevExch }
ata3: hard resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata4.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata2.00: configured for UDMA/33
ata2: EH complete
ata1.00: configured for UDMA/33
ata1: EH complete
ata3.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata3.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata4.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
ata4.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
ata3.00: configured for UDMA/33
ata3: EH complete
ata4.00: configured for UDMA/33
ata4: EH complete

Ce que j'ai déjà compris (ou que je pense avoir compris)

Les commandes SECURITY FREEZE LOCKet DEVICE CONFIGURATION OVERLAYne sont pas importantes pour le problème.

En lisant environ 20 rapports de bogues et beaucoup de documentations, quelques-uns liés ont suggéré de désactiver NCQ, ce que j'ai fait.

D'abord pour un appareil, après avoir attendu 1 jour pour vérifier si l'erreur se répète, je l'ai de nouveau désactivée pour les 4 appareils

echo "1" >/sys/block/sdc/device/queue_depth

Aucun changement évident dans la situation.

https://ata.wiki.kernel.org/index.php/Libata_error_messages

https://wiki.archlinux.org/index.php/Solid_State_Drives#Resolving_NCQ_errors

D'autres suggèrent un câble SATA ou même une incompatibilité entre carte + disques.

Cependant, comme je semble avoir le problème sur un lecteur et cela se produit sur les 4, ou avoir le problème directement sur les 4 appareils, je ne peux pas identifier le problème plus en détail.

Comme il s'agit d'un serveur de production, mettre ce serveur à l'arrêt pour maintenance (ou modifications des paramètres du bios / noyau) est possible, mais j'aimerais éviter cela si possible.

Selon l'hébergeur, cela pourrait être lié à la gestion de l'alimentation:

https://bugzilla.kernel.org/show_bug.cgi?id=74961 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318218

echo "medium_power" >/sys/class/scsi_host/host0/link_power_management_policy

Avant la modification, celle-ci était définie sur max_performance.

Cela n'a pas aidé non plus.

Les valeurs intelligentes des disques durs / SDD sont OK, rien de trop évident.

Notez que la valeur UDMA ne semble être que 33 maintenant.

Au démarrage du serveur, ce sont les valeurs de vitesse de liaison sata:

[    3.161850] ata6: SATA link down (SStatus 0 SControl 300)
[    3.161867] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.161882] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.161894] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.161907] ata5: SATA link down (SStatus 0 SControl 300)

La situation pourrait se produire sur une charge élevée sur les disques durs uniquement, je n'ai pas encore testé cela car cela affecterait les performances du serveur de toute évidence.

Il n'y a pas de charge sur les SSD, ils sont montés mais ne sont utilisés par aucun des processus.

La RAM est ECC pour autant que je sache.

dmidecode -t 17
# dmidecode 2.11
SMBIOS 2.7 present.

Handle 0x0023, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x0022
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits
    Size: 8192 MB
    Form Factor: DIMM
    Set: None
    Locator: P1-DIMMA1
    Bank Locator: P0_Node0_Channel0_Dimm0
    Type: DDR3
    Type Detail: Synchronous
    Speed: 1600 MHz
    Manufacturer: Samsung
    Serial Number: 373A6427
    Asset Tag: 9876543210
    Part Number: M391B1G73QH0-CK0  
    Rank: 2
    Configured Clock Speed: 1600 MHz

Veuillez me faire savoir si je peux donner des informations supplémentaires car je n'ai pas d'idées sur la suite des choses.

linux  debian  sata  supermicro 
— Dennis Nolte
source
en demandant directement au fournisseur supermicro, ils peuvent aider si l'hébergeur ne le fait pas.
— Dennis Nolte
1
Notez que le système renégocie à 1,5 Gbit / s. Essayez de forcer 1,5 Gbps et voyez si cela rend le système stable. C'est un point de données. Essayez askubuntu.com/a/146290/11751 pour un bref résumé sur la façon de le faire.
— un CVn du

Réponses:

4

Ce que vous expérimentez sur le serveur est essentiellement une renégociation SATA à une vitesse de liaison inférieure après un problème de communication avec les disques.

Ces facteurs peuvent être à l'œuvre ici (classés par probabilité)

  1. opérations IOPS à latence très élevée (par exemple: provoquées par le garbage collection du contrôleur SSD) entraînant un délai d'expiration de la commande SATA. Votre disque prend-il en charge la commande SATA Trim? Si c'est le cas, essayez de courir fstrim /. Cela change-t-il quelque chose?
  2. Mauvaise carte mère / mémoire: votre mémoire est-elle protégée par ECC? Si ce n'est pas le cas, et si vous le pouvez, exécutez une session de test memtest86 + étendue (plus de 2 heures)
  3. incompatibilité des pilotes matériels / logiciels
  4. Mauvais contrôleur SATA: bien que peu probable, vous ne pouvez pas l'exclure complètement
  5. Mauvais câbles / lecteurs SATA: comme les quatre lecteurs vous posent problème, cela est très peu probable
— shodanshok
source
le ssd (s) ne sont pas actuellement utilisés, semble ECC est utilisé. de dmidecode -t17: Largeur totale: 72 bits Largeur des données: 64 bits
— Dennis Nolte
3

Selon Supermicro Support, le défaut réside dans la carte:

Citation:

This board may need ECO 16238 update.
— Dennis Nolte
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.