Hard Reset Link Exception Emask 0x50 SAct 0x0 SErr 0x4090800 Aktion 0xe eingefroren

8

Folgende Situation:

Ein produktiver Linux Debian 7 Server mit Kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux

Hersteller: Supermicro Produktname: X10SLL-F Version:1.02

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

2x SSD, 2x Festplatte

Jedes Laufwerk kann Sata Rev3 (6,0 Gbit / s) ausführen.

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

Die Kernel-Meldungen deuten (zumindest für mich) auf ein Problem mit allen 4 Laufwerken hin, was mich zu der Annahme veranlasst, dass möglicherweise der Sata-Controller schuld ist.

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

Was ich bereits herausgefunden habe (oder glaube herausgefunden zu haben)

Die Befehle SECURITY FREEZE LOCKund DEVICE CONFIGURATION OVERLAYsind für das Problem nicht wichtig.

Während ich ungefähr 20 Bugreports und viele Dokumentationen las, schlugen einige verlinkte vor, NCQ zu deaktivieren, was ich auch tat.

Zuerst für ein Gerät, nachdem ich 1 Tag gewartet habe, um zu überprüfen, ob der Fehler wiederholt wird, ist es wieder passiert und ich habe es für alle 4 Geräte deaktiviert

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

Keine offensichtliche Änderung der Situation.

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

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

Andere schlagen SATA-Kabel oder sogar eine Inkompatibilität zwischen Board + Laufwerken vor.

Da ich jedoch entweder das Problem auf einem Laufwerk habe und dies auf alle 4 ausgefüllt ist oder das Problem direkt auf allen 4 Geräten auftritt, kann ich das Problem nicht weiter lokalisieren.

Da dies ein Produktionsserver ist, der diesen Server zur Wartung herunterfährt (auch bekannt als Änderungen der BIOS- / Kernel-Parameter), ist dies möglich, aber ich möchte dies nach Möglichkeit verhindern.

Laut dem Hoster könnte dies mit der Energieverwaltung zusammenhängen:

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

Vor der Änderung wurde dies auf gesetzt max_performance.

Das hat auch nicht geholfen.

Intelligente Werte der Festplatten / SDDs sind in Ordnung, nichts zu offensichtlich.

Beachten Sie, dass der UDMA-Wert jetzt nur noch 33 zu sein scheint.

Beim Booten des Servers waren dies die Sata-Link-Geschwindigkeitswerte:

[    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)

Die Situation kann nur bei hoher Auslastung der Festplatten auftreten. Ich habe dies noch nicht getestet, da dies die Serverleistung offensichtlich beeinträchtigen würde.

Die SSDs werden nicht belastet, sie werden gemountet, aber von keinem der Prozesse verwendet.

Der RAM ist ECC, soweit ich das beurteilen kann.

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

Bitte lassen Sie mich wissen, ob ich zusätzliche Informationen geben kann, da mir die Ideen fehlen, was als nächstes zu tun ist.

linux  debian  sata  supermicro 
— Dennis Nolte
quelle
Fragen Sie den Anbieter Supermicro direkt, möglicherweise können sie helfen, wenn der Hoster dies nicht tut.
— Dennis Nolte
1
Beachten Sie, dass das System mit 1,5 Gbit / s neu verhandelt. Versuchen Sie, 1,5 Gbit / s zu erzwingen, und prüfen Sie, ob das System dadurch stabil ist. Es ist ein Datenpunkt. Versuchen Sie askubuntu.com/a/146290/11751, um eine kurze Beschreibung zu erhalten.
— Ein CVn

Antworten:

4

Was Ihr Server erlebt, ist im Grunde eine SATA-Neuverhandlung mit einer niedrigeren Verbindungsgeschwindigkeit nach einigen Problemen bei der Kommunikation mit den Laufwerken.

Diese Faktoren können hier eine Rolle spielen (geordnet nach Wahrscheinlichkeit)

  1. IOPS-Vorgänge mit sehr hoher Latenz (z. B. verursacht durch die Garbage Collection des SSD-Controllers) führen zu einem Timeout des SATA-Befehls. Unterstützt Ihr Laufwerk den Befehl SATA Trim? Wenn ja, versuchen Sie es fstrim /. Ändert es etwas?
  2. Schlechtes Motherboard / Speicher: Ist Ihr Speicher ECC-geschützt? Wenn nicht und wenn Sie können, führen Sie eine erweiterte (2+ Stunden) memtest86 + -Testsitzung durch
  3. Inkompatibilität der Hardware- / Softwaretreiber
  4. Schlechter SATA-Controller: Obwohl dies ziemlich unwahrscheinlich ist, können Sie ihn nicht vollständig ausschließen
  5. Schlechte SATA-Kabel / Laufwerke: Da bei allen vier Laufwerken Probleme auftreten, ist dies sehr unwahrscheinlich
— Shodanshok
quelle
Die ssd (s) werden derzeit nicht verwendet, anscheinend wird ECC verwendet. von dmidecode -t17: Gesamtbreite: 72 Bit Datenbreite: 64 Bit
— Dennis Nolte
3

Laut Supermicro Support liegt der Defekt beim Board:

Zitat:

This board may need ECO 16238 update.
— Dennis Nolte
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.