News Verursacht Fehler in Intel-Chipsatz SSD-Probleme?

[Ralf555]

"Intel sind keine Probleme mit HDDs/SDDs im Zusammenhang mit Intel Chipsätzen – auch nicht mit Cougar Point – wie in den Forum-Diskussionen beschrieben, bekannt. Die diskutierten Probleme sind ferner nicht auf das publizierte Erratum zurückzuführen. Intel ist sehr bemüht beste Produktqualität und Verlässlichkeit zu liefern. Darüber hinaus werden wir ausgiebige Validierungen und Qualitätskontrollen durchführen sowie die beschriebene Situation im Auge behalten."

http://www.pcgameshardware.de/aid,8...-SSDs-und-6er-Mainboard-Chips/Mainboard/News/


Wie ich sagte, mit dem Chipsatz hat das nichts zu tun. Ich bitte um Klarstellung in der news.

 

[Falke]

Diesen Hinweis solltet ihr aber auch wenn erwähnen.

Those of you that have the Revodrive3, this update applies to you as well, the Toolbox will update the drives.


A note to those using Intel RST drivers, we are highly recommending you use 10.6 or newer.

If you are using 10.1 or 9.6 we are now strongly advising you to update to 10.6 or newer

http://downloadcenter.intel.com/Detail_Desc.aspx?lang=eng&changeLang=true&DwnldId=20215

 

[Athlonscout]

Wie ich sagte, mit dem Chipsatz hat das nichts zu tun. Ich bitte um Klarstellung in der news.

Das ist ja die Aussage der Intel Marketingabteiulung! Das die sich auch nicht 100% sicher ist räumen Sie ja ein, indem sie weiterhin "beobachten" wollen.
Zudem wird in der News ja nur hinterfragt (siehe ?) und nicht als Fakt hingestellt.

Insofern finde ich dein Gemeckere etwas ...

 

[uNrEL2K]

http://filebase.exceleram.com/Softw...-in-Windows-with-SandForce-Driven-SSD(EN).pdf

Mittlerweile trägt der Msahci eine größere Versionsnummer. In dem PDF geht es um eine ältere Variante des Treibers.

 

[Holt]

Halten wir doch mal fest: Crucial hatte mit LPM Probleme mit Laggs und diere per FW Update gelöst, was auch zu erwarten war, denn die Intel 510 verwendet den gleichen Controller ohne diese Probleme zu haben. Von den andere SSD sind auch nur die mit SandForce Controller betroffen und SF hat jetzt ein FW Update gebracht um diese zu beheben, wo liegt da wohl die Ursache des Problems?

 

[Ralf555]

Das ist ja die Aussage der Intel Marketingabteiulung! Das die sich auch nicht 100% sicher ist räumen Sie ja ein, indem sie weiterhin "beobachten" wollen.
Zudem wird in der News ja nur hinterfragt (siehe ?) und nicht als Fakt hingestellt.

Insofern finde ich dein Gemeckere etwas ...

Es gibt keine schlüssige Erklärung die die Chipsatz These unterstützt. Das was hier CB in der news berschreibt hat jedenfalls nichts mit dem Chipsatz zu tun. Es müsste seitens CB zuerst einmal der Beweis erbracht werden bevor groß Anschuldigungen in die Richtung gehen. Das ist reinste Polemik so wie sich das derzeit darstellt. Und Intel ist kein kleines AMD oder OCZ, wenn es wirklich ein Chipsatz Problem wäre, würde die Erklärung dementsprechend anders ausfallen. Außerdem passt es einfach nicht zusammen, dass AMD user ebenfalls betroffen sind.

Hierzu passt auch, dass mehrere Leser von ähnlichen Problemen bei AMD-Systemen berichten.

 

[Athlonscout]

Es gibt keine schlüssige Erklärung die die Chipsatz These unterstützt. Das was hier CB in der news berschreibt hat jedenfalls nichts mit dem Chipsatz zu tun. Es müsste seitens CB zuerst einmal der Beweis erbracht werden bevor groß Anschuldigungen in die Richtung gehen. Das ist reinste Polemik so wie sich das derzeit darstellt.

Wundert mich, dass du hier CB kritisierst, in spekulativen News über andere Hersteller aber keine Kritik an CB übst.

Und Intel ist kein kleines AMD oder OCZ, wenn es wirklich ein Chipsatz Problem wäre, würde die Erklärung dementsprechend anders ausfallen.

In der Vergangenheit hat sich Intel nicht gerade dadurch ausgezeichnet Fehler ihrer Produkte ihren Kunden gegenüber zuzugeben. Warum sollte es hier ausgerechnet anders sein?

