# Merkwürdiges Problem mit 3TB-HDDs (hard resetting link)

## doedel

Hi,

ich habe hier 4 Stück ganz neue 3TB Platten von Seagate (ST3000DM001). In meinem grossen Rechner sollten die an einen 3Ware Raid Controller.

Der Controller: 3ware Inc 9650SE SATA-II RAID PCIe. Egal ob ich die Platten am Controller habe oder auf dem onboard JMicron Fake-Raid-Controller (JMicron Technology Corp. JMB363 SATA/IDE Controller), bekomme ich diese Fehler, oft schon beim mounten:

```

[   85.670403] ata6.01: exception Emask 0x10 SAct 0x0 SErr 0x400101 action 0x0

[   85.670409] ata6.01: SError: { RecovData UnrecovData Handshk }

[   85.670413] ata6.01: failed command: WRITE DMA EXT

[   85.670420] ata6.01: cmd 35/00:00:00:f9:80/00:04:00:00:00/f0 tag 0 dma 524288 out

[   85.670420]          res 51/84:00:c0:6c:c5/84:02:00:00:00/f0 Emask 0x30 (host bus error)

[   85.670425] ata6.01: status: { DRDY ERR }

[   85.670428] ata6.01: error: { ICRC ABRT }

[   85.670436] ata6.00: hard resetting link

[   85.988015] ata6.01: hard resetting link

[   86.464062] ata6.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   86.464076] ata6.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[   86.512354] ata6.00: configured for UDMA/133

[   86.528349] ata6.01: configured for UDMA/133

[   86.528360] ata6: EH complete

[   86.528830] ata6.01: exception Emask 0x10 SAct 0x0 SErr 0x400100 action 0x0

[   86.528835] ata6.01: SError: { UnrecovData Handshk }

[   86.528839] ata6.01: failed command: WRITE DMA EXT

[   86.528846] ata6.01: cmd 35/00:00:00:f9:80/00:04:00:00:00/f0 tag 0 dma 524288 out

[   86.528846]          res 51/84:81:3f:6b:c5/84:03:00:00:00/f0 Emask 0x30 (host bus error)

[   86.528850] ata6.01: status: { DRDY ERR }

[   86.528853] ata6.01: error: { ICRC ABRT }

[   86.528861] ata6.00: hard resetting link

[   86.848016] ata6.01: hard resetting link

```

Wenn die Platten im Raid Modus (egal ob 0, 1 oder 5) auf dem 3Ware betreibe habe ich diese Fehler nicht. Nur mit Fakeraid oder wenn ich die Platten einzeln anspreche.

Daten, die ich zu Anfangs drauf geschrieben habe (ca. 1200GB) liessen sich Problemlos und Fehlerfrei wieder von der Platte holen, nur ist da mein dmesg dann total zugespammt gewesen. So habe ich das überhaupt erst bemerkt.

Kernel ist gentoo-source-3.8.13, eine Knoppix und eine Suse Live CD, überall der selbe Fehler.

Kann mir jemand vielleicht was genaueres dazu sagen? Was genau diese Meldung bedeuted, was da schief ging?

----------

## py-ro

Tausch mal das Kabel aus oder den Wechselrahmen, falls einer verwendet wird.

Das du die Meldung nicht bekommst, wenn Sie am RAID-Controller bekommst, liegt daran, dass dieser sich selber darum kümmert.

Py

----------

## doedel

Ich habs jetzt mit 8 verschiedenen Kabeln in 8 verschiedenen Einschüben im Gehäuse versucht und dann die Platten direkt ohne die Einschübe ans Kabel angeschlossen. Dass alle 8 Kabel defekt sind, dachte ich dann zuerst und habe ein SATA Kabel aus einem anderen Rechner genommen, das 100%ig funktioniert, aber da war der selbe Fehler.

Ich weiss nicht mehr weiter, sehr nervige Sache...

Der RAID-Controller kommt generell mit 3TB Platten klar, ich habe zwei 3TB WD vorher drin gehabt, die liefen monatelang Problemlos. 4 750GB Seagate habe ich auch noch hier, die laufen auch problemlos.

----------

## Jean-Paul

Hi,

