SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 11]

[Dekal]

Ich hab jetzt mal die 1916W geflasht, bzw. ich habs versucht...

Und nun habe ich eine Yatapdong Barefoot...

Nen Schiebeschalter hat die SSD leider auch nicht, jedenfalls nichts von außen zugängliches. Gibts noch eine Chance auf Rettung der SSD? Ohne Garantieverlust, oder ist die eh schon futsch?

Versuchs mal hiermit, vielleicht hilft das dir ja genauso weiter wie mir:

http://www.hardwareluxx.de/community/f227/supertalent-fw-1916w-tun-nach-einem-fehlerhaften-flashvorgang-725059.html

 

[koaschten]

Normal bei destruktiven Updates.

1916w -> 2030 ist aber nicht destruktiv, zumindest hab ich kein Image wiederherstellen müssen

 

[Morpog]

@ Dekal

Bilderquote bitte entfernen!

1916w -> 2030 ist aber nicht destruktiv, zumindest hab ich kein Image wiederherstellen müssen

Ja, aber 1916W war destruktiv. Genau zu dem Zeitpunkt hast du deine SMART Daten verloren.

 

[DerRob]

Versuchs mal hiermit, vielleicht hilft das dir ja genauso weiter wie mir:

http://www.hardwareluxx.de/community/f227/supertalent-fw-1916w-tun-nach-einem-fehlerhaften-flashvorgang-725059.html

Kommt wieder genau das gleiche, er fängt wohl an zu flashen, der "Propeller" dreht sich ein paar mal, und dann kommt wieder die Meldung "debug assertion failure"...

 

[Morpog]

Im IDE oder AHCI Modus geflashed?

 

[DerRob]

Im IDE oder AHCI Modus geflashed?

Beim ersten und 2. Mal IDE-Compatible, dann AHCI-Native und eben nochmal IDE Native getestet, immer das gleiche... Ich werd die SSD jetzt mal mit nach Hause nehmen, und dort am Rechner ausprobieren.

Wenns da auch nicht geht, muss ich halt erstmal auf die Spiele-SSD zuhause verzichten, Vista auf einer alten 80GB-HD geht überhaupt nicht, das Ding rödelt immer erstmal sekundenlang rum, bevor sich was tut...

 

[Morpog]

Beim ersten und 2. Mal IDE-Compatible, dann AHCI-Native und eben nochmal IDE Native getestet, immer das gleiche... Ich werd die SSD jetzt mal mit nach Hause nehmen, und dort am Rechner ausprobieren.

Wenns da auch nicht geht, muss ich halt erstmal auf die Spiele-SSD zuhause verzichten, Vista auf einer alten 80GB-HD geht überhaupt nicht, das Ding rödelt immer erstmal sekundenlang rum, bevor sich was tut...

Du hast das aber jetzt nicht wirklich unter Vista gemacht?
Die Anleitung hast du schon gelesen?

 

[frief]

bei mir lieg tmp auf ramdisk
none /tmp tmpfs defaults,size=512M,mode=1777 0 0
none /var/tmp tmpfs defaults,size=256M,mode=1777 0 0

Danke. /var/tmp habe ich jetzt wie bei Dir angelegt.

kann auch sein, daß bei mir 1916 non-gc läuft. Beim update von 1916 gc auf 1916 non-gc gabs ungereimtheiten, bin mir deshalb nicht sicher was bei mir läuft. Das wearout hat sich nach dem "update" aber nicht geändert.

Hast Du/könntest Du eine /etc/cron.hourly/smartctl ähnlich meinem vorherigen Post anlegen, so dass mehr systematische Daten (die nicht aus Screenshots abgetippt werden müssten) vorliegen?

warum verwendest du kein discard in fstab um das trim einzuschalten? Oder nimmst du wiper.sh?

Hoppla, dies hatte ich einfach übersehen. Ab jetzt (Power_On_Hours=1064) ist discard drin. Wäre ohne Deinen Beitrag noch ewig ohne gelaufen - Danke!

 

[DerRob]

Du hast das aber jetzt nicht wirklich unter Vista gemacht?

Erwischt!

Nö, der erste Versuch (der aus der SSD eine Yatapdong gemacht hat) war unter XP. Erst danach hab ichs dann auch unter Vista probiert, aber die Fehlermeldung ist immer die gleiche.

 

[Morpog]

