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

Status
Für weitere Antworten geschlossen.
Ich hab jetzt mal die 1916W geflasht, bzw. ich habs versucht... :rolleyes:

Und nun habe ich eine Yatapdong Barefoot... :mad:

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
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
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... :wall:
 
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... :wall:

Du hast das aber jetzt nicht wirklich unter Vista gemacht?
Die Anleitung hast du schon gelesen?
 
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!
 
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.
 
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 ?
 
Zuletzt bearbeitet:
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?)
 
Willst Du aus dem Geld Flugzeuge basteln, um sie rausfliegen zu lassen? :d

*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 :)
 
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
 

Anhänge

  • ssd.log.zip
    76,9 KB · Aufrufe: 58
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
 
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.
 
Konnte mir das auch nicht vorstellen, da nimmt sich wohl einer zu wichtig. Danke.
 
naja er spricht ja von "brauchen"...
Also brauchen tut mans ja nicht, ratsam ists aber "brauchen" ..... ^^
 
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?
 
Zuletzt bearbeitet:
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)
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh