SiL3512 SATA-Controler detached wärend Schreibvorgang 2TB-Platte

Wasp

Insektenspray-Gegner
Hallo Forum,

nach längerer Problemarmut habe ich endlich mal wieder ein anständiges und vor allem bis dato nicht verläßlich reproduzierbares Problem. :mad:

Nach Bereits langwirigem Ärger mit einem anderen Chipsatz in Zusammenhang mit 2TB Festplatten nun als Austausch vom Händler eine Karte mit SiL 3512 Chipsatz. Dieser soll nach Befragungen und Recherchen auf PCI-Karten als einfacher Controler zum erweitern mit SATA-Platten (ohne RAID oder ähnlichen schnick-schnack) gut laufen.

Leider muß ich jedoch feststellen, daß die Platte (WD20EARS) wärend des Betriebes von Controler einfach "detached" wird.
Code:
Jun 17 03:08:48 hel kernel: [B]subdisk6: detached[/B]
Jun 17 03:08:48 hel kernel: [B]ad6: detached[/B]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197958430720, length=131072)]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197958561792, length=131072)]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197958692864, length=131072)]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197958823936, length=131072)]
......................
Jun 17 03:08:48 hel kernel: GEOM_ELI: g_eli_read_done() failed ad6s1.eli[READ(offset=1260224647168, length=4096)]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1340055126016, length=32768)]
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1350918373376, length=32768)]
......................
Jun 17 03:08:48 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197280985088, length=32768)]
Jun 17 03:08:48 hel kernel: g_vfs_done():ad6s1.elie[WRITE(offset=98446802944, length=131072)]error = 6
Jun 17 03:08:48 hel kernel: g_vfs_done():ad6s1.elie[WRITE(offset=98446934016, length=131072)]error = 6
Jun 17 03:08:48 hel kernel: g_vfs_done():ad6s1.elie[WRITE(offset=98447065088, length=131072)]error = 6
......................
Jun 17 03:08:52 hel kernel: g_vfs_done():ad6s1.elie[WRITE(offset=98449620992, length=131072)]error = 6
Jun 17 03:08:52 hel kernel: GEOM_ELI: Crypto WRITE request failed (error=6). ad6s1.eli[WRITE(offset=1197961379840, length=131072)]
Jun 17 03:08:52 hel kernel: g_vfs_done():ad6s1.elie[WRITE(offset=98449752064, length=131072)]error = 6

Hardwarehintergrund:

Der SATA-PCI-Controler (Firma unbekannt, vermutlich EverTech):
Code:
# pciconf -lv |grep -A4 atapci0
atapci0@pci0:13:0:      class=0x010400 card=0x65121095 chip=0x35121095 rev=0x01 hdr=0x00
    vendor     = 'Silicon Image Inc (Was: CMD Technology Inc)'
    device     = 'Sil 3512 SATALink/SATARaid Controller'
    class      = mass storage
    subclass   = RAID

Die etwaige Problemplatte (Kennung ge-X-t)
Code:
# dmesg |grep ad6
ad6: 1907729MB <WDC WD20EARS-xxxxxx 80.00A80> at ata3-master SATA150

Vielleicht bin ich auf Grund der Probleme mit dem vorangegangen VT6421a Chipsatz voreingenommen, da dieser zumindest ähnliche Probleme mit einer solchen 2TB Platte hatte (Platte wurde vom Händler auch bereits ausgetauscht) und eben nicht mit der ebenso angeschlossenen 1TB-Festplatte (WD1000FYPS) hatte. Aber dieses Problem hatte ich eben auch noch nicht mit der 1TB-Platte am SiL-Chip. Wobei ich sagen muß, daß ich diese inzwischen vorsorglich nur noch als Read-Only einhänge.

System ist z.Z. FreeBSD 6.2-stable, mit dem ich auch sehr zufrieden bin. Vor einem Update aus reiner Hoffnung heraus ins Blaue hinein, würde mich eure Meinung/Hinweise zu anderen evtl. bereits bekannten Problemem interessieren.
Wasp
 
Zuletzt bearbeitet:

cla

Well-Known Member
Hm...nur eine Vermutung....ist das eine der WD-Festplatten, welche unter FreeBSD nach 5 Sekunden in Sleep-Modus verfällt und dann deshalb vom Controller rausgeworfen wird weil sie zu lange braucht um wieder hochzukommen?
WD hat nen Tool um diesen Timeout auszuschalten.