Hoppla, dies hatte ich einfach übersehen. Ab jetzt (Power_On_Hours=1064) ist discard drin. Wäre ohne Deinen Beitrag noch ewig ohne gelaufen - Danke!

Aber dann ist ja klar warum das GC bei dir derart aus dem Ruder läuft. Das implementierte GC verbraucht ja mit TRIM schon massig Zyklen.

 

[tzyn]

Hat hier jemand 2030 mit Linux am laufen?
weil hier gibts anscheinend schwierigkeiten mit 2030 und linux:
Support Question Vertex 1.6 fails to read data on Linux

Also ich hab bisher keine Probs unter Linux (Ubuntu 10.04, Kernel 2.6.32-23, ext4 Filesystem). Mir fehlen allerdings noch Langzeit-Erfahrungen. Hab erst vor wenigen Tagen auf 2030 aktualisiert.

 

[Dekal]

Nö, der erste Versuch (der aus der SSD eine Yatapdong gemacht hat) war unter XP. Erst danach hab ichs dann auch unter Vista probiert, aber die Fehlermeldung ist immer die gleiche.

Dann Versuch ma meinen Trick in Windows XP!

 

[DSL Cowboy]

moin, also meine 64GB hab ich heut morgen auf 1916w unter win7 und 2030 unter dos flashen können. habs dann noch mit meiner 32er probiert. 1916w geht unter win7 aber dann auf die 2030 wird die bei der frage mit targed drive nicht gefunden, die 64er schon. ist das 2030 nicht für 32er gedacht ?

 

[DSL Cowboy]

an welche email soll man den schreiben bei ST ?

 

[Morpog]

An niemanden. Kriegst PN von mir

 

[DerRob]

Dann Versuch ma meinen Trick in Windows XP!

Welchen "Trick"? Die 051302.exe hab ich schon mehrfach direkt gestartet, da ändert sich nix am Fehler.
Zuhause am Rechner hats übrigens auch nicht funktioniert, da kommt die gleiche Fehlermeldung.

Der Flasher fängt an, überprüft wohl erstmal die SSD (ich hab auch mal die anderen Versionen getestet, die brechen hier schon nach 1-2 sec ab), dann dreht sich der Strich für ca. 10 sec. (ich vermute, hier wird die SSD erstmal gelöscht), und dann bricht er mit dem Debug-Fehler ab.
Was passiert denn, wenn einer der Flashblöcke, in denen die Firmware gespeichert werden soll, defekt ist? Durch das Löschen sind doch die Informationen über den Zustand der Zellen auch erstmal weg. Prüft der Flasher vorher den Zustand und speichert die Firmware dann einfach in andere Zellen?

Was kann ich noch tun?

---------- Beitrag hinzugefügt um 09:50 ---------- Vorheriger Beitrag war um 09:40 ----------

An niemanden. Kriegst PN von mir

Für das Problem gibts schon eine Lösung? Warum regt sich ST dann nicht, und bietet weiterhin den fehlerhaften Flasher an?
Hätte auch Interesse an der Lösung (warum über PN? Zu gefährlich?)

 

[DSL Cowboy]

danke

 

[T.Full]

Willst Du aus dem Geld Flugzeuge basteln, um sie rausfliegen zu lassen?

*SCNR*

Kennst mich zwar nciht aber bei mir flog gelegentlich schon das ein oder andere Teil durch die Gegend. Auch ohne Flügel hat es beträchtliche Strecken hinter sich gebracht. Bei der SSD werde ich das jedoch nur symbolisch vollziehen, da ist sie mir dann doch zu teuer

 

[Morpog]

Für das Problem gibts schon eine Lösung? Warum regt sich ST dann nicht, und bietet weiterhin den fehlerhaften Flasher an?
Hätte auch Interesse an der Lösung (warum über PN? Zu gefährlich?)

Kriegst PN.

 

[antiram]

Hast Du/könntest Du eine /etc/cron.hourly/smartctl ähnlich meinem vorherigen Post anlegen, so dass mehr systematische Daten (die nicht aus Screenshots abgetippt werden müssten) vorliegen?

Hoppla, dies hatte ich einfach übersehen. Ab jetzt (Power_On_Hours=1064) ist discard drin. Wäre ohne Deinen Beitrag noch ewig ohne gelaufen - Danke!

lass am besten erst mal wiper.sh durchlaufen zum durchputzen.

die smart logdatei ist im Anhang. Die Reihenfolge der Spalten müßte allocs geändertem script entsprechen. Allerdings sinds bei mir "tab" statt ";" als trenner zur besseren lesbarkeit. Wenn die logdatei in /var/log liegt kann man sie mit dem systemprotokollbetrachter dann bequem lesen.

irgendwo in dem log springen die korrigierbaren fehlerbits plötzlich hoch. Da hab ich wohl den stromstecker bei der ssd gezogen bevor der rechner ganz aus war

 

[jodd]

Ich hab auf CB das gelesen und nachgefragt wo die Info herkommt, Antwort seht etwas weiter unten. Ist da was dran? Wenn ja, hätten sich alle mit einer GX die "Flasherei" auf 2030 sparen können.

 

[locoBO]

so habe eben auch erfolgreich meine beiden 128er aus dem Notebook und aus dem Desktop von der normalen 1916 auf die 2030 per USB-Stick geupdatet.

hat alles ohne Probleme geklappt.

Ich hatte zum Glück das "ich bin dann mal weg" Phänomen noch nich und hoffe, dass das mit der neuen Firmware dann auch nicht mehr passieren kann...

War nämlich schon ein bisschen paranoid deswegen...

Gruß Tim

 

[vectrafan]

Ich hab auf CB das gelesen und nachgefragt wo die Info herkommt, Antwort seht etwas weiter unten. Ist da was dran? Wenn ja, hätten sich alle mit einer GX die "Flasherei" auf 2030 sparen können.

wage ich zu bezweifeln, denn dann hätten ocz und supertalent kollektiv mist gebaut und ihre kunden unnötig flashen lassen.

 

[Morpog]

Ich hab auf CB das gelesen und nachgefragt wo die Info herkommt, Antwort seht etwas weiter unten. Ist da was dran? Wenn ja, hätten sich alle mit einer GX die "Flasherei" auf 2030 sparen können.

Das stimmt so definitiv nicht. Alleine ein Blick in den changelog beweist es.

Außerdem glaube ich nicht dass sich indilinx zu Produkten seiner Kunden Stellung (in diesem Fall Solidata) nimmt. Ein weiterer Punkt wäre noch dass bei den K6 in neueren Chargen nand kleiner 50nm eingestzt wird.

 

[jodd]

Konnte mir das auch nicht vorstellen, da nimmt sich wohl einer zu wichtig. Danke.

 

[pinki]

naja er spricht ja von "brauchen"...
Also brauchen tut mans ja nicht, ratsam ists aber "brauchen" ..... ^^

 

[schweiger]

ich habe auch bei meinem Lieferanten nachgefragt, der sagt auch, dass man den 2030flasher nicht braucht, die 1916 GC läuft absolut stabil (zumindest bei meinen)
ist vielleicht doch nur ein ST-Thema?

 

[vectrafan]

ich habe auch bei meinem Lieferanten nachgefragt, der sagt auch, dass man den 2030flasher nicht braucht, die 1916 GC läuft absolut stabil (zumindest bei meinen)
ist vielleicht doch nur ein ST-Thema?

nein, die 2030 wurde zuerst von ocz veröffentlicht.

 

[pinki]

Ach langsam nervts aber schon... NEIN es ist KEIN ST Only Thema !!

 

[frief]

warum verwendest du kein discard in fstab um das trim einzuschalten? Oder nimmst du wiper.sh?

Hoppla, dies hatte ich einfach übersehen. Ab jetzt (Power_On_Hours=1064) ist discard drin. Wäre ohne Deinen Beitrag noch ewig ohne gelaufen - Danke!

Aber dann ist ja klar warum das GC bei dir derart aus dem Ruder läuft. Das implementierte GC verbraucht ja mit TRIM schon massig Zyklen.

die smart logdatei ist im Anhang.

Danke für die Logdatei!

Ich habe mit discard enabled gestern etwa 16 GByte an Daten von der Platte gelöscht, so dass die GC jetzt mehr Luft hat.
Nun sieht es so aus, als stiege der Average_Erase_Count (ähnlich wie bei Dir in der Logdatei) etwa alle 7 Stunden um 1 an (dies entspräche einer Löschrate von etwa 2.5 MByte pro Sekunde bei einer 64 GByte Platte).
Vorher stieg Average_Erase_Count etwa alle 2 Stunden um 1 an...

(wiper.sh spare ich mir zunächst - bei Gelegenheit mache ich einen sanity erase)