Neue Samsung 2TB HD204UI Firmware-Patch nötig?

[Flava89]

Hey,
weiß jemand, ob die aktuellen HD204UI Festplatten den Patch brauchen? Samsung-Patch

Habe in diversen Foren gelesen, dass alle HDD's die nach januar2011 gefertigt wurden schon geupdated sind.

 

[domainhost]

hab mir die platte jetz au geholt, das wüsst ich auch gern

 

[MTechlerin]

Schau auf deinen Auf den Aufkleber deiner HDD hat sie Firmware: "F4EG" drauf stehen brauch sie es nicht.
Alternativ Firmware der HDD feststellen wenn nicht eindeutig auf HDD: CrystalDiskInfo
Betrifft alle Samsung Festplatten der reihen:
HD204UI,
HD204UI/Z4,
HD204UI/UZ4,
HD155UI,
HD155UI/Z4,
HD155UI/UZ4

 

[Flava89]

Schau auf deinen Auf den Aufkleber deiner HDD hat sie Firmware: "F4EG" drauf stehen brauch sie es nicht.

Betrifft alle Samsung Festplatten der reihen:
HD204UI,
HD204UI/Z4,
HD204UI/UZ4,
HD155UI,
HD155UI/Z4,
HD155UI/UZ4

sry, aber auf dem Aufkleber steht keine Firmwareversion.

 

[mastor]

es steht bei dir nicht drauf und du hast die reihe die betroffen ist, also brauchst du es wohl

 

[Flava89]

es steht bei dir nicht drauf und du hast die reihe die betroffen ist, also brauchst du es wohl

ja ok, aber haben die es nicht auf die Reihe gebracht, die neueren Laufwerke selber zu flashen?

Man kann ja an der Firmware nicht erkennen, ob es die Neue ist... so ein Mist.... vor allem für Mac-User...

 

[MTechlerin]

Firmware der HDD feststellen wenn nicht eindeutig auf HDD: CrystalDiskInfo

 

[Rick_Danger]

Firmware kannst Du nicht identifizieren, da die fehlerhafte und die "Neue" die gleiche Bezeichnung tragen. Da Deine Platte aber in 7/2011 gefertigt wurde, ist die "Neue" schon drauf. Musst nichts machen.

 

[Madnex]

Schau auf deinen Auf den Aufkleber deiner HDD hat sie Firmware: "F4EG" drauf stehen brauch sie es nicht.

Woher hast du das denn? F4EG ist einfach nur die Abkürzung der Serienbezeichnung und hat nichts mit der Firmwareversion zu tun.

@Flava89
Alle F4EG Platten, die ab Dezember 2010 produziert wurden, haben den Patch bereits ab Werk drauf und müssen nicht aktualisiert werden. Deine Platte ist brandneu und wurde im Juli 2011 hergestellt.

 

[wfgdd]

Sorry, das ich den hier ausgrabe - aber ich habe eine entsprechende Platte, müsste von Herbst 2010 und damit betroffen sein. Leider ist sie in einem externen Gehäuse verbaut, deshalb kann ich die Seriennummer nicht lesen und Seagate lässt einen somit nicht auf die Downloads zugreifen. die links zur Samsung-Seite werden alle auf die Hauptseite von Seagate geleitet.....

Gehen beim Update eigentlich die Daten verloren?!

Edit: Unter den Firmware-Updates listet Seagate die Platte nicht einmal:
http://knowledge.seagate.com/articles/en_US/FAQ/207931en

Samsung fand ich toll, aber jetzt kommen meine Platten wohl bald nur noch von WD - aber das gehört jetzt nicht hier hin .

 

[Ernst@at]

Leider ist sie in einem externen Gehäuse verbaut, deshalb kann ich die Seriennummer nicht lesen

Dazu gibt es CrystalDiskInfo - Zeigt Type, Seriennummer und Firmwareversion.
Wenn die externe nur eine USB-Schnittstelle hat, kannst Du ohne Ausbau sowieso kein Firmwareupdate machen.
Ansonsten ist das auch nicht weiter schlimm, solange Du bei der Verwendung der externen Platte während des Schreibens darauf keine Plattentools wie CDI oder HDTune oder andere SMART-Anzeigeprogramme anwirfst - denn nur in dieser Kombination (Schreiben+Diagnostiktool) kann eine Fehlfunktion auftreten.

Außerdem sollten alle wichtigen Daten sowieso woanders nochmals vorhanden sein, es ist also Jacke wie Hose, ob wegen dieses Fehlers Datenverlust eintritt oder weil sie Dir vom Tisch fällt.

 

[wfgdd]

Hmmm, CDI zeigt die Platte gar nicht an - vermutlich, weil es eine eSATA ist?!

 

