On Mon, 3 Aug 2015 10:09:32 +0200
David Haller
Hallo,
Am Sun, 02 Aug 2015, Peter Mc Donough schrieb:
Am 02.08.2015 um 09:41 schrieb Stephan Hemeier:
Am Samstag, 1. August 2015, 23:54:14 schrieb Peter Mc Donough:
Am 01.08.2015 um 21:35 schrieb Stephan Hemeier:
...
Ich habe auch so eine Platte, als erstes hab ich eine aktuelle Firmware aufgespielt un d es läuft alles wunderbar.
Ich habe nur opensuse als Hauptsystem. Für die Samsung Firmware gibt es mit Samsung Magician DC auch eine (nach der Optik DOS??) Software zum Aufspielen der Firmware. Wenn ich mich recht erinnere nur für die "PRO" SSDs. Meine wäre die Standard 850 EVO. Würde mir also nichts nützen, oder?
Für die 850 gibt's noch kein Update, und das Update für die 840 ist erst das, was den Fehler hat (über NCQ+TRIM gleichzeitig) zu lügen.
Andererseits Windows 8.1 virtuell, vielleicht damit ließe sich die Firmware updaten, bevor ich die SSD unter Linux verwende. Was für Klimmzüge!
Es gibt kein FW-Update für die 850! Du mußt nur dafür sorgen, daß TRIM nicht per NCQ bei der Platte ankommt. Siehe dazu nebenan den Bug auf kernel.org. Im Zweifelsfall kannst du TRIM oder NCQ ausschalten.
Welchen Kernel verwendet dein System? ... Kernel 4.1 aus kernel:stable
Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable"
Könntes du in (vermutlich) /usr/src/linux-4.1.???/drivers/ata/libata-core.c ob bei
/* devices that don't properly handle queued TRIM commands */ { "Micron_M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, }, { "Crucial_CT???M500SSD*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, }, { "Micron_M550*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, }, { "Crucial_CT*M550SSD*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
Samsung hinzugefügt wurde?
Wurde es. Und zwar gleich die komplette 8xx Serie, obwohl meine 830 z.B. nicht betroffen ist. Aber ich verwende eh nen "uralten" Kernel ;) IIRC:
{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM, },
Wie Du selbst schon erkannt hast ist dieser Code Unfug, weil er Deine 830 inkludiert und auch gleich noch eine vielleicht noch kommende 8[6-9]0. Er koennte von Dir sein, so unspezifiziert wie er ist ;-)
oder so. Siehe den Bugreport nebenan.
BTW: Das Flag bringt's auf den Punkt, im Gegensatz zu dem was Krawallczinsky behauptet: NO_NCQ_TRIM == "TRIM geht nicht via NCQ".
Ist obiges flag gesetzt sorgt der Treiber dann dafür, daß die NC-Queue geleert wird, dann als einziger Befehl das TRIM, und dann kann's auch schon wieder mit NCQ weitergehen.
Auch wenn obiges Flag nicht gesetzt ist passiert genau das gleiche, weil der queued TRIM naemlich zusammen mit dem Auswerfen der "failed" Meldung, die eigentlich "informational" sein sollte abgeschaltet wird. Es gibt also einen automatischen Fallback in diesem Fall. Damit ist diese ganze Diskussion ganz klar akademisch und und es gibt kein real auftretendes Problem. Im Gegenteil macht der "Fix" die Sache eher schlimmer, weil er eben auch in die Zukunft der Produktschiene wirkt. Ich behaupte das muss nochmal veraendert werden. Der ganze "Vorgang" war bereits korrekt - defensiv - im Kernel implementiert und wurde nur wegen des Woertchens "failed" zum grossen Ding unter Usern die den Code nie gelesen haben. Jetzt ist die Meldung weg weil ein _falscher_ Patch gemacht wurde.
Der Klimmzug über obiges Flag ist aber nur nötig, weil die SSD auf ein ATA IDENTIFY Kommando hin lügt, eben behauptet TRIM auch via NCQ zu beherrschen, was aber eben nicht der Fall ist. TRIM funktioniert eben _NICHT_ per queue.
Das ist so nicht korrekt, die Implementation mag nur keine Send/Receive Logs. Es gibt Leute die durchaus bezweifeln dass das fuer jede Variante vorgeschrieben ist: "So the error message is actually wrong, as we should never test for the NCQ Send/Receive logs on implementations prior to ACS-3."
HTH, -dnh
-- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org