ich hatte ziemlich genau vor einem Jahr einen ähnlichen Fehler in der dmesg - allerdings mit einer anderen Distri.

 *Quote:*   

> [36.078239] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
> 
> [   36.078323] ata1: irq_stat 0x00400040, connection status changed
> 
> [   36.078393] ata1: hard resetting link
> ...

 

Das war aber in Verbindung mit einer SSD, die aber auch an einem jMicron-Controller hing. Die SSD hat einwandfrei funktioniert, Datenverluste hatte ich auch keine.

Habe mir damals fast einen Wolf gegooglet und herausgefunden, dass es mit JMicron zusammenhängt jedoch harmlos ist.

Dieser Fehler war harmlos, deiner sieht etwas anders aus.

Jedenfalls verschwand der Fehler plötzlich wieder. Entweder hatte ich ein Kabel gewechselt, einen neuen Kernel eingespielt oder e2fsprogs aktuallisiert - oder eine Kombination davon. Der Fehler war jedenfalls weg.

Das hilft dir warscheinlich nicht direkt.

Eine Suche nach "failed command: WRITE DMA EXT" oder "SError: { RecovData UnrecovData Handshk }" in der Suchmaschine deiner Wahl, bringt aber schon einige Ergebnisse.

Jean-Paul

----------

## kernelOfTruth

jo, hatte heute auch wieder die Ehre

mit dem externen JMicron eSATA-Port & einer WD Red, kernel 3.9.3

das ist so schlimm geworden, dass ich keine Daten draufkopieren konnte & es ab jetzt wieder mit 3.8.13 versuchen werde,

damit ging es scheinbar besser

das ist von Platte zu Platte, Chipsatz zu Chipsatz und kernel zu kernel unterschiedlich   :Sad: 

häufig hängt damit Folgendes zusammen (haben sicher einige von euch auch schon beobachtet):

sobald man größere Mengen auf die Platte kopiert oder den SATA-Anschluss einigermaßen voll ausreizt (3 Gbps statt 1.5 Gbps)

streikt das Teil

----------

## doedel

Ich hab jetzt verschiedene Distributionen ausprobiert, verschiedene Kernel. Immer das selbe Problem.

Den onboard JMicron hab ich in IDE Mode versetzt, AHCI und Raid. Dort dran versucht, am 3ware RAID Controller versucht.

Die Platten auf einem anderen Board (ebenfalls der selbe JMicron controller, aber anderes Board) versucht, dort besteht das Problem ebenfalls.

Auf meiner Workstation (Phenom II), ebenfalls JMicron aber anderer, hab ich das Problem nicht, genauso wie an verschiedenen USB-SATA Adaptern.

Ich vermute ich werde das Board im grossen tauschen müssen und mir aber auf jeden Fall neue, andere, 3TB Platten holen - das Risiko, dass da doch was spinnt ist zu gross. Es darf nur eine ausfallen, dass alle Daten immer noch vorhanden sind...

Jetzt werkelt das alte RAID wieder, ich wollts doch loswerden ...  :Wink: 

Danke für eure Tipps. Ich tippe auf den JMicron oder das Board an sich als Übeltäter.

PS: Ein Windows könnte ich zum Testen auf der Kiste noch installieren, gibts dort vielleicht eine Möglichkeit an die Fehlermeldungen wie hier im Linux zu kommen, nur um's einfach mal zu testen?

----------

## kernelOfTruth

ich dachte, ich hätte den Link zum passenden Blog/Artikel gepostet, dem ist anscheinend nicht so:

http://paul.sullivan.za.org/kernel-disables-sata-drive-under-heavy-load-action-0x6-frozen/

https://bugzilla.redhat.com/show_bug.cgi?id=549981

das ist  eine Variante davon, die ich mit einer Seagate Platte + Jmicron Controller schon erlebt hatte

aktuell mit JMicron Controller & anderer Platte von WD tritt aber was ähnliches auf: ziemlich am Anfang nach dem Anschließen & zu Beginn des Transfers fällt die Platte aus bzw wird resettet:

http://pastebin.com/0uB6E85F

mit anderen Controllern scheint es auch aufzutreten, was genau es verursacht weiß ich in meinem Fall leider noch nicht

----------

## Jean-Paul

 *Quote:*   

> end_request: I/O error, dev sde, sector 3054780160

  Das könnte darauf hindeuten, dass sich deine Platte verabschiedet. Ein fsck würde warscheinlich eine Menge Fehler bringen.

Ich vermute, dass du als Folge davon die Kernel-OOPS bekommst.

 *Quote:*   

> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"

  Dies deutet auf zu viele geöffnete Files hin, ausgelöst durch die IO errors.

 *Quote:*   

> ulimit -n

  zeigt dir an, wieviel Files geöffnet sein können (kann auf 65K erhöht werden)

 *Quote:*   

> txg_sync        D ffff88023fcd3180     0 10236      2 0x00000000

  Beim alloc von Speicher bei ZFS (ist das Filesystem ZFS ?) abwechselnd mit rsync (weiter unten).

 *Quote:*   

> ziemlich am Anfang nach dem Anschließen & zu Beginn des Transfers fällt die Platte aus bzw wird resettet

  Hatte ich auch mal, dann war es das Netzteil.

 *Quote:*   

> mit anderen Controllern scheint es auch aufzutreten

  Das deutet darauf hin, dass es nicht der Jmicron ist.

Insgesamt ist das ein sehr schwer zu debug'ender Fehler um den ich dich nicht beneide.

Wenn die Daten wertvoll genug sind um gesichert zu werden, würde ich dies tun, dann die Platte komplett platt machen und testen.

Jean-Paul

----------

## doedel

Bei mir schienen die Platten vollkommen in Ordnung zu sein. Ein fsck lief auf Problemlos durch.

Ich habs jetzt anders gelöst, andere Platten rein, damit scheints zu laufen. Mir is das einfach zu wackelig gewesen. 

Ich bau mir kein RAID um dann zwischen den Backups immer bangen zu müssen. Platten sind zwar immer noch keine Ramschware, aber bei 120 Euro für eine 3TB WD RED ist das doch mal zu verschmerzen. Die Seagate waren halt nochmal 40 Euro billiger pro Platte, scheint wohl doch noch mit dem Preis zusammen hängen  :Wink:   :Wink:   :Wink: 

Alles in allem bin ich jetzt ganz froh mit der Kombi. Der Xeon kostet nicht mehr viel und hat ordentlich Dampf, der 3Ware ist zwar kein Schnäppchen aber für den Preis vollkommen in Ordnung und die Platten taugen jetzt anscheinend auch. 

Ich hab sie zum Testen erstmal am onboard-Controller laufen lassen, durch den 3ware durch bekomme ich ja keine Meldungen. Da ist aber die ganze Zeit über gar nichts aufgetaucht. 

Und in einem Jahr gibts neue Platten fürs RAID und ich hab 4x 3TB zum Basteln über  :Smile: 

Ach wie schön, dass wir nicht mehr in Zeiten von VAXen und Tapes leben  :Wink: 

----------

## schmidicom

 *doedel wrote:*   

> Ach wie schön, dass wir nicht mehr in Zeiten von VAXen und Tapes leben 

 Wieso, gab es damals mehr/weniger Probleme?

Im Beriech Raidcontroller und Fehlermeldungen habe ich auch schon einiges erlebt. In meinem Fall mit einem externen Transtec RAID-Controller der über SCSI an zwei identische Server angeschlossen ist von denen der eine mit Gentoo und der andere mit Windows betrieben wird. Aber auch da gibt der Transtec nur die HDD-Fehler weiter die er selbst für relevant hält oder per Konfiguration dazu gezwungen wird.

----------

## doedel

 *schmidicom wrote:*   

>  *doedel wrote:*   Ach wie schön, dass wir nicht mehr in Zeiten von VAXen und Tapes leben  Wieso, gab es damals mehr/weniger Probleme?

 

Nein das nicht, aber heute gibt es ein vielfaches an Speicherplatz für einen Bruchteil der Kosten.

Das Problem scheinen RAID-Controller im Allgemeinen zu haben. Ich hab heute mal auf Arbeit zwei wirklich kaputte Platten an neuen Adaptec gehangen, dort hat sich die LED gemeldet und er hat neuen Platte für Rebuild gefordert, aber was genau los sei hab ich durch den Controller nicht mitbekommen.

----------

