Nummer Serie Identifizieren der Festplatte laut Log

[hakiri]

Hallo,

einer meiner Festplatten scheint kaputt zu gehen. Beim Datentransfer usw. friert das System ein. Laut SMART scheint zwar alles okay, aber dennoch ist da wohl was im Busch...

Apr 28 21:17:55 kernel: [268207.714663] ata6.00: failed to read SCR 1 (Emask=0x40)
Apr 28 21:17:55 kernel: [268207.719903] ata6.01: failed to read SCR 1 (Emask=0x40)
Apr 28 21:17:55 kernel: [268207.725140] ata6.02: failed to read SCR 1 (Emask=0x40)
Apr 28 21:17:55 kernel: [268207.730365] ata6.03: failed to read SCR 1 (Emask=0x40)
Apr 28 21:17:55 kernel: [268207.735590] ata6.04: failed to read SCR 1 (Emask=0x40)
Apr 28 21:17:55 kernel: [268207.740822] ata6.15: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen
Apr 28 21:17:55 kernel: [268207.748050] ata6.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
Apr 28 21:17:55 kernel: [268207.755362] ata6.01: exception Emask 0x1 SAct 0xfff7 SErr 0x0 action 0x6 frozen
Apr 28 21:17:55 kernel: [268207.762761] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.768083] ata6.01: cmd 61/f0:00:10:8b:b9/01:00:34:00:00/40 tag 0 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.768087]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.783551] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.787300] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.792621] ata6.01: cmd 61/f0:08:00:8d:b9/01:00:34:00:00/40 tag 1 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.792625]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.808084] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.811833] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.817153] ata6.01: cmd 61/f0:10:f0:8e:b9/01:00:34:00:00/40 tag 2 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.817157]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.832621] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.836368] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.841690] ata6.01: cmd 61/f0:20:d0:73:b9/01:00:34:00:00/40 tag 4 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.841694]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.857153] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.860906] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.866229] ata6.01: cmd 61/f0:28:c0:75:b9/01:00:34:00:00/40 tag 5 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.866233]          res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
Apr 28 21:17:55 kernel: [268207.881783] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.887100] ata6.01: cmd 61/f0:30:b0:77:b9/01:00:34:00:00/40 tag 6 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.887104]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.902560] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.906306] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.911623] ata6.01: cmd 61/f0:38:a0:79:b9/01:00:34:00:00/40 tag 7 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.911627]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.927083] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.930831] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.936146] ata6.01: cmd 61/f0:40:90:7b:b9/01:00:34:00:00/40 tag 8 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.936150]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.951610] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.955359] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.960675] ata6.01: cmd 61/f0:48:80:7d:b9/01:00:34:00:00/40 tag 9 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.960679]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268207.976136] ata6.01: status: { DRDY }
Apr 28 21:17:55 kernel: [268207.979883] ata6.01: failed command: WRITE FPDMA QUEUED
Apr 28 21:17:55 kernel: [268207.985198] ata6.01: cmd 61/f0:50:70:7f:b9/01:00:34:00:00/40 tag 10 ncq 253952 out
Apr 28 21:17:55 kernel: [268207.985202]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Apr 28 21:17:55 kernel: [268208.000745] ata6.01: status: { DRDY }

So sieht's im Log aus.
Und so im DMESG:

[89809.987278] ata6.03: SATA link down (SStatus 0 SControl 320)
[89809.996839] ata6.04: hard resetting link
[89810.329244] ata6.04: SATA link down (SStatus 0 SControl 320)
[89810.348492] ata6.00: configured for UDMA/133
[89810.368762] ata6.01: configured for UDMA/133
[89810.375434] ata6.00: device reported invalid CHS sector 0
[89810.381530] ata6.00: device reported invalid CHS sector 0
[89810.387328] ata6.00: device reported invalid CHS sector 0
[89810.392938] ata6.00: device reported invalid CHS sector 0
[89810.398465] ata6.00: device reported invalid CHS sector 0
[89810.404028] ata6.00: device reported invalid CHS sector 0
[89810.409475] ata6.00: device reported invalid CHS sector 0
[89810.414877] ata6.00: device reported invalid CHS sector 0
[89810.420280] ata6.00: device reported invalid CHS sector 0
[89810.425675] ata6.00: device reported invalid CHS sector 0
[89810.431071] ata6.00: device reported invalid CHS sector 0
[89810.436467] ata6.00: device reported invalid CHS sector 0
[89810.441906] ata6: EH complete
[91460.175828] ata6.00: failed to read SCR 1 (Emask=0x40)
[91460.181108] ata6.01: failed to read SCR 1 (Emask=0x40)
[91460.186380] ata6.02: failed to read SCR 1 (Emask=0x40)
[91460.191670] ata6.03: failed to read SCR 1 (Emask=0x40)
[91460.196891] ata6.04: failed to read SCR 1 (Emask=0x40)