[Ernst@at]

Was ist das für ein Board, bzw. von welchem Controller wird der eSATA-Port bedient?
Das klingt sehr nach NVIDIA-Murks ohne aktuelle Treiber oder älterer Bauart
CDI hat allerdings auch bei Samsungs der betroffenen Modelle eine Sperre.
(in neuen Versionen unter "Optionen -> Workaround" das Häkchen bei "[Firmware Bug] SAMSUNG HD155UI/HD204UI" entfernen)

 

[Madnex]

@wfgdd
Das Firmware-Update kannst du auch über meine Homepage beziehen: klick!

Wenn die externe nur eine USB-Schnittstelle hat, kannst Du ohne Ausbau sowieso kein Firmwareupdate machen.
Ansonsten ist das auch nicht weiter schlimm, solange Du bei der Verwendung der externen Platte während des Schreibens darauf keine Plattentools wie CDI oder HDTune oder andere SMART-Anzeigeprogramme anwirfst - denn nur in dieser Kombination (Schreiben+Diagnostiktool) kann eine Fehlfunktion auftreten.

Wenn die Platte extern ausschließlich per USB angeschlossen ist, braucht man den Firmware-Patch nicht unbedingt aufspielen, da der Fehler nur in Verbindung mit NCQ passiert. Über USB ist NCQ nicht aktiv.

Davon abgesehen hat der Firmware-Bug nichts mit Smart zu tun. Das sind Fehlinformationen der ersten Stunde, die durch News-Meldungen verbreitet wurden, denen wohl auch der Autor von CDI aufgesessen ist. Denn CDI soll den entsprechenden ATA-Befehl gar nicht verwenden.

 

[Ernst@at]

Meines Wissens wurde im Falle von abgesetzten "Identify Device" Commands (ID) der Write-Cache korrumpiert.
Warum daher über USB nicht möglich, kann ich nicht nachvollziehen, da nach Abschluss des Datentransfers eines Writes ein ID zur Durchführung kommen kann, noch bevor die Daten auf der Oberfläche in Sicherheit sind.
CDI benutzt sehr wohl ID, serial/firmware revision/sectorsize usw wird damit erhoben; der komplette zurückgegebene Datensatz ist im Detail-Log an/abwählbar.
Es hat zwar nichts mit SMART direkt zu tun, aber da die meisten Tools diese Zusatzinformationen ebenso erheben, verwenden sie auch den ID-Befehl.

 

[Madnex]

Warum daher über USB nicht möglich, kann ich nicht nachvollziehen, da nach Abschluss des Datentransfers eines Writes ein ID zur Durchführung kommen kann, noch bevor die Daten auf der Oberfläche in Sicherheit sind.

Da das nur passieren kann, wenn NCQ genutzt wird. Über USB ist meines Wissens NCQ nicht aktiv und somit kann es keine Korrumpierung geben.

CDI benutzt sehr wohl ID, serial/firmware revision/sectorsize usw wird damit erhoben; der komplette zurückgegebene Datensatz ist im Detail-Log an/abwählbar.
Es hat zwar nichts mit SMART direkt zu tun, aber da die meisten Tools diese Zusatzinformationen ebenso erheben, verwenden sie auch den ID-Befehl.

Laut der c't stören z.B. Crystal Disk Info und HDD-Health die Platte in ihren Versuchen nicht. Wie die die Informationen abrufen, kann ich dir leider nicht sagen. Ich bin kein Programmierer. Möglich ist natürlich auch, dass die c't da was falsch interpretiert hat, da sie Schlüsse aus eigenen Tests (Versuche, um den Fehler zu reproduzieren) gezogen haben. Quelle: klick!

Zitat c't: "Mittlerweile hat sich herausgestellt, dass nicht etwa SMART-Abfragen die Festplatte zu dem Fehler veranlassen, sondern der ATA-Befehl "IDENTIFY DEVICE". Diesen sendet nicht nur der Aufruf "smartmontools -a" an die Platte, sondern unter Linux etwa auch "hdparm -I". Nach Experimenten im c't-Labor können auch die SeaTools for Windows des Festplattenherstellers Seagate den Fehler bei der Samsung-Platte hervorrufen. Andere Festplatten-Utilities wie CrystalDiskInfo oder HDD Health störten die Samsung-Platte in unseren Versuchen hingegen nicht."

 

[Ernst@at]

Da das nur passieren kann, wenn NCQ genutzt wird. Über USB ist meines Wissens NCQ nicht aktiv und somit kann es keine Korrumpierung geben.

Wer das herausgefunden zu haben glaubt, wäre interessant.
Ein USB Controller supported kein NCQ, das ist klar.

