etking schrieb:
Der Text könnte die genauso häufigen Hänger bei Crucial C300 und M4 schon im ersten Satz erwähnen und auch ein wenig auf die sofortige Symptombeseitigung durch das deaktivieren von LPM eingehen.
Zwischen den Problemen die Crucial mit LPM hatte und denen die Sandforce damit hat, gibt es aber ein paar entscheidende Unterschiede:
- Die Laggs waren bei Crucial deutlich kürzer und BSOD kamen auch nicht vor
- Crucial hat die Bug per Firmware-Update offenbar im wesentlichen abgestellt
- Die C300 gab es lange vor dem Chipsatz und damals war es die einizige SATA3 SSD am Marks, Intel hätte also damit testen und den Fehler gleicher erkennen müssen, nicht umgekehrt
Dionysos808 schrieb:
Aber weshalb sich Asus-Mainboards unterscheiden sollen (Aktivierung von Hot Plug), wenn diese Firmware im neuen BIOS steckt, leuchtet mir nicht ein.
Hotplug zu aktivieren führt nur dazu, dass Windows LPM deaktiviert und das Laufwerk dann bei "Hardeware sicher entfernen" aufgelistet wird.
Tronx schrieb:
Diese sind aber schon seit einigen Monaten durch das letzte Crucial Update behoben worden!
Eben, ware es das gleiche Problem, so sollte Sandforce das auch mal langsam behoben bekommen, aber die SF Controller haben ja wohl mit Energiezuständen sowieso mehr Probleme.
Tronx schrieb:
So langsam aber sicher wird es komisch bei Intel, was ist da nur los. Es sieht auch schwer danach aus, als ob die das schon lange wüssten.
Zumindest könnte man den Verdacht bekommen, dass Intel in der FW ihrer 510er Reihe, die ja den gleichen Controller wie Crucial verwendet, das Problem geschickt umgangen hat.
Pierrre schrieb:
Wollte mir eigentlich demnächst eine m4 besorgen.
Gute Wahl, LPM deaktivieren und auf FW 002 updaten, dann passt das.
Pierrre schrieb:
Ist davon auszugehen, dass die Probleme nun bald vollständig behoben sind?
Ja
Pierrre schrieb:
Oder besser eine OCZ Agility 3 wählen?
Nein.
chriss_msi schrieb:
Paradebeispiel ist der AHCI-Treiber von der AMD-Seite, der ist sowas von verbuggt und AMD bringt ja beinahe jeden Monat n Treiber raus, aber ändern tut sich gar nichts. Intel reagiert wenigstens noch auf Probleme...
Wieso ist der AMD AHCI verbuggt? AMD bringt zwar laufend neue Treiberpakete heraus, aber die sind ja in erster Linie für die Grakas und enthalten eben als Komplettpaket jeweils auch die aktuellen SB Treiber, aber an denn ändert sich längst nicht immer was. Du stellst das ja so hin, als würde AMD jeden Monat einen neuen AHCI Treiber bringen.
Bei Intel werden einzelne Treiber auch einzeln released.
chriss_msi schrieb:
Ich könnte an der Stelle auch den verbuggten AMD-USB-Filtertreiber in Benutzung mit nem FrescoLogic-USB3-Controller ansprechen, wo das Problem auch schon seit über einem Jahr besteht und bekannt ist, aber nichts gemacht wird, aber das gehört hier nicht dazu...
Wieso hat denn AMD eine Schuld an Problemen mit dem FrescoLogic USB3 Controller?
Moros schrieb:
1) Die News bedeutet auf gar keinen Fall, dass Intel an irgendwas allein Schuld wäre. SSD-Bugs kommen wie bei jeder Hardware vor, wie bei jeder Hardware sind die Auswirkungen des Bugs unterschiedlich. Diese Bugs müssen entsprechend von den SSD-Herstellern beseitigt werden.
Den Schuldigen am Bug zu finden dürfte sehr schwer sein, denn dass einige Probleme haben und andere nicht könnte durchaus auch an Toleranzen zu liegen. Wer die jetzt zu großzugig ausgelegt hat oder ob zwar beide Seiten die Vorgaben erfüllen, die Spezifikation aber in sich nicht passt, wird man schwer herausfinden können. Letztlich können die Unterschiede auch zwischen den Boardhersteller sogar am Layout liegen. Jedenfalls scheint das alles sehr auf Naht gestrickt zu sein und da hat Intel auch wieder eine Schuld, weil man zuletzt jedem Milliwatt nachrennt statt auf Stabilität zu setzen.
Moros schrieb:
2) Kleinere Hänger können auch durch ein aggressives Link Power Management (LPM) entstehen. Sie sind also nicht notwendigerweise auf einen Fehler im Chipsatz zurück zu führen!
LPM kann bei Problemen von jedem einfach deaktiviert werden.
Eben, LPM kann und sollte auch ruhig von jedem deaktiviert werden. Selbst eine HDDs macht das Probleme, nur fallen die eben kaum auf, weil die HDD sowiso langsamer reagieren.
Moros schrieb:
3) Ich gehe davon aus, dass eine Kombination aus Firmware- und BIOS-Updates das Problem komplett umgehen wird, wie dies bereits zum Teil geschehen ist. Es ist jedoch nicht auszuschließen, dass es bei Notebooks aufgrund des rudimentären und selten aktualisierten BIOS/(U)EFI noch für längere Zeit zu Problemen kommen kann. Ggf. sollte ein Hinweis an die Notebook-Hersteller erfolgen.
Warten wir das mal besser ab, jedenfalls sollte man solange niemandem eine Sandforce SSD empfehlen, wie die Lösung nicht gefunden ist, denn kurze Laggs die das Arbeiten unflüssig machen sind das eine, BSOD aber deutlich schwerwiegender. Die Intel 320er SSD Reihe kann man ja auch erst empfehlen, wenn der 8MB Bug beseitigt ist.
Quenya schrieb:
hatte das Problem vor ein paar Tagen auch. Habe ein ASUS Board mit X58-Chipsatz und eine OCZ Vertex 3 mit 120 GB fürs System. Der Rechner hat sich einfach total aufgehangen und nicht mehr reagiert. Ein Neustart mit Resetknopf hat nichts gebracht. Das SSD wurde dann nicht erkannt. Erst nachdem der Rechner komplett aus war ging wieder alles.
Dein Board hat einen ganz anderen Chipsatz, das gleiche Problem kann es also nicht sein. Das SF SSD zuweilen Probleme haben, die erst durch Power-Cycles gelöst werden, ist auch nicht neu. LPM zu deaktivieren könnte trotzdem helfen.
Kasmopaya schrieb:
Das wirklich schlimme daran ist ja das es bei Intel keine Auswahl an Chipssätzen mehr gibt, nur noch Intel, kein NV kein gar nix. Jetzt sitzt man da und man weis das es am Chipsatz liegt und man könnte gar nix anderes kaufen als den fehlerhaften Chipsatz. Schon das 2. mal in diesem Jahr das sich diese Situation negativ für den Kunden auswirkt.
Ja, das ist sehr traurig, aber bei AMD nicht anders. Deshalb muß man sich immer das Gespann CPU + Chipsatz ansehen und vergleichen, bevor man eine Kaufentscheidung trifft.
Kasmopaya schrieb:
Vielleicht wusste Intel von dem Problem schon länger, aber was sollen sie machen Sandy einfach nicht starten wegen den Chipsätzen? Erst jetzt die CPUs starten weil die Chipsätzte jetzt vielleicht mal fertig sind?
Durchaus denkbar. Bei Sandbridge-E scheint man sich dann aber anders entschieden zu haben, denn da verursachen wohl die Chipsätze die Probleme und sind damit Ursache der Verzögerung.
Kasmopaya schrieb:
Noch was stört mich an der Geschichte, das es so lange dauert bis man davon hört. Hätte ich mir 2011 einen neuen PC gekauft wäre es sicher Sandy und eine Sandforce geworden. Also gar keine Chance da zu reagieren.
Nachdem Crucial die Probleme per FW Update behoben hat und Intels eigene 510er Reihe keine hat, trifft es ja eigentlich nur noch SSDs mit dem neuen SF-2281 Controller und wie viele eigenen Bugs dessen FW noch enthält....
Kasmopaya schrieb:
Da sieht man mal wieder wie wichtig es ist sich Zeit zu lassen und möglichst alle Fehler zu finden. Bulldozer Verschiebung.
Hoffen wir mal, dass die Zeit gut angelegt sein wird.
Kasmopaya schrieb:
Bei BD/+Chipsatz will ich weder: Sockelbrand, Chipsatz Desaster, SSD Inkompatibilität noch sonst irgend welche Kinderkrankheiten sehen.
Da AMD die gleichen Chipsätze (nur umgelabelt) weiterverwenden wird, kann man mal davon ausgehen, dass die Chipsätze zumindest ausgereift sein werden.
Seth666 schrieb:
Wie siehts denn mit den Corsair Laufwerken aus?
Alle FW in SF-SSDs kommt von Sandforce selbst, da dürfte es keinen Unterschied machen, von welchem Hersteller die sind.
Moros schrieb:
Die Probleme treten selbstverständlich nicht bei allen Systemen mit aktuellen Intel-Platinen und SSDs auf.
S.o. eigentlich sind nur noch SF-2281 SSDs betroffen.
Moros schrieb:
Außerdem lässt sich der Bug vollständig umgehen.
Ist das so? Habt ihr auf dem Testsystem die Fehler wegbekommen? Gibt es ein BIOS Update, welches dies umgeht?
Moros schrieb:
Ich vermute ja, dass SandForce deshalb so stark betroffen ist, weil der Bug erst mit dem B3-Stepping kam (Spekulation!). Man hat den SF-2xxx vermutlich ausgiebig mit B2-Mainboards getestet und keinen Fehler gefunden.
Diese Vermutung kann ich nicht teilen. Es gibt User mit anderen Chipsätzen, die auch Probleme haben und es gibt das B3 Stepping schon eine ganze Weile, da hätte SF schon lange damit testen kommte und müssen, liegt doch der Unterschied im wesentlichen im SATA Controller. Ich vermute ehr, dass Sandforce schon immer mehr Probleme mit Energiezuständen hatte (
Sleep-Bug der nie
wirklich gelösst wurde) und keine Angabe zu Sleep/Slummer Leistungsaufnahme bei Vorstellung der zweiten Generation. Dazu kommt, dass die Controller wohl zuweilen in Zustände fallen, aus denen sie nur durch Power-Cycles rauskommen.