Nun mein Problem.
Wenn ich das Log richtig interpretiere, hat die Platte an ata6.00 einen Fehler. Nur welche ist es hardwaremässig?
Ich habe ein DS413 mit einem DX213 dran. Meine "Vermutung" ist, dass es eine aus dem DX213 ist... Wie kann ich diese identifizieren?

 

[süno42]

[89810.409475] ata6.00: device reported invalid CHS sector 0

Ich würde nicht sofort von einem Hardwarefehler der Festplatte ausgehen. Die Logdatei zeigt keinen Schreib-/Lesefehler an, sondern dokumentiert Adressierungsprobleme bzgl. Sektor 0. Eventuell kommt hier auch ein Kernel- oder Treiberfehler in Betracht. Ursache kann eventuell ein sogenannter "Off-by-One-Fehler" sein. Hast Du die Meldung mal bei einer Suchmaschine Deines Vertrauens eingegeben?


Viele Grüße
Süno42

 

[hakiri]

Danke für Dein Post.
Laut Google schreiben viele, dass die Platte einen Weg hat.
Gestern habe ich nochmal genau analysiert und beim Boot konnte ich nachvollziehen, dass ATA6 die DX213 ist.
Kurioserweise machte gestern die 2. Festplatte also ATA6.01 laut Log Probleme.
Getestet habe ich außerdem das Kopieren von Daten (60GB) von Volum21 (DS413 mit Raid5) auf die beiden Volumes (2+3) in der DX213 und beim Schreiben auf die DX213 kamen reproduzierbar immer die Fehler im Log.
Da es diesmal, wie gesagt die andere Platte ist, werde ich das Gefühl nicht los, dass es vielleicht an der ganzen DX213 liegen könnte. Ich habe gestern mit den Informationen an Synology geschrieben.

 

[süno42]

Danke für Dein Post.
Laut Google schreiben viele, dass die Platte einen Weg hat.

Das kann ich mir gut vorstellen. Das ließt man häufig. Das liegt vermutlich daran, daß nur wenige Leute einen Softwarefehler vermuten und sich mit einer Voreinstellung oder eigenen Vermutung auf die Suche bei Google begeben, um sich dann die Bestätigung ihrer eigenen Vermutung abzuholen. Ob die Vermutung richtig oder falsch war, ist spätestens ab diesem Punkt nebensächlich. Was ich damit sagen will, nicht wenige Meldungen bei Google basieren auf subjektiv empfundenen Vorfällen. Ich lasse bei der Interpretation solcher Meldungen immer noch eine gesunde Portion Skepsis mit einfließen, was sich in der Vergangenheit auch bewährt hat. Zudem lassen sich Festplattenfehler meist immer noch mit Verschleiß begründen, Softwarefehler dagegen nicht.

Berücksichtige, meine Vermutung muß auch nicht in Stein gemeißelt sein, bloß grabe ich meist noch immer etwas tiefer nach den Ursachen, und jeder läßt zudem noch seien Erfahrungen einfließen.

Du kannst beispielsweise noch andere Quellen anzapfen. Foren von Linuxdistributionen oder http://bugzilla.kernel.org

 

[hakiri]

Ich werde die Ansätze berücksichtigen.
Parallel hat mir der Synology Support geantwortet:
Ich soll die Platten unter Windows mit dem Diag-Tool testen, was es vom Hersteller gibt. Falls keine Fehler auftreten, soll die DX213 defekt sein und via RMA ausgetauscht werden.
hmm... kann mir nur schwer vorstellen, dass die DX einen weg hat.

 

[hakiri]

Nochmal ein Update für die Interessierten:
- beide Platten in der DX213 laut SMART und Seagate Tool Check fehlerfrei
- Habe nun nur noch eine Platte drin und sobald das System Last bekommt kommt der Fehler wieder.
Das Interessante ist, dass nach einem Reboot wieder normal auf die Platte zugegriffen werden kann. Ansonsten kommen zig Fehler in's Log und i/o zieht das System laut top derbe runter.
Für mich klingt das langsam auch immer mehr nach einem Kernel Bug. Dennoch werde ich nun die Platte, welche noch in der DX verbaut ist, gegen eine andere wechseln und das System unter Last setzen. Tritt der Fehler wieder auf, melde ich mich wieder bei Synology. Ein Hardware-Defekt der DX213 selbst halte ich für relativ unwahrscheinlich.


Nachtrag: Beim Durchforsten des Forums ist mir dieser Beitrag aufgefallen. Offensichtlich kann ich also einen Hardware Defekt nicht ausschliessen

 

[hakiri]

Und noch mehr Infos...
Ich habe die DX213 inzwischen getauscht und der Fehler besteht unverändert.
Der Support scheint an der Stelle deutlich überfordert zu sein.
Die Festplatten habe ich auf Anweisungen vom Support schon getauscht und einzeln getestet in der DX und DS - die Platten kann ich IMHO ausschliessen.
Das neue Gerät hatte ein neues SATA Kabel.
Nun will mir der Support weismachen, dass NUR die Platten aus der Compability Liste laufen. Allerdings gibts beim Suchen im Forum User mit dem gleichen Problem, die Platten aus dieser Liste einsetzen.
Jetzt schlägt mir der Support vor, ich möge doch auch noch die DS413 tauschen, da eventuell der eSata Anschluß defekt ist. Sorry, funktioniert mit einer einzelnen Platte einwandfrei und da der Bug im Log für mich immer reproduzierbar ist, schliesse ich auch hier einen Hardware-Fehler aus.
Ich bin echt SEHR enttäuscht und überlege nun, mich mal an heise oder hardwareluxx zu wenden, und zu bitten, dass die mit einem gleichen Test-Setup das ganze mal ausprobieren. Vielleicht hört der Support denen ja besser zu als mir.

 

[süno42]

Auch wenn es Dir nicht hilft, auch ich bin von dem Support nicht wirklich überzeugt. Geht es über 0815-Probleme kann der Support oftmals nicht weiterhelfen. Hast Du dem Support schon Links auf ähnliche über die Suchmaschine gefundene Problemschilderungen geschickt?

Laß Dich mit diesem Kompatibilitätsaussagen nicht abspeisen.

 

[hakiri]

Nachdem ich gefragt habe, ob es nützt, wenn ich mich mit dem Problem an heise.de oder hardwareluxx.com wende, damit die das Problem für mich nachvollziehen und sich dann direkt mit Synology auseinander setzen könnten, haben sie um mehr Zeit gebeten.
Ich bin noch on Hold.
Links zu anderen Usern habe ich ihnen geschickt. Antworten sind aber immer ausweichend. Hardware-Problem halt... klingt für mich auch etwas nach Zeit schinden.

 

[süno42]

Hi,

wann tritt das Problem noch mal genau auf, nur nach dem Systemruhezustand oder auch direkt nach dem Hochfahren?

Ich habe mir die Meldung mal angeschaut. Wie vermutet tauchen irgendwie widersprüchliche Informationen im ATA-Taskfile des Kernels auf. Die Funktion identifiziert hier eine klassische CHS-Adressierung (warum auch immer), da das LBA-Flag nicht gesetzt ist. Weiterhin erfolgt gleichzeitig eine Adressierung des Sektors 0, was bei CHS nicht erlaubt ist. Hier werden Sektoren grundsätzlich ab eins gezählt.

Voraus gehen dem Fehler Probleme beim Lesen der SATA Status-Registers. Probier mal, ob eventuell eine Abschaltung von NQC etwas bringt. Hierzu einfach mal folgendes probieren:

echo 1 > /sys/block/[b]sdX[/b]/device/queue_depth

sdX durch die richtige Platte (sda, sdb, …) ersetzen. und natürlich vorher BACKUP NICHT VERGESSEN.


Viele Grüße,
Süno42

 

[hakiri]

Hi Süno,

unabhängig vom Ruhezustand lässt sich das Problem folgendermaßen Reproduzieren:
Auf einer der DX's Festplatten folgendes ausführen

dd if=/dev/zero of=myBigFile.dat bs=50M count=500

und in einer weiteren shell:

cp myBigFile.dat myBigFile.dat2

Der Fehler tritt also auf, wenn sowohl read als auch write operationen zugleich auftreten. Dies aber auch nur sporadisch. Eben z.B. nach knapp 15 Minuten.

Cool, dass Du dich bis auf Kernel Ebene mit der Thematik befasst hast. Mit dem NCQ Bug habe ich mich allerdings auch schon befasst und muss Dir leider sagen, dass das Setzen der Queue auf 1 leider keine Abhilfe schafft
Allerdings bin ich nicht über den Kernel an die Thematik rangegangen, sondern über die Hardware.
Der DX hat den Sil3726 als Portmultiplikator. Über google findet man generelle Fehler und Lösungsansätze zu diesem Chip. u.A. wird halt häufig das NCQ thematisiert.