Durch das Queueing ist die Device in der Lage, trotz Abarbeitung bereits empfangener Befehle weitere anzunehmen. Auch ID, welche sich mit Writes in speziellen Konstellationen nicht vertragen (so die Bugbeschreibung). Daher wird der Fehler hier häufiger auftreten

Wenn allerdings ein Write seinen Datentransfer an die HDD beendet hat(bei eingeschaltetem Write-Caching), ist für das System der I/O abgeschlossen kann daher auch über USB den ID Befehl an die HDD schicken, bevor diese das Write auf die Oberfläche beendet hat.

Daher könnte der Bug nach meiner Vorstellungskraft auch hier, allerdings weniger häufig, auftreten.
Ob das wer mit der Linux-Verifizierung auch per USB getestet hat, entzieht sich meiner Kenntnis; ob es triftige gegenteilige Argumente gibt, warum es per USB nicht auftreten kann, ebenso. Bei den vielen herumschwirrenden technischen Latrinengerüchten übernehme ich es durch die bloße Behauptung von irgendwo (nix gegen Dich ) erstmal nicht zur Weiterverbreitung.

 

[Madnex]

Die offizielle Beschreibung dieses Bugs von Samsung/Seagate lautet: "If the host issues an identify command during an action of writing data in NCQ, the data's writing can be destabilized, and can lead to data loss."

Was liest du daraus?

Auf dieser Seite schreibt der Entwickler der Smartmontools folgendes:

"The problem could not be reproduced with the above test if any of the following conditions are met:

• Disk write cache is disabled.
  
• NCQ is disabled. This may not always be true as the c't lab also reported problems with NCQ disabled.
  
• A modified test version of smartctl which does not issue IDENTIFY DEVICE commands is used. Then all other SMART and non-SMART commands used by smartctl work without any data loss.
  
• The disk is replaced by another model (tested with Samsung HE103UJ and Seagate ST31000524NS)."

Bezüglich "This may not always be true as the c't lab also reported problems with NCQ disabled.". Das wird wohl nur intern zwischen der c't und dem Smartmontools-Entwickler kommuniziert worden sein. Denn offiziell hat das die c't weder in irgendeiner News noch in irgendeinem Heft-Artikel geschrieben. Wobei ich dem Smartmontools-Entwickler mehr Know-How zutraue als den c't-Redakteuren.

Aber ich gebe dir Recht. Um sicher zu gehen, dass das wirklich so ist, müsste man es selbst testen. Hast du noch eine ungepatchte F4 im Schrank, die vor Dezember 2010 produziert wurde, oder kennst du jemanden? Im Zweifel sollte man wohl wirklich auf Nummer sicher gehen und auch per USB angeschlossene Festplatten patchen.

 

[wfgdd]

lag an dem CDI-Workaround, dass sie nicht zu lesen war!

finde es trotzdem lächerlich, dass man beim Download von Firmware/Treibern/Diagnostiktools die Seriennummer angeben muss. (außer einzeln um für ein bestimmtest Update die Notwendigkeit ggf zu prüfen)

würde man die Beschädigung eigentlich merken? Also beim Schreiben noch oder erst beim lesen, und bei letzterem wegen CRC-Fehler o.ä. oder nur, wenn man die Datei tatsächlich öffnet und dann z.B. die Wiedergabe des Videos einfriert?!

lg

 

[Ernst@at]

Nachdem Seagate-Bugs meist auf Herstellungschargen/Seriennummernkreise beschränkt waren, hat man die Notwendigkeit für ein Firmwareupdate daraus abgeleitet (damit man nicht das falsche erwischt, weil es so viele gab ). Nach der Übernahme wird das jetzt auch bei Samsungs praktiziert. Vorausgesetzt, die Kerle wissen, wie lange sie den Bug auf welchen Seriennummern ausgeliefert haben, wäre das ja eine prima Testmöglichkeit, ob man betroffen ist, da die Pappnasen ja den Fix ohne Änderung der Revision-Nr. vorgenommen haben (worüber man als Techniker nur fassungslos den Kopf schütteln kann)


CRCs werden erst beim Schreibvorgang generiert, wenn da jetzt was falsches oder gar nichts auf einige Sektoren geschrieben wird, merkt man das weder beim Schreiben noch beim Lesen.
Je nachdem, wo der Fehler generiert wird, sind auch die Auswirkungen verschieden -
Dropouts bei Videos oder Musikdateien, Streifen in Bildern, Fehler beim Öffnen von Textdokumenten, Prüfsummenfehler bei .zip oder .rar entpacken . Schlimmstenfalls auch korrupte Verzeichniseinträge, die per chkdsk repariert werden müssen, wenn es dabei passiert ist.