Oder anderer Gedanke: eine der neuen Platten mit 4k Sektorgröße was irgendwie oft auch noch Probleme macht...
 

Wasp

Insektenspray-Gegner
Es ist eine GreenPower Festplatte von WD, welche damit nach wohl 8s (?) den Kopf parkt. Ob sie dann zu langsam ist um wieder hoch zu kommen weiß ich nicht, kann ich mir aber ehrlich gesagt nicht vorstellen, da der Controler/FreeBSD die Platte während eines Schreibvorganges rauswirft. Die platte dürfte hier also garnicht parken. (Die letzten beiden Male bei dem Entpacken eines RAR-Archives passiert.)

In jedem Falle kann es nicht normal sein, daß der Controler/FreeBSD die Platte rausschmeißt, wärend ein anderes Programm versucht darauf zu schreiben. Den damit gibt es nicht mal mehr eine "Panic", sondern einfach ein komplettes Einfrieren des Systemes und autoamtischen Neustart.

Noch mal, um missverständnissen vorzubäugen: Mit "rauswerfen" bzw. "detach" meine ich nicht "umount" oder der gleichen, sondern "atacontrol detach". Dies dürfte ungefähr dem abziehen aller Kabel von der Festplatte während des Betriebes gleich kommen.

Da ich neben diesem Problem auch auf das Problem des zu häufige Parken des Kopfes stieß, welches, so zu seher hohen Load/Unload Cycles führt, kann ich sagen, daß es zwar so ein "Tool" zum "irgendwie umschalten"* dieses Timeouts gibt, allerdings nur für RE (=RAID Edition) Platten, zu denen meine eben nicht zählt.

Die Festplatte hat (auch :D )eine interne Sektorgröße von 4kB, doch sollte dies m.E. kein Problem darstellen, da der Controler auf der Fesplatte nach außen hin immer noch 512kB vorgibt, welche nur nach Innen auf 4kB übersetzt wird. Meines Wissens nach, wirkt sich dies im negativen Fall lediglich (minimal) auf die Schreibgeschwindigkeit aus, wenn die Blöcke über die Sektorgröße ragen. Aber wer da anderes zu berichten hat, kann mich gerne eines Besseren belehren.

Habe jetzt gerade mal die beiden Festplatte an den jeweils anderen Port des Controler gehangen. Jetzt warte ich wieder drauf, daß der Rechner abschmiert. :mad:

Für weitere oder weiterführende Ratschläge bzw. Hinweise wäre ich nach wie vor sehr Dankbar... :(
___________
* Leider verrät WD nicht, was das Firmwareupdate macht. Man weiß nur, daß man bei einer vorherigen Version einen Timeout selbst angeben konnte, bei der jetzigen "05" version allerdings nicht mehr. Ebenso ist das "Problem" nicht nur für RE sondern auch für GP Platten bekannt, aber wird nur für RE Festplatten offiziell behoben -- auch wenn ich zugeben muß, dass es im Kern eher ein FreeBSD/Linux Problem zu sein scheint, als eines seitens WD. Aber das ist eine andere Geschichte ...
 
Zuletzt bearbeitet:

Wasp

Insektenspray-Gegner
Ja klingt sehr ähnlich, aber die Ausgaben bzw. die Ergebnisse sehen zumindest leicht anders aus.
Code:
subdisk6: detached
ad6: detached
gegenüber
Code:
ad6:[b]FAILURE[/b] - device detached
Bei dem Bug-Report berichtet die Festplatte einen Fehler, bei mir allerdings detached sie einfach so (in zwei Schritten). "subdisk6" sagt mir leider garnichts.
... aber ich weiß es nicht, gibt ja bei dem Bug-Report keine Lösungsvorschläge oder gar Patches, als das ich irgendwas zur verifizierung ausprobieren könnte... :(

Vorschläge? Ideen? :confused:
 

Wasp

Insektenspray-Gegner
Hatte SATA-Ports der beiden Festplatten jetzt mal vertauscht und seit dem gibt es absolut keine Fehlermeldung mehr -- den/die Fehler allerdings schon :ugly:. Das System friert einfach ein und bootet sich nicht mal mehr von alleine neu, wie zuvor, sondern muß mit Reset neugestartet werden. (Fehler-)Meldungen sucht man nach dem Neustart (und fsck von run 3TB) auch vergebens. :(
 
Oben