Außerdem passt es einfach nicht zusammen, dass AMD user ebenfalls betroffen sind.

Das der SF 2xxx Controller (bzw die bisherigen Produkte) verbuggt sind, wird ja auch nach und nach von den OEMs wie OCZ und Co. eingeräumt.

 

[Ralf555]

Wundert mich, dass du hier CB kritisierst, in spekulativen News über andere Hersteller aber keine Kritik an CB übst.

Das hat dich nicht zu wundern, meine Interessen sind meine Angelegenheiten. Wenn dich etwas zu anderen news stört, steht es dir frei deinen eigenen Senf beizusteuern.

In der Vergangenheit hat sich Intel nicht gerade dadurch ausgezeichnet Fehler ihrer Produkte ihren Kunden gegenüber zuzugeben. Warum sollte es hier ausgerechnet anders sein?

Sata Cougar Point-B2 und SSD 320 Bug, nur um 2 Beispiele zu nennen. Intel hat keine Probleme damit Fehler zuzugeben im Gegensatz zu kleineren Herstellern. Warum sollte es hier ausgerechnet anders sein? Ohne Beweise sollte sich CB bzw. der entsprechende News Verfasser etwas zurückhalten mit Anschuldigungen. Was in der news zu lesen ist, ist reinste Spekulationsbasis. Es deutet nichts auf ein Chipsatz Fehler hin.

 

[jodd]

Immer schön beim Thema bleiben, für anderes Geplänkel ist hier kein Platz.

 

[Holt]

In der Vergangenheit hat sich Intel nicht gerade dadurch ausgezeichnet Fehler ihrer Produkte ihren Kunden gegenüber zuzugeben. Warum sollte es hier ausgerechnet anders sein?

Das sehe ich nicht so, den Bug im SATA2 Teil von Cougar Point Rev. B2 hat niemand bemerkt und hätte das auch so schnell nicht, weil er ja erst mit der Zeit auftrifft. Trotzdem hat Intel ihn public gemacht und die Chipsätze getauscht.
Den Bug in der 320er SSD Reihe haben sie untersucht und arbeiten an einer Lösung. Deine Behauptungen bzgl. Intels Verhalten bei Fehlern in seinen Produkten entbähren also jeder Grundlage.

Das der SF 2xxx Controller (bzw die bisherigen Produkte) verbuggt sind, wird ja auch nach und nach von den OEMs wie OCZ und Co. eingeräumt.

Wo hat wer das jemals eingeräumt? OCZ hat die Release-Notes der 1.32 FW erst wie hier im OCU Forum zu sehen komplett auch im pdf angegeben und dieses dann gekürzt, so steht es jetzt im Netz. (Sollte der Beitrag im OCZ Forum auch gekürzt werden, hier habe ich die Liste damals auch kopiert.

Davon Bugs im eigenen Produkt einzuräumen sind die wohl weiter entfernt als Intel.

Was in der news zu lesen ist, ist reinste Spekulationsbasis. Es deutet nichts auf ein Chipsatz Fehler hin.

So sehe ich das auch und spätestens wenn das FW Update von SF die Probleme löst, dann sollte CB auch eine Richtigstellung bringen. Anderseits haben die SandFroce Controller schon seid der ersten Generation offenbar besondere Probleme mit Powerstates. Das könnte an der Funktionsweise liegen, denn wie OCZ selbst erklärt

However, if you write 2x DVDr's worth of data in rar format quickly to the drive that OP area could be gone very quickly. The drive will then start actively freeing up blocks marked by TRIM as not needed and will rebuild the OP area...A recovery period is now needed as any writes made during this period will push back the time it takes to rebuild the full OP allocation.

hat Sandforce ein anderes Verständnis von Overproviding und muss wohl komplexere Operationen im Idle ausführen als andere SSDs, deren Unterbrechung dann natürlich größere Probleme verursachen kann.

 

[Athlonscout]

Das sehe ich nicht so, den Bug im SATA2 Teil von Cougar Point Rev. B2 hat niemand bemerkt und hätte das auch so schnell nicht, weil er ja erst mit der Zeit auftrifft. Trotzdem hat Intel ihn public gemacht und die Chipsätze getauscht.

Da hat Intel imho zum ersten Mal ohne Druck einen Fehler (vorbildlich) eingestanden. Das war aber nicht immer so! Bspw. der Pentium FDIV-Bug wurde damals geleugnet bis es nicht mehr zu leugnen war.

Den Bug in der 320er SSD Reihe haben sie untersucht und arbeiten an einer Lösung.

Trotzdem haben Sie den Bug erst nach massiven Kundenbeschwerden öffentlich publik gemacht. Da kann mir jetzt keiner erzählen, dass Intel der Bug nicht bekannt war, bevor viele Kunden ihre Daten verloren hatten.

 

[Ralf555]

Trotzdem haben Sie den Bug erst nach massiven Kundenbeschwerden öffentlich publik gemacht. Da kann mir jetzt keiner erzählen, dass Intel der Bug nicht bekannt war, bevor viele Kunden ihre Daten verloren hatten.

Ein "Bug" muss erst validiert werden. Es macht keinen Sinn vorschnelle Entscheidungen zu treffen. Intel hat schnellstmöglich reagiert.

 

[Holt]

Da hat Intel imho zum ersten Mal ohne Druck einen Fehler (vorbildlich) eingestanden. Das war aber nicht immer so! Bspw. der Pentium FDIV-Bug wurde damals geleugnet bis es nicht mehr zu leugnen war.

Der Pentium-FDIV-Bug wurde von Prof. Thomas Ray Nicely vom Lynchburg College entdeckt und am 30. Oktober 1994 informierte er ausgewählte Fachbuchautoren und Fachjournalisten.

Pentium-FDIV-Bug]Als gesichert kann gelten, dass Intel den Fehler bereits seit längerem kannte. Anders lässt sich der Umstand, dass Intel schon im Oktober eine fehlerbereinigte Version in Musterstückzahlen liefern konnte, nicht erklären.

Intel hat den Bug nicht geleugnet, man hat ihn nur als nicht für Endanweder relevant angesehen, weil man der Meinung war, er würde bei denen nur alle 27.000 Jahre einmal auftreten. Und Intel hat daraus ja auch gelernt, was bis heute, 17 Jahre danach, gilt:

Pentium-FDIV-Bug]Aber Intel zog auch seine Lehren aus dem Vorfall. Andy Grove entschuldigte sich in der Presse für den Ärger, den seine Haltung verursacht hat. Es wurde extra für den Umtausch der fehlerhaften CPUs eine Telefonzentrale eingerichtet. Insgesamt stellte Intel für diesen Vorfall 475 Millionen Dollar zur Verfügung, was über der Hälfte des Gewinns im vierten Quartal des Jahres 1994 entsprach. Am Ende wurden ca. eine Million fehlerhafte Prozessoren umgetauscht. 1995 begann man mit der Veröffentlichung aller in den eigenen CPUs entdeckten Fehler. Um an diese Informationen zu kommen, musste man zuvor noch eine Vertraulichkeitsvereinbarung unterzeichnen. Von nun an konnte sich jeder in sogenannten Specification Updates über Fehler in Intel-Produkten informieren.

Trotzdem haben Sie den Bug erst nach massiven Kundenbeschwerden öffentlich publik gemacht. Da kann mir jetzt keiner erzählen, dass Intel der Bug nicht bekannt war, bevor viele Kunden ihre Daten verloren hatten.

Wenn eine Firma ein Produkt ausliefert, dann gibt es immer wieder Kunden die Probleme damit haben. Ist es ein neues Produkt, wie die 320er Reihe, so muß man erst einmal eine bestimmte Häufing eines gleichen Syntoms haben, bevor man diese als einen Fehler im Produkt erkennen und darauf reagieren kann. Würden alle SSD Hersteller Fehler so schnell eingestehen und sich um Lösungen bemühen, so hätte Sandforce den Sleep Bug schon viel früher lösen müssen und es gäbe wohl auch keinen news wie diese.

 

[T3mp3sT1187]

Hab ne Crucial m4 - System lief super bis zur Installation von den Intel Treibern... zum Glück ist inzwischen Firmware 0002 draußen, damit kann ich LPM aktiviert lassen und es klappt bestens...

 

[WeltalsWille]

Es gibt keine schlüssige Erklärung die die Chipsatz These unterstützt. Das was hier CB in der news berschreibt hat jedenfalls nichts mit dem Chipsatz zu tun. Es müsste seitens CB zuerst einmal der Beweis erbracht werden bevor groß Anschuldigungen in die Richtung gehen. Das ist reinste Polemik so wie sich das derzeit darstellt. Und Intel ist kein kleines AMD oder OCZ, wenn es wirklich ein Chipsatz Problem wäre, würde die Erklärung dementsprechend anders ausfallen. Außerdem passt es einfach nicht zusammen, dass AMD user ebenfalls betroffen sind.

CB muß nicht beweisen. Es ist kein wissenschaftliches Organ sondern ein journalistisches. Das Aufwerfen spektulativ kritischer Fragen anhand von Indizien, wie im vorliegenden Fall, liegt im Rahmen der üblichen journalistischen Freiheit.

Dass Intel offiziell angibt, nicht der Problemverursacher zu sein, liegt im Erwartungsbereich. Man sollte das der Vollständigkeit halber in den Artikel einbeziehen. Die ursprüngliche Aussage muß aber keinesfalls geändert werden, denn die von CB ermittelten Indizien sind mit Behauptungen, wie "Intel sind keine Probleme mit HDDs/SDDs im Zusammenhang mit Intel Chipsätzen – auch nicht mit Cougar Point – wie in den Forum-Diskussionen beschrieben, bekannt. Die diskutierten Probleme sind ferner nicht auf das publizierte Erratum zurückzuführen." nicht nachvollziehbar widerlegt. Zudem ist die Informationspolitik eines Konzerns, egal ob intel, beate uhse, greenpeace energy oder amd, zuvörderst dem wirtschaftlichen Eigennutz und einem positiven Image verplichtet. Dass eigene Defizite immer nur mit großer Zurückhaltung eingeräumt werden, ist praktisch selbstverständlich.

 

[Holt]

Die ursprüngliche Aussage muß aber keinesfalls geändert werden, denn die von CB ermittelten Indizien sind mit Behauptungen, wie "Intel sind keine Probleme mit HDDs/SDDs im Zusammenhang mit Intel Chipsätzen – auch nicht mit Cougar Point – wie in den Forum-Diskussionen beschrieben, bekannt. Die diskutierten Probleme sind ferner nicht auf das publizierte Erratum zurückzuführen." nicht nachvollziehbar widerlegt.

Es ist aber schon sehr merkwürdig, dass die Probleme nur Crucial und SandForce SSDs betrafen, Crucial diese durch FW Updates (002 für die m4, 007 für die C300) beseitigt hat (wie Du in dem Beitrag über Deinem lesen kannst) und auch SandForce mit der FW 2.11 erwartet dies Behoben zu haben. Da kann man die These der Schuld von Intels Chipsatz kaum noch aufrecht erhalten.

 

[Warhead]

damit geht das ganze automatisch ,o hne selbst in der regedit rumfummeln zu müssen.
http://www.noobtech.at/wp-content/uploads/2011/05/LPM.zip

nur komisch, dass beide regfiles identisch sind

 

[Holt]

@Warhead, wieso sind beide identisch? Du hast sie Dir nicht genau angesehen, sonst hättest du den Unterschied zwischen:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port0]

und

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port0]

erkannt.

 

[derGrimm]

Da es sich um einen Hardware-Defekt handelt, ja.

Naja, den kann man ja auch unter Windows "zügeln"
Nutzt Ubuntu LPM?

http://www.pcgameshardware.de/aid,8...-SSDs-und-6er-Mainboard-Chips/Mainboard/News/

Wie ich sagte, mit dem Chipsatz hat das nichts zu tun. Ich bitte um Klarstellung in der news.

Genau, genauso wie Intel keinen Marktmißbrauch betrieben hat usw.

Es ist aber schon sehr merkwürdig, dass die Probleme nur Crucial und SandForce SSDs betrafen, Crucial diese durch FW Updates (002 für die m4, 007 für die C300) beseitigt hat (wie Du in dem Beitrag über Deinem lesen kannst) und auch SandForce mit der FW 2.11 erwartet dies Behoben zu haben. Da kann man die These der Schuld von Intels Chipsatz kaum noch aufrecht erhalten.

Die Linux Distributionen hatten (haben?) Probleme mit UEFI bei vielen Herstellern.
Aber nicht weil die Linux Distributionen schlecht programmiert sind, sondern weil M$ sich nicht ganz korrekt an die Spezifikationen hält und die Hersteller sich nach Windows richten und meist nur dort Testen.

Nur weil man ein Fehler lösen kann bzw. bei anderen nicht Auftritt, heißt das nicht das die SSDs schuld sind.
Es kann auch einfach sein, dass die anderen das Problem einfach schon vorher umgangen haben und nun z.B. OCZ mit der neuen FW-Version das Problem umgeht.

umgeht =|= es ist keins Vorhanden!

 

[WeltalsWille]

Hihi, inzwischen hat intel die letzte Rev. der Spezifikation für die 6er-Chipsets zurückgezogen. Damit ist auch das den Problemen mit den SF22xx-SSD verblüffend ähnliche BSOD-Erratum verschwunden. Ich kann natürlich verstehen, dass man ggf. falschen Spekulationen um Mitverantwortung an Inkompatilitäten von Komponenten Dritter den Nährboden entziehen will. Man hätte diesen Schritt aber entsprechend kommentieren sollen. Durch den platten Rückzug wird der Eindruck erweckt, man würde Errata willkürlich bekannt geben.