Mickey Cohen schrieb:
das eigentliche problem ist doch, warum gehn die daten verloren, bloß weil der betriebsstundenzähler mist ausgibt? diese abhängigkeit dürfte schon garnicht existieren.
Die Daten werden wohl noch im NAND stehen, aber der Controller dürfte nicht mehr arbeiten und daher kommt man dann nicht mehr ran.
ImpactBlue schrieb:
vorausgesetzt das Update zerschießt einem nicht die Daten. Aber dafür gibt es wieder Backups. Theoretisch.
Das ein FW Update einer SSD die Daten zerstört ist schon lange nicht mehr verbreitet, ganz früher ist sowas öfter mal vorgekommen, aber das letzte an das ich mich erinnern kann, war eines bei der Samsung 470, also wirklich so aus der Anfangszeit der modernen SSDs.
Chattermark() schrieb:
Einige von uns waren selbst betroffen (Hallo, hier). Das hat mit übler Nachrede nichts zu tun.
Welche konkrete Crucial SSDs ist Dir den ausgefallen oder meinst Du mit betroffen den 5400 Stunden Bug der m4 und mit betroffen, dass man ein FW Update einspielen musste?
Chattermark() schrieb:
Ich denk da an meine erste SSD (Hersteller vergessen), die hatte alle paar Stunden Bluescreens produziert - das Firmware-Update das "bald" kommen sollte gibts bis heute nicht.
Hersteller vergessen aber auf Crucial meckern
Beim 5400h Bug war es so ähnlich, aber der BSOD kam bei der nach maximal einer Stunde, nämlich wenn der Betriebsstundenzähler über den kritischen Wert hinauszählen wollte, dann reagierte sie nicht mehr, bis man sie stromlos machte (z.B. durch Neustart des Rechners) und dann hatte man wieder maximal eine Stunden und konnte in der Zeit das FW Update einspielen, dann war der Spuck vorbei.
DocWindows schrieb:
Wüsstest du so spontan einen Test mit dem du genau diesen Fehler beim Testing erkannt hättest?
Beim Testing kann man den nicht finden, aber zu den Grundlagen jeder Softwareentwicklung gehört es sich Gedanken um die Datentypen zu machen die man jeweils verwendet. Wenn jemand eine Variabel nimmt um die Betriebsstunden zu zählen, sollte man sich überlegen wie lange ein 16 Bit Integer reicht und klar sein, dass dies zu kurz ist um die geplante Nutzungsdauer zu überstehen.
DocWindows schrieb:
Wenn der Zähler überläuft dürfte sich die positive Zahl der Betriebsstunden in eine negative Zahl umkehren. Wenn die Firmware das beim Starten und/oder Aktualisieren nicht abfängt, stürzt sie ab und bootet auch nicht mehr. Da man für Betriebsstunden selten negative Werte erwartet, weil Zeitreisen noch nicht funktionieren, fängt man das wahrscheinlich auch nicht ab.
Das ist aber der nächste Fehler, man muss jeden möglichen Fehler abfangen, außerdem frage ich mich, wofür die FW die Betriebsstunden überhaupt nutzt, die müssen doch nur hochgezählt werden, aber scheinbar macht die FW irgendwelche Berechnungen mit den Betriebsstunden.
DocWindows schrieb:
Der höhere Wert schwappt dann möglicherweise quasi in den nächsten Speicherbereich über und überschreibt etwas anderes, möglicherweise wichtiges.
Wieso sollte was anderes überschrieben werden? Es gibt ein Register in der CPU welches gesetzt wird und wenn man dies nicht abfragt, passiert gar nichts, der Wert geht auf 0 und mehr passiert dann nicht.
Nebula123 schrieb:
Bei Intel geht es um die Idle Stunden, dort gibt es nur Probleme, wenn die SSD mehr als 1700h ununterbrochen Idle ist, was allenfalls bei einer Hot-Spare SSD der Fall sein dürfte, wobei meist schon das Auslesen der S.M.A.R.T. Werte, z.B. zur Überwachung der Temperatur, den Idle Zustand unterbricht. Außerdem gibt es das FW Update mit dem Bugfix bei Intel schon lange.
DocWindows schrieb:
Man kann bei der Entwicklung sicherlich alles mögliche bedenken, aber dann wird man a) nie fertig und hat b) hinterher ein unperformantes Produkt, weil tonnenweise Prüfcode auf alles mögliche auf die Leistung drückt, und das vollkommen unnötig weil 99,9% der überprüften Zustände niemals eintreten.
Also so lange dauert es nun auch nicht sich Gedanken um die Datentypen zu machen und wenn man ein 32 Bit Integer nimmt, dann braucht man keinen Prüfcode um deren Überlauf abzufangen.
