SSD - TRIM Problem?? Samsung 850 EVO 250GB - openSUSE Users (Deutsch)

SSD - TRIM Problem?? Samsung 850 EVO 250GB

Peter Mc Donough

1 Aug 2015 1 Aug '15

14:06

Hi, nach langem Zögern habe ich mir eine SSD bestellt, man gönnt sich ja sonst nix. Die Wahl fiel auf die Samsung 850 EVO 250GB, hauptsächlich wegen der fünf Jahre Garantie. Alternativ wäre auch eine Crucial ... BX 250GB in Frage gekommen. Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen. https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ Das ist nicht die einzige Quelle, andere berichten ebenfalls von Problemen, auch mit Samsung Consumer SSDs. Nach Hinweisen fand ich bei bei meinem Opensuse 4.2 64bit, Kernel 3.16.7-21 in /usr/src/linux-3.16.7-21/drivers/ata/libata-core.c dass zumindest Cruicial auf einer Blacklist steht und der Eintrag vermutlich dem Kernel sagt, wie er damit umgehen soll. * 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, }, Ein vergleichbarer Eintrag wäre sicher für Selbstcompilerer interessant, zu denen rechne ich mich nicht, wer weiß, was er beim nächsten Kernelupdate anrichten würde. Regelmäßiges TRIM an sich soll ja für die SSD-Performance wichtig sein Gesucht ist eine update-resistente Möglichkeit TRIM zu verwenden, ohne sich einen Datenverlust einzuhandeln. Tipps? Gruß Peter -- 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

Show replies by date

Stephan von Krawczynski

1 Aug 1 Aug

15:39

On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote:

...

Hi,

nach langem Zögern habe ich mir eine SSD bestellt, man gönnt sich ja sonst nix. Die Wahl fiel auf die Samsung 850 EVO 250GB, hauptsächlich wegen der fünf Jahre Garantie. Alternativ wäre auch eine Crucial ... BX 250GB in Frage gekommen.

Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel, den ein Samsung-Techniker nach langem Suchen aufgedeckt hat. Im wesentlichen handelte es sich um einen Free von noch benutztem Speicher (mehrere Pointer). Hier der von einem Oracle-Mann vorgeschlagene Patch: http://www.spinics.net/lists/raid/msg49455.html

...

[...] Tipps?

Lesen?

...

Gruß Peter

-- 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

Peter Mc Donough

22:27

Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...

On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: ...

...
Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen. https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel, den ein Samsung-Techniker nach langem Suchen aufgedeckt hat. Im wesentlichen handelte es sich um einen Free von noch benutztem Speicher (mehrere Pointer).

Wie ich den Vorgang verstanden habe, musste Samsung zur Mithilfe getragen werden. In Windows tritt das Problem nicht auf, weil es TRIM nicht in der Weise anspricht, wie der Linux-Kernel.

...

Hier der von einem Oracle-Mann vorgeschlagene Patch: http://www.spinics.net/lists/raid/msg49455.html

List sich gut, schön, aber die Anwendung des Patches überschreitet meine Fähigkeiten, davon abgesehen, dass eine lokale Korrektur beim nächsten Update u.U. wieder verschwände, ein Rezept für massiven Trouble. Ich fände es besser, wenn ein solcher Patch von "oben" in den regulären 13.2er suse Kernel übernommen werden würde. Gruß Peter -- 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

Stephan von Krawczynski

2 Aug 2 Aug

11:09

On Sun, 2 Aug 2015 00:27:33 +0200 Peter Mc Donough wrote:

...

Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...
On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: ...

...
Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen. https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel, den ein Samsung-Techniker nach langem Suchen aufgedeckt hat. Im wesentlichen handelte es sich um einen Free von noch benutztem Speicher (mehrere Pointer).

Wie ich den Vorgang verstanden habe, musste Samsung zur Mithilfe getragen werden. In Windows tritt das Problem nicht auf, weil es TRIM nicht in der Weise anspricht, wie der Linux-Kernel.

Ich wuerde sogar sagen dass die Mithilfe von Samsung ausserordentlich gut war. Ich bin eigentlich ziemlich erstaunt darueber dass dort jemand tatsaechlich sich mit einem "User-Problem" beschaeftigt hat und die Ursache die noch dazu ausserhalb des eigenen Unternehmens lag aufgedeckt und einen eigenen Patch vorgeschlagen hat. Das finde ich ziemlich lobenswert. Ich kann mich auf die Schnelle an keinen aehnlichen Fall erinnern wo jemand von Seagate (Beispiel) aehnliches getan haette. Dort werden die Produkte nach PR/Markt-Einschaetzungen gerne mal "demoliert" anstatt sie zu verbessern.

...

...
Hier der von einem Oracle-Mann vorgeschlagene Patch: http://www.spinics.net/lists/raid/msg49455.html

List sich gut, schön, aber die Anwendung des Patches überschreitet meine Fähigkeiten, davon abgesehen, dass eine lokale Korrektur beim nächsten Update u.U. wieder verschwände, ein Rezept für massiven Trouble. Ich fände es besser, wenn ein solcher Patch von "oben" in den regulären 13.2er suse Kernel übernommen werden würde.

Gruß Peter

Im Gegensatz zu Dir bin ich der Meinung dass es so etwas wie einen 13.2er suse Kernel gar nicht geben sollte. Kernels sollten nur von kernel.org kommen. Da kuemmern sich staendig gute Leute darum genau solche Patches und Probleme zu bearbeiten. Wozu dieselbe Arbeit nochmals bei SuSE oder einem anderen Distri-Kernel-Maintainer gemacht werden soll vermag mir nicht einzuleuchten. Es verkleinert nur die Anwenderbasis fuer die regulaeren Kernel.org Kernels und ist daher auch noch kontra-produktiv. -- 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

Peter Mc Donough

12:10

Am 02.08.2015 um 13:09 schrieb Stephan von Krawczynski:

...

On Sun, 2 Aug 2015 00:27:33 +0200 Peter Mc Donough wrote:

...
Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...
On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: ...

...
Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen. https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel, den ein Samsung-Techniker nach langem Suchen aufgedeckt hat. Im wesentlichen handelte es sich um einen Free von noch benutztem Speicher (mehrere Pointer).

Wie ich den Vorgang verstanden habe, musste Samsung zur Mithilfe getragen werden. In Windows tritt das Problem nicht auf, weil es TRIM nicht in der Weise anspricht, wie der Linux-Kernel.

Ich wuerde sogar sagen dass die Mithilfe von Samsung ausserordentlich gut war. Ich bin eigentlich ziemlich erstaunt darueber dass dort jemand tatsaechlich sich mit einem "User-Problem" beschaeftigt hat und die Ursache die noch dazu ausserhalb des eigenen Unternehmens lag aufgedeckt und einen eigenen Patch vorgeschlagen hat. Das finde ich ziemlich lobenswert.

Da habe ich im Rahmen der Suche nach einer Problemlösung auch Anderes von Samsung gelesen. Die Reaktion Samsungs liegt vielleicht daran, das Algolia nicht einfach ein beliebiger user ist und mit einer von anderen beachteten Veröffentlichung Samsung in Zugzwang gebracht hat, insbesondere mit dem Hinweis, das der Fehler bei sonst gleicher Konfiguration bei Intel SSDs nicht auftritt. Ein weitere Zitat aus einer Meldung vom 19.6.2015 http://www.computerbase.de/2015-06/server-ausfaelle-angeblicher-trim-bug-bei... "The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro...." "... Martin K. Petersen, Kernel Developer bei Oracle" [Patcheinspielung]

...

...
List sich gut, schön, aber die Anwendung des Patches überschreitet meine Fähigkeiten, davon abgesehen, dass eine lokale Korrektur beim nächsten Update u.U. wieder verschwände, ein Rezept für massiven Trouble. Ich fände es besser, wenn ein solcher Patch von "oben" in den regulären 13.2er suse Kernel übernommen werden würde.

Im Gegensatz zu Dir bin ich der Meinung dass es so etwas wie einen 13.2er suse Kernel gar nicht geben sollte. Kernels sollten nur von kernel.org kommen. Da kuemmern sich staendig gute Leute darum genau solche Patches und Probleme zu bearbeiten. Wozu dieselbe Arbeit nochmals bei SuSE oder einem anderen Distri-Kernel-Maintainer gemacht werden soll vermag mir nicht einzuleuchten. Es verkleinert nur die Anwenderbasis fuer die regulaeren Kernel.org Kernels und ist daher auch noch kontra-produktiv.

Das hängt vermutlich einerseits an der Dynamik der Linuxentwicklung und andererseits an der erwarteten Stabilität einer Distribution. Da es bei der Kernelentwicklung nicht nur um Freizeitbeschäftigung geht, wird es eine genügend andere Motivationen für spezielle Kernelanpassungen geben. Gruß Peter -- 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

Stephan von Krawczynski

16:12

On Sun, 2 Aug 2015 14:10:43 +0200 Peter Mc Donough wrote:

...

Am 02.08.2015 um 13:09 schrieb Stephan von Krawczynski:

...
On Sun, 2 Aug 2015 00:27:33 +0200 Peter Mc Donough wrote:

...
Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...
On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: ...

...
Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen. https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel, den ein Samsung-Techniker nach langem Suchen aufgedeckt hat. Im wesentlichen handelte es sich um einen Free von noch benutztem Speicher (mehrere Pointer).

Wie ich den Vorgang verstanden habe, musste Samsung zur Mithilfe getragen werden. In Windows tritt das Problem nicht auf, weil es TRIM nicht in der Weise anspricht, wie der Linux-Kernel.

Ich wuerde sogar sagen dass die Mithilfe von Samsung ausserordentlich gut war. Ich bin eigentlich ziemlich erstaunt darueber dass dort jemand tatsaechlich sich mit einem "User-Problem" beschaeftigt hat und die Ursache die noch dazu ausserhalb des eigenen Unternehmens lag aufgedeckt und einen eigenen Patch vorgeschlagen hat. Das finde ich ziemlich lobenswert.

Da habe ich im Rahmen der Suche nach einer Problemlösung auch Anderes von Samsung gelesen.

Die Reaktion Samsungs liegt vielleicht daran, das Algolia nicht einfach ein beliebiger user ist und mit einer von anderen beachteten Veröffentlichung Samsung in Zugzwang gebracht hat, insbesondere mit dem Hinweis, das der Fehler bei sonst gleicher Konfiguration bei Intel SSDs nicht auftritt.

Ein weitere Zitat aus einer Meldung vom 19.6.2015 http://www.computerbase.de/2015-06/server-ausfaelle-angeblicher-trim-bug-bei...

"The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro...." "... Martin K. Petersen, Kernel Developer bei Oracle"

Ich wuerde mal sagen dass der gute Martin sich da recht weit aus dem Fenster haengt und im direkten Gespraech mit dem Samsung Entwickler zurueckrudern muss: --- Zitat Martin K. Petersen ----- Seunguk, Thanks for tracking this down. Instead of explicitly coding around the issue in raid0/raid10/linear I would prefer to fix bio_split(). It seems like a deficiency in the interface that it does not handle this transparently. --- Zitat Ende ---- (http://www.spinics.net/lists/raid/msg49455.html) So oft Du das auch wiederholst, es ist kein Samsung Problem. Es tritt bei Intel nicht auf weil einfach das Timing in deren Ablaeufen anders ist. Vielleicht ist Samsung an genau dieser Stelle einfach schneller...

...

[Patcheinspielung]

...
...
List sich gut, schön, aber die Anwendung des Patches überschreitet meine Fähigkeiten, davon abgesehen, dass eine lokale Korrektur beim nächsten Update u.U. wieder verschwände, ein Rezept für massiven Trouble. Ich fände es besser, wenn ein solcher Patch von "oben" in den regulären 13.2er suse Kernel übernommen werden würde.

Im Gegensatz zu Dir bin ich der Meinung dass es so etwas wie einen 13.2er suse Kernel gar nicht geben sollte. Kernels sollten nur von kernel.org kommen. Da kuemmern sich staendig gute Leute darum genau solche Patches und Probleme zu bearbeiten. Wozu dieselbe Arbeit nochmals bei SuSE oder einem anderen Distri-Kernel-Maintainer gemacht werden soll vermag mir nicht einzuleuchten. Es verkleinert nur die Anwenderbasis fuer die regulaeren Kernel.org Kernels und ist daher auch noch kontra-produktiv.

Das hängt vermutlich einerseits an der Dynamik der Linuxentwicklung und andererseits an der erwarteten Stabilität einer Distribution. Da es bei der Kernelentwicklung nicht nur um Freizeitbeschäftigung geht, wird es eine genügend andere Motivationen für spezielle Kernelanpassungen geben.

Gruß Peter

Ausgerechnet bei OpenSUSE von Stabilitaet zu reden die treffgenau immer einen EOL Kernel auf die DVDs brennen hat schon was ... Es ist ja nicht so dass es keine longterm (stable) releases auf www.kernel.org gaebe. Das erste das ich von fast jeder neu installierten SuSE bisher ausgewechselt habe ist der Kernel - seit Jahren. -- 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

Wilhelm Boltz

17:53

Hallo Stephan, Am Sonntag, 2. August 2015, 18:12:33 schrieb Stephan von Krawczynski:

...

On Sun, 2 Aug 2015 14:10:43 +0200

Peter Mc Donough wrote:

...
Am 02.08.2015 um 13:09 schrieb Stephan von Krawczynski:

...
On Sun, 2 Aug 2015 00:27:33 +0200

Peter Mc Donough wrote:

...
Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...
On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: [...]

...

Ausgerechnet bei OpenSUSE von Stabilitaet zu reden die treffgenau immer einen EOL Kernel auf die DVDs brennen hat schon was ... Es ist ja nicht so dass es keine longterm (stable) releases auf www.kernel.org gaebe. Das erste das ich von fast jeder neu installierten SuSE bisher ausgewechselt habe ist der Kernel - seit Jahren.

Nimmst Du dafür dieses Repo: http://download.opensuse.org/repositories/Kernel:/stable/standard/ Muss man sich da noch um patches kümmern, oder läuft der aus der Tüte - für den Normalanwender? Danke im voraus! Gruß Willi -- openSUSE 13.2 (Harlequin) (x86_64) GNU/Linux 3.16.7-21-desktop KDE 4.14.8 -- 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

Stephan Hemeier

18:02

Am Sonntag, 2. August 2015, 19:53:50 schrieb Wilhelm Boltz:

...

Hallo Stephan,

Am Sonntag, 2. August 2015, 18:12:33 schrieb Stephan von

Krawczynski:

...
On Sun, 2 Aug 2015 14:10:43 +0200

Peter Mc Donough wrote:

...
Am 02.08.2015 um 13:09 schrieb Stephan von Krawczynski:

...
On Sun, 2 Aug 2015 00:27:33 +0200

Peter Mc Donough wrote:

...
Am 01.08.2015 um 17:39 schrieb Stephan von Krawczynski:

...
On Sat, 1 Aug 2015 16:06:09 +0200 Peter Mc Donough wrote: [...]

Ausgerechnet bei OpenSUSE von Stabilitaet zu reden die treffgenau immer einen EOL Kernel auf die DVDs brennen hat schon was ... Es ist ja nicht so dass es keine longterm (stable) releases auf www.kernel.org gaebe. Das erste das ich von fast jeder neu installierten SuSE bisher ausgewechselt habe ist der Kernel - seit Jahren.

Nimmst Du dafür dieses Repo: http://download.opensuse.org/repositories/Kernel:/stable/standard/

Muss man sich da noch um patches kümmern, oder läuft der aus der Tüte - für den Normalanwender?

Danke im voraus!

Gruß Willi Du bekommst alle paar Tage einen neuen Kernel automatisch, der alte wird aber aus dem Repo entfernt, daher Vorsicht.

zypper up reicht, ebenso Yast---Update. Und bedenke: Die Grafikkartentreiber für Nvidia und ATI musst Du selbst mit den Dateien von deren Homepage bauen, nichts mehr mit Repo. Ebenso funktionieren alle vorkompilierten Kernel Module a la z.B. broadcom-wl nicht mehr, die sind alle gegen Kernel 3.16 gebaut. -- 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

Wilhelm Boltz

20:03

Am Sonntag, 2. August 2015, 20:02:07 schrieb Stephan Hemeier:

...

Am Sonntag, 2. August 2015, 19:53:50 schrieb Wilhelm Boltz:

...
Hallo Stephan,

Am Sonntag, 2. August 2015, 18:12:33 schrieb Stephan von Krawczynski:

...
[...] ist ja nicht so dass es keine longterm (stable) releases auf www.kernel.org gaebe. Das erste das ich von fast jeder neu installierten SuSE bisher ausgewechselt habe ist der Kernel - seit Jahren.

Nimmst Du dafür dieses Repo: <http://download.opensuse.org/repositories/Kernel:/stable/standa rd/>

Muss man sich da noch um patches kümmern, oder läuft der aus der Tüte - für den Normalanwender? [...]

Du bekommst alle paar Tage einen neuen Kernel automatisch, der alte wird aber aus dem Repo entfernt, daher Vorsicht.

zypper up reicht, ebenso Yast---Update.

Und bedenke: Die Grafikkartentreiber für Nvidia und ATI musst Du selbst mit den Dateien von deren Homepage bauen, nichts mehr mit Repo. Ebenso funktionieren alle vorkompilierten Kernel Module a la z.B. broadcom-wl nicht mehr, die sind alle gegen Kernel 3.16 gebaut.

Ok, danke für die Hinweise. Klingt ziemlich aufwendig. Gruß Willi -- openSUSE 13.2 (Harlequin) (x86_64) GNU/Linux 3.16.7-21-desktop KDE 4.14.8 -- 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

Stephan von Krawczynski

23:35

On Sun, 02 Aug 2015 22:03:18 +0200 Wilhelm Boltz wrote:

...

Am Sonntag, 2. August 2015, 20:02:07 schrieb Stephan Hemeier:

...
Am Sonntag, 2. August 2015, 19:53:50 schrieb Wilhelm Boltz:

...
Hallo Stephan,

Am Sonntag, 2. August 2015, 18:12:33 schrieb Stephan von Krawczynski:

...
[...] ist ja nicht so dass es keine longterm (stable) releases auf www.kernel.org gaebe. Das erste das ich von fast jeder neu installierten SuSE bisher ausgewechselt habe ist der Kernel - seit Jahren.

Nimmst Du dafür dieses Repo: <http://download.opensuse.org/repositories/Kernel:/stable/standa rd/>

Muss man sich da noch um patches kümmern, oder läuft der aus der Tüte - für den Normalanwender? [...]

Du bekommst alle paar Tage einen neuen Kernel automatisch, der alte wird aber aus dem Repo entfernt, daher Vorsicht.

zypper up reicht, ebenso Yast---Update.

Und bedenke: Die Grafikkartentreiber für Nvidia und ATI musst Du selbst mit den Dateien von deren Homepage bauen, nichts mehr mit Repo. Ebenso funktionieren alle vorkompilierten Kernel Module a la z.B. broadcom-wl nicht mehr, die sind alle gegen Kernel 3.16 gebaut.

Ok, danke für die Hinweise. Klingt ziemlich aufwendig.

Gruß Willi

Ich glaub da ist mehr der "User-Erschrecken" Faktor am Werk. Ich nehm natuerlich kein Repo von SuSE. Warum sollte ich dem trauen? Man laedt ganz einfach das gewuenschte Archiv von Kernel.org runter und entpackt es in "/usr/src/". Dann macht man einen Softlink "linux" auf das Verzeichnis und kopiert die config Datei des laufenden Kernels "zcat /proc/config.gz >/usr/src/linux/.config Sodann ins Verzeichnis "linux" wechseln" und "make menuconfig" aufrufen. Man sollte dann (das erste Mal) unter dem Punkt "General Setup" die "local version" loeschen, das ist das schoene Kuerzel das hinten an den SUSE-Kernel-Versionsnummern dranhaengt. Sodann "exit" und mit "make -j <cpu-anzahl>" compilieren, "make modules_install" und dann "make install". Danach booten und fertig. Ich sags ganz offen: wer einen binary-only Kernel-Treiber benutzt (z.b. fuer eine supertolle teure Grafikkarte) hat verloren. Uebrigens: Hardware deren einziger Treiber ausgerechnet gegen Kernel 3.16 gebaut ist sollte man sowieso nicht kaufen, denn 3.16 ist schon lange EOL. Das bedeutet dann der Hersteller interessiert sich gar nicht fuer Linux. Ein einfacher Intel NUC wuerde z.b. einwandfrei funktionieren (um mal etwas Werbung fuer die Guten zu machen ;-) -- 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

Peter Mc Donough

3 Aug 3 Aug

11:37

Am 03.08.2015 um 01:35 schrieb Stephan von Krawczynski:

...

On Sun, 02 Aug 2015 22:03:18 +0200 Wilhelm Boltz wrote:

...

...
... Ok, danke für die Hinweise. Klingt ziemlich aufwendig.

Ich glaub da ist mehr der "User-Erschrecken" Faktor am Werk. Ich nehm natuerlich kein Repo von SuSE. Warum sollte ich dem trauen?

Man laedt ganz einfach das gewuenschte Archiv von Kernel.org runter und entpackt es in "/usr/src/". Dann macht man einen Softlink "linux" auf das Verzeichnis und kopiert die config Datei des laufenden Kernels "zcat /proc/config.gz >/usr/src/linux/.config Sodann ins Verzeichnis "linux" wechseln" und "make menuconfig" aufrufen. Man sollte dann (das erste Mal) unter dem Punkt "General Setup" die "local version" loeschen, das ist das schoene Kuerzel das hinten an den SUSE-Kernel-Versionsnummern dranhaengt. Sodann "exit" und mit "make -j <cpu-anzahl>" compilieren, "make modules_install" und dann "make install". Danach booten und fertig.

Da hast du aber mehrere ;-) ;-) ;-) vergessen. Das ist etwas für diejenigen, die glauben, sie hätten damit die Kontrolle über die ca. 10GB Programme, Treiber und Libraries auf dem Rechner. Was bringt dich außerdem auf die Idee, dass die Leute von Kernel.org zuverlässiger sein sollen, als diejenigen, die bei der Distrozusammenstellung werken, abgesehen davon, dass einige zum Brötchen verdienen sicher in beide Sektionen tätig sind.

...

Ich sags ganz offen: wer einen binary-only Kernel-Treiber benutzt (z.b. fuer eine supertolle teure Grafikkarte) hat verloren.

Für die supertolle Hardware brauchst du bei jedem Betriebssystem einen Herstellertreiber und bist für die Zusammenarbeit des Herstellers mit den Kernel-Leuten dankbar, wenn sie denn stattfindet.

...

Uebrigens: Hardware deren einziger Treiber ausgerechnet gegen Kernel 3.16 gebaut ist sollte man sowieso nicht kaufen, denn 3.16 ist schon lange EOL.

Nur gegen einen bestimmten Kernel compiliert. Kann ich mir nicht vorstellen, im Zweifelsfall nicht für, sondern ab eine bestimmten Kernelversion. Da ist übrigens der Vorteil von Linux. Im Prinzip kannst du ja den Kernel mit dem Treiber neu kompilieren, sofern(??) von Letzterem der Quellcode vorliegt.

...

Das bedeutet dann der Hersteller interessiert sich gar nicht fuer Linux. ...

Welcher Hersteller von Consumerprodukten interessiert sich denn für Linux. Da fällt mit nur HP bei Druckern ein. Gruß Peter -- 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

Stephan von Krawczynski

12:50

On Mon, 3 Aug 2015 13:37:48 +0200 Peter Mc Donough wrote:

...

Am 03.08.2015 um 01:35 schrieb Stephan von Krawczynski:

...
On Sun, 02 Aug 2015 22:03:18 +0200 Wilhelm Boltz wrote:

...
...
... Ok, danke für die Hinweise. Klingt ziemlich aufwendig.

Ich glaub da ist mehr der "User-Erschrecken" Faktor am Werk. Ich nehm natuerlich kein Repo von SuSE. Warum sollte ich dem trauen?

Man laedt ganz einfach das gewuenschte Archiv von Kernel.org runter und entpackt es in "/usr/src/". Dann macht man einen Softlink "linux" auf das Verzeichnis und kopiert die config Datei des laufenden Kernels "zcat /proc/config.gz >/usr/src/linux/.config Sodann ins Verzeichnis "linux" wechseln" und "make menuconfig" aufrufen. Man sollte dann (das erste Mal) unter dem Punkt "General Setup" die "local version" loeschen, das ist das schoene Kuerzel das hinten an den SUSE-Kernel-Versionsnummern dranhaengt. Sodann "exit" und mit "make -j <cpu-anzahl>" compilieren, "make modules_install" und dann "make install". Danach booten und fertig.

Da hast du aber mehrere ;-) ;-) ;-) vergessen.

Das ist etwas für diejenigen, die glauben, sie hätten damit die Kontrolle über die ca. 10GB Programme, Treiber und Libraries auf dem Rechner.

Es geht eher weniger um Kontrolle. Es geht vielmehr um _langfristige_ Stabilitaet. Sowas hier: # uptime 14:48pm up 616 days 23:14, 4 users, load average: 5.72, 5.62, 5.46

...

Was bringt dich außerdem auf die Idee, dass die Leute von Kernel.org zuverlässiger sein sollen, als diejenigen, die bei der Distrozusammenstellung werken, abgesehen davon, dass einige zum Brötchen verdienen sicher in beide Sektionen tätig sind.

Es ist schwer das zu formulieren ohne dass sich jemand schwach angeredet fuehlt. Die einfache Wahrheit ist dass der Kernel eben von Leuten gemacht wird die ihn dann auf kernel.org auf die Menschheit loslassen. Die Kernel-Leute bei Distributionen sind eher "Patcher". Man hat sich mal auf die (falsche) Idee eingelassen dass die Kernel-Version gleich bleiben muss und muss deshalb staendig Sachen nachpatchen die in dem jeweils neueren kernel.org Tree eben drin sind. Diese Herangehensweise ist einfach broken-by-design.

...

...
Ich sags ganz offen: wer einen binary-only Kernel-Treiber benutzt (z.b. fuer eine supertolle teure Grafikkarte) hat verloren.

Für die supertolle Hardware brauchst du bei jedem Betriebssystem einen Herstellertreiber und bist für die Zusammenarbeit des Herstellers mit den Kernel-Leuten dankbar, wenn sie denn stattfindet.

Ich verwende seit Jahren ganze einfache und billige ATI-Karten und habe seit dem ersten Linux-Tag noch nie einen Binary-Treiber dafuer gebraucht.

...

...
Uebrigens: Hardware deren einziger Treiber ausgerechnet gegen Kernel 3.16 gebaut ist sollte man sowieso nicht kaufen, denn 3.16 ist schon lange EOL.

Nur gegen einen bestimmten Kernel compiliert. Kann ich mir nicht vorstellen, im Zweifelsfall nicht für, sondern ab eine bestimmten Kernelversion.

Da ist übrigens der Vorteil von Linux. Im Prinzip kannst du ja den Kernel mit dem Treiber neu kompilieren, sofern(??) von Letzterem der Quellcode vorliegt.

Wir reden aber grade davon dass insbesondere Grafikkarten-Hersteller gerne nur Binary-only Treiber verteilen und deswegen der Allgemeinheit kein Source zur Verfuegung steht.

...

...
Das bedeutet dann der Hersteller interessiert sich gar nicht fuer Linux. ...

Welcher Hersteller von Consumerprodukten interessiert sich denn für Linux. Da fällt mit nur HP bei Druckern ein.

ATI auf jeden Fall deutlich mehr als Nvidia, und mit onboard Intel hast Du eh gewonnen.

...

Gruß Peter

Peter Mc Donough

14:31

Am 03.08.2015 um 14:50 schrieb Stephan von Krawczynski:

...

On Mon, 3 Aug 2015 13:37:48 +0200 Peter Mc Donough wrote: ...

...
...
Man laedt ganz einfach das gewuenschte Archiv von Kernel.org runter und entpackt es in "/usr/src/". Dann macht man einen Softlink "linux" ...

Da hast du aber mehrere ;-) ;-) ;-) vergessen.

Das ist etwas für diejenigen, die glauben, sie hätten damit die Kontrolle über die ca. 10GB Programme, Treiber und Libraries auf dem Rechner.

Es geht eher weniger um Kontrolle. Es geht vielmehr um _langfristige_ Stabilitaet. Sowas hier:

# uptime 14:48pm up 616 days 23:14, 4 users, load average: 5.72, 5.62, 5.46

Da macht es Sinn und Stabilität hat Vorrang für 24/7 laufende Computer. Wenn du jetzt einen Anwender hast, der aus was für welchen Gründen eine bestimmte Hardware oder Software auf seinem Rechner braucht und der gegenwärtige Kernel liefert die nicht, muss er abwägen, ob es mehr Sinn macht, den Kernel neu zu compilieren oder einfach einen neueren fertigen Kernel zu verwenden. Ich habe ein 8/1 System. Für mich ist es schlichtweg effizienter meine Zeit für die Anwendung zu verwenden, statt mich um das System zu kümmern, so lange es keine offensichtlichen Probleme verursacht

...

...

...
Was bringt dich außerdem auf die Idee, dass die Leute von Kernel.org zuverlässiger sein sollen, ....

Es ist schwer das zu formulieren ohne dass sich jemand schwach angeredet fuehlt. Die einfache Wahrheit ist dass der Kernel eben von Leuten gemacht wird die ihn dann auf kernel.org auf die Menschheit loslassen. Die Kernel-Leute bei Distributionen sind eher "Patcher". Man hat sich mal auf die (falsche) Idee eingelassen dass die Kernel-Version gleich bleiben muss und muss deshalb staendig Sachen nachpatchen die in dem jeweils neueren kernel.org Tree eben drin sind. Diese Herangehensweise ist einfach broken-by-design.

Das sehe ich z.B. bei openSuse für meine Zwecke nicht. Der ausgelieferte Kernel bleibt wie er ist, es sei denn, ein Fehler muss beseitigt werden oder es gibt einen triftigen Grund ihn zu wechseln. Die Arbeit hast du bei einem selbstcompilierten Kernel auch und musst dich zusätzlich darum kümmern, die mögliche Probleme überhaupt mitzukommen. Ich bin jetzt nicht unbedingt ein openSuse-Anhänger. Ich habe vor langer Zeit auch schon bei Debian und Ubuntu hineingeschnuppert aber nicht herausgefunden, warum ich wechseln sollte. Selbstcompiliertes ohne zwingenden Grund ist da noch viel weiter weg.

...

...
...
Ich sags ganz offen: wer einen binary-only Kernel-Treiber benutzt (z.b. fuer eine supertolle teure Grafikkarte) hat verloren.

Für die supertolle Hardware brauchst du bei jedem Betriebssystem einen Herstellertreiber und bist für die Zusammenarbeit des Herstellers mit den Kernel-Leuten dankbar, wenn sie denn stattfindet.

Ich verwende seit Jahren ganze einfache und billige ATI-Karten und habe seit dem ersten Linux-Tag noch nie einen Binary-Treiber dafuer gebraucht.

Das hängt von der Anwendung ab und ob die Grafikarte das macht, wozu du sie verwenden möchtest.

...

...
...

...
Das bedeutet dann der Hersteller interessiert sich gar nicht fuer Linux. ...

...
Welcher Hersteller von Consumerprodukten interessiert sich denn für Linux. Da fällt mit nur HP bei Druckern ein.

ATI auf jeden Fall deutlich mehr als Nvidia, und mit onboard Intel hast Du eh gewonnen.

Ich habe schon zu lange einen Computer um blind eine Firma zu glauben, dass ihre Hardware das kann, was sie behauptet. Siehe die Samsung SSD Saga. Gruß Peter -- 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

Stephan von Krawczynski

17:54

On Mon, 3 Aug 2015 16:31:21 +0200 Peter Mc Donough wrote:

...

Ich habe schon zu lange einen Computer um blind eine Firma zu glauben, dass ihre Hardware das kann, was sie behauptet. Siehe die Samsung SSD Saga.

Gruß Peter

Waerm das Thema nicht wieder auf, denn da ist keine Saga. Ich wuerde eher sagen ein Drama rund um eine Info-Meldung. Ich habe wirklich einige 840pro im Einsatz und bis heute kein einziges Problem. -- 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

Hugo Egon Maurer

19:28

Am 03.08.2015 um 19:54 schrieb Stephan von Krawczynski:

...

On Mon, 3 Aug 2015 16:31:21 +0200 Peter Mc Donough wrote:

...
Ich habe schon zu lange einen Computer um blind eine Firma zu glauben, dass ihre Hardware das kann, was sie behauptet. Siehe die Samsung SSD Saga.

Gruß Peter Waerm das Thema nicht wieder auf, denn da ist keine Saga. Ich wuerde eher sagen ein Drama rund um eine Info-Meldung. Ich habe wirklich einige 840pro im Einsatz und bis heute kein einziges Problem.

Hallo, Fakt ist:, wenn die Hardwaremafia mehr/besser mit den Linuxern zusammenarbeiten würde, dann gäbe es garantiert weniger Probleme. So müssen die Programmierer Zeit investieren um "blind" Treiber zu schreiben, das die Hardware läuft, wenn der treiber geschrieben ist und wenn es dumm läuft kommt irgendeiner von der Hardwaremafia daher und verlangt "Lizenzsteuer". Gruß Hugo -- 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

Christian Boltz

21:00

Hallo Stephan, hallo Leute, Am Montag, 3. August 2015 schrieb Stephan von Krawczynski:

...

On Mon, 3 Aug 2015 13:37:48 +0200 Peter Mc Donough wrote:

...
Am 03.08.2015 um 01:35 schrieb Stephan von Krawczynski: [...] Es geht eher weniger um Kontrolle. Es geht vielmehr um _langfristige_ Stabilitaet. Sowas hier:

# uptime 14:48pm up 616 days 23:14, 4 users, load average: 5.72, 5.62, 5.46

Zwei Jahre ohne Sicherheitsupdates. Lecker... ;-) Das kann bei Systemen, die _nur_ intern erreichbar sind, noch vertretbar sein - sobald das Ganze irgendwie am Internet hängt oder gar von außen erreichbar ist, ist mir ein Reboot zu einem Kernel mit entsprechenden Security-Fixes aber deutlich lieber als die Uptime.

...

...
Was bringt dich außerdem auf die Idee, dass die Leute von Kernel.org zuverlässiger sein sollen, als diejenigen, die bei der Distrozusammenstellung werken, abgesehen davon, dass einige zum Brötchen verdienen sicher in beide Sektionen tätig sind.

Es ist schwer das zu formulieren ohne dass sich jemand schwach angeredet fuehlt. Die einfache Wahrheit ist dass der Kernel eben von Leuten gemacht wird die ihn dann auf kernel.org auf die Menschheit loslassen. Die Kernel-Leute bei Distributionen sind eher "Patcher". Man hat sich mal auf die (falsche) Idee eingelassen dass die Kernel-Version gleich bleiben muss und muss deshalb staendig Sachen nachpatchen die in dem jeweils neueren kernel.org Tree eben drin sind. Diese Herangehensweise ist einfach broken-by-design.

Sagen wir einfach, dass beide Methoden Vor- und Nachteile haben ;-) Du siehst das Patchen wahrscheinlich als "unnötige" Arbeit, aber es hat den Vorteil, dass es ein geringeres Risiko von Regressions bei Sicherheitsupdates gibt (im Vergleich zu einer komplett neuen Kernel- Version). Daher bin ich ganz froh, dass die Kernel-Version üblicherweise über ein Release stabil bleibt und "nur" Patches eingepflegt werden. Gruß Christian Boltz --

...

Den Anwender als Betatester zu missbrauchen ist doch schon immer die Sache der Jungs aus Redmond gewesen... sorry, der Hinweis auf die Redmond-Kunden hinkt etwas. Schließlich bezahlen diese kräftig dafür, dass sie testen dürfen. [> Thomas Giese und Christian Meseberg in opensuse-de]

-- 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

Stephan von Krawczynski

23:22

On Mon, 03 Aug 2015 23:00:44 +0200 Christian Boltz wrote:

...

Hallo Stephan, hallo Leute,

Am Montag, 3. August 2015 schrieb Stephan von Krawczynski:

...
On Mon, 3 Aug 2015 13:37:48 +0200 Peter Mc Donough wrote:

...
Am 03.08.2015 um 01:35 schrieb Stephan von Krawczynski: [...] Es geht eher weniger um Kontrolle. Es geht vielmehr um _langfristige_ Stabilitaet. Sowas hier:

# uptime 14:48pm up 616 days 23:14, 4 users, load average: 5.72, 5.62, 5.46

Zwei Jahre ohne Sicherheitsupdates. Lecker... ;-)

Das kann bei Systemen, die _nur_ intern erreichbar sind, noch vertretbar sein - sobald das Ganze irgendwie am Internet hängt oder gar von außen erreichbar ist, ist mir ein Reboot zu einem Kernel mit entsprechenden Security-Fixes aber deutlich lieber als die Uptime.

Bei weitem nicht jedes System haengt am Internet, da wuerde ich mir mehr Gedanken ueber verwegene Linux-Ableger wie VMWare machen. "Sicherheitsupdates" ala 13.2 openssh ohne libwrap wuerden mir da deutlich mehr Sorgen machen.

...

...
...
Was bringt dich außerdem auf die Idee, dass die Leute von Kernel.org zuverlässiger sein sollen, als diejenigen, die bei der Distrozusammenstellung werken, abgesehen davon, dass einige zum Brötchen verdienen sicher in beide Sektionen tätig sind.

Es ist schwer das zu formulieren ohne dass sich jemand schwach angeredet fuehlt. Die einfache Wahrheit ist dass der Kernel eben von Leuten gemacht wird die ihn dann auf kernel.org auf die Menschheit loslassen. Die Kernel-Leute bei Distributionen sind eher "Patcher". Man hat sich mal auf die (falsche) Idee eingelassen dass die Kernel-Version gleich bleiben muss und muss deshalb staendig Sachen nachpatchen die in dem jeweils neueren kernel.org Tree eben drin sind. Diese Herangehensweise ist einfach broken-by-design.

Sagen wir einfach, dass beide Methoden Vor- und Nachteile haben ;-)

Du siehst das Patchen wahrscheinlich als "unnötige" Arbeit, aber es hat den Vorteil, dass es ein geringeres Risiko von Regressions bei Sicherheitsupdates gibt (im Vergleich zu einer komplett neuen Kernel- Version). Daher bin ich ganz froh, dass die Kernel-Version üblicherweise über ein Release stabil bleibt und "nur" Patches eingepflegt werden.

Gruß

Christian Boltz

_Das_ halte ich fuer einen grossen Irrtum. Ob ein Patch der meist "backported" sein muss wirklich sonst keine Auswirkungen hat laesst sich nicht ohne Weiteres immer sagen. Im Gegensatz zu kernel.org hat eine Distribution keine einfache Moeglichkeit eine neue Version auf breiter Front zu testen. Wie man hier auch sehen kann werden die meisten Updates ja auf Leute losgelassen mit begrenzten Test-Moeglichkeiten und -Faehigkeiten. Die Feedback-Basis ist also dramatisch verkleinert. Es waere jedenfalls ganz erheblich besser wenn man wenigstens longterm Kernel Releases nehmen wuerde und nicht EOL-Versionen. Das ganze ist im derzeitigen Status mehr eine ABM-Massnahme als sinnvolle Arbeit. -- 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

Wilhelm Boltz

4 Aug 4 Aug

07:40

Hallo Stephan, Am Montag, 3. August 2015, 01:35:52 schrieb Stephan von Krawczynski:

...

On Sun, 02 Aug 2015 22:03:18 +0200

...
...
...
...
[...] Ich glaub da ist mehr der "User-Erschrecken" Faktor am Werk. Ich nehm natuerlich kein Repo von SuSE. Warum sollte ich dem trauen?

Man laedt ganz einfach das gewuenschte Archiv von Kernel.org runter und entpackt es in "/usr/src/". Dann macht man einen Softlink "linux" auf das Verzeichnis und kopiert die config Datei des laufenden Kernels "zcat /proc/config.gz

...
/usr/src/linux/.config Sodann ins Verzeichnis "linux" wechseln" und "make menuconfig" aufrufen. Man sollte dann (das erste Mal) unter dem Punkt "General Setup" die "local version" loeschen, das ist das schoene Kuerzel das hinten an den SUSE-Kernel-Versionsnummern dranhaengt. Sodann "exit" und mit "make -j <cpu-anzahl>" compilieren, "make modules_install" und dann "make install". Danach booten und fertig.

Ich sags ganz offen: wer einen binary-only Kernel-Treiber benutzt (z.b. fuer eine supertolle teure Grafikkarte) hat verloren. Uebrigens: Hardware deren einziger Treiber ausgerechnet gegen Kernel 3.16 gebaut ist sollte man sowieso nicht kaufen, denn 3.16 ist schon lange EOL. Das bedeutet dann der Hersteller interessiert sich gar nicht fuer Linux. Ein einfacher Intel NUC wuerde z.b. einwandfrei funktionieren (um mal etwas Werbung fuer die Guten zu machen ;-)

vielen Dank für die Erläuterung. PM wäre nicht nötig gewesen, ich lese die Liste. Gruß Willi -- openSUSE 13.2 (Harlequin) (x86_64) GNU/Linux 3.16.7-21-desktop KDE 4.14.8 -- 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

David Haller

3 Aug 3 Aug

08:00

Hallo, Am Sat, 01 Aug 2015, Stephan von Krawczynski schrieb:

...

Peter Mc Donough wrote: [..]

...
Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Sorry, aber Du hast wohl den Vorgang nicht komplett gelesen. Wenn Du die _Loesung_ dieses Problems verfolgt haettest, dann waere Dir aufgefallen, dass es sich _nicht_ um ein TRIM-Problem der Platte handelte sondern um einen klaren Bug im Kernel,

Schwachsinn. Wenn man keine Ahnung hat, einfach mal die Fresse halten! Die SSD 840/850 lügen über das, was sie können. Sie behaupten sie könnten TRIM mit NCQ, tun's aber nicht. Vgl. z.B. https://bugzilla.kernel.org/show_bug.cgi?id=72341 # smartctl --identify=w /dev/sdX [..] 77 6 1 RECEIVE/SEND FPDMA QUEUED supported Hier behauptet die SSD sie könnte es, tut es aber nicht. Firmware Bug. Die SSD sollte einfach nicht darüber lügen, was sie kann und was nicht. Daß der Linux Kernel sich erstmal darauf verläßt, was die SSD behauptet ist vollkommen korrekt. Und inzwischen gibt's auch nen Patch, der alle SSD 8xx auf die Blacklist setzt (d.h. auf die, daß NCQ und TRIM nicht gleichzeitig gehen). Da ich selber eine davon habe: die 830er Serie hat das Problem nicht! # smartctl --identify=w /dev/sda 77 - 0x0004 Serial ATA additional capabilities 77 3:1 0x2 Current Serial ATA signal speed Meine 830 behauptet eben nicht, TRIM via NCQ zu können. Und jetzt, Krawallczinsky, kriech wieder unter deinen Stein! -dnh -- The problem with sendmail is not that it has too few features. -- Alan J Rosenthal, in alt.sysadmin.recovery -- 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

Stephan Hemeier

1 Aug 1 Aug

19:35

Am Samstag, 1. August 2015, 16:06:09 schrieb Peter Mc Donough:

...

Hi,

nach langem Zögern habe ich mir eine SSD bestellt, man gönnt sich ja sonst nix. Die Wahl fiel auf die Samsung 850 EVO 250GB, hauptsächlich wegen der fünf Jahre Garantie. Alternativ wäre auch eine Crucial ... BX 250GB in Frage gekommen.

Nun lese ich, dass die Samsung SSDs eine Problem mit TRIM haben sollen.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ Das ist nicht die einzige Quelle, andere berichten ebenfalls von Problemen, auch mit Samsung Consumer SSDs.

Nach Hinweisen fand ich bei bei meinem Opensuse 4.2 64bit, Kernel 3.16.7-21 in

/usr/src/linux-3.16.7-21/drivers/ata/libata-core.c

dass zumindest Cruicial auf einer Blacklist steht und der Eintrag vermutlich dem Kernel sagt, wie er damit umgehen soll.

* 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, },

Ein vergleichbarer Eintrag wäre sicher für Selbstcompilerer interessant, zu denen rechne ich mich nicht, wer weiß, was er beim nächsten Kernelupdate anrichten würde.

Regelmäßiges TRIM an sich soll ja für die SSD-Performance wichtig sein Gesucht ist eine update-resistente Möglichkeit TRIM zu verwenden, ohne sich einen Datenverlust einzuhandeln.

Tipps?

Gruß Peter Ich habe auch so eine Platte, als erstes hab ich eine aktuelle Firmware aufgespielt un d es läuft alles wunderbar. -- 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

Peter Mc Donough

21:54

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.

Das ist gut. Welchen Kernel verwendet dein System? Ich zitiere aus einen Posting auf meine (die gleiche) Frage in de/de.comp.os.unix.linux.misc 01.08.2015 17:55 "Das ist ein kernel-Problem, das erst nach 4.0 gelöst wurde. Im Debian wurde auf den Patch im Bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793612 hingewiesen." Gruß Peter -- 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

Stephan Hemeier

2 Aug 2 Aug

07:41

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.

Das ist gut.

Welchen Kernel verwendet dein System?

Ich zitiere aus einen Posting auf meine (die gleiche) Frage in de/de.comp.os.unix.linux.misc 01.08.2015 17:55

"Das ist ein kernel-Problem, das erst nach 4.0 gelöst wurde. Im Debian wurde auf den Patch im Bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793612 hingewiesen."

Gruß Peter Kernel 4.1 aus kernel:stable -- 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

Peter Mc Donough

10:22

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? 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!

...

...
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? Gruß Peter -- 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

Manfred Kreisl

11:45

Hallo Peter, Am 02.08.2015 um 12:22 schrieb Peter Mc Donough:

...

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?

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!

...
...
Welchen Kernel verwendet dein System? ...

Kernel 4.1 aus kernel:stable

Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable" ein klein wenig Eigeninitiative könnte man schon auch von dir erwarten, oder?

Eine Suche bei google nach "suse kernel repo" erbrachte gleich an erster Stelle den richtigen Treffer: http://download.opensuse.org/repositories/Kernel:/stable/standard/ Außerdem - ich habe interessehalber mich auch etwas kundig gemacht - betrifft das Softwareraid's, zumindest in den angegebenen Links ist davon die Rede. Und da Du ja 1 Laufwerk hast, ist die Diskussion hier an dieser Stelle ja sowieso überflüssig.

...

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?

Binde das Repo ein, installiere dir den gewünschten Kernel und gut ists Gruß Manfred -- 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

Peter Mc Donough

12:48

Am 02.08.2015 um 13:45 schrieb Manfred Kreisl:

...

Am 02.08.2015 um 12:22 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 09:41 schrieb Stephan Hemeier:

...
...
Welchen Kernel verwendet dein System? ... Kernel 4.1 aus kernel:stable

Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable" ein klein wenig Eigeninitiative könnte man schon auch von dir erwarten, oder?

Klar, das siehst du an dem Aufwand, den ich treibe, um herauszufinden, ob mir ein Stück Hardware nach dem Einbau vermeidbare Probleme bereiten könnte.

...

Eine Suche bei google nach "suse kernel repo" erbrachte gleich an erster Stelle den richtigen Treffer:

http://download.opensuse.org/repositories/Kernel:/stable/standard/

Du bist noch jung und mutig;-). Diesen Link hatte ich vor der 13.2 eingebunden. Er ist aber aus dem Repositoryverzeichnis von Suse verschwunden und ich als vorsichtiger Mensch versuche mich schlau zu machen, bevor ich ein Repo in mein stabil laufendes System einbinde. [...]

...

Außerdem - ich habe interessehalber mich auch etwas kundig gemacht - betrifft das Softwareraid's, zumindest in den angegebenen Links ist davon die Rede. Und da Du ja 1 Laufwerk hast, ist die Diskussion hier an dieser Stelle ja sowieso überflüssig.

Wie geschrieben, jung und mutig. Samsung gibt eine Garantie von 5 Jahren. Wer weiß schon jetzt, wie die SSD noch verwendet werden wird. Folgerichtig müsste ich auf der SSD vermerken: Hier Fehlersuchen bei Verwendung in Softwareraids. In anderen Worten, so etwas macht man nur, wenn es keine Alternative gibt.

...

...
Könntes du in (vermutlich) /usr/src/linux-4.1.???/drivers/ata/libata-core.c ob bei ...

Binde das Repo ein, installiere dir den gewünschten Kernel und gut ists

Also mit dem AMD-Catalyst Treiber von Sebastian Siebert gibt es keine Probleme. Und wenn ich schon herausgefunden hätte, ob Virtualbox auch schon mit ihm zusammenarbeitet, wäre ich ein Stück weiter. Wie du siehst, so einfach ist das nicht. Mann spart sich viel Arbeit, wenn man einen neuen Kernel erst installiert, wenn man sich voraussichtlich keine Konflikte einhandelt. Aber ich hoffe auf Stephan, der ihn schon auf seinem Rechner hat, zusammen mit einer Samsung SSD und sicher auch wissen will, ob im verborgenen ein Problem wartet, das erst zuschlägt, wenn er den Rechner dringend braucht. Gruß Peter -- 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

Peter Mc Donough

13:39

Am 02.08.2015 um 14:48 schrieb Peter Mc Donough:

...

Am 02.08.2015 um 13:45 schrieb Manfred Kreisl:

...
Am 02.08.2015 um 12:22 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 09:41 schrieb Stephan Hemeier:

...
...
Welchen Kernel verwendet dein System? Kernel 4.1 aus kernel:stable

Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable" ein klein wenig Eigeninitiative könnte man schon auch von dir erwarten, oder? ...

Eine Suche bei google nach "suse kernel repo" erbrachte gleich an erster Stelle den richtigen Treffer:

http://download.opensuse.org/repositories/Kernel:/stable/standard/

Du bist noch jung und mutig;-). Diesen Link hatte ich vor der 13.2 eingebunden. Er ist aber aus dem Repositoryverzeichnis von Suse verschwunden ...

Ergänzung: Bei Tumbleweed is "stable" aufgelistet, jedoch nicht unter 13.2 Das wäre nicht das richtige Repo für die 13.2 oder ich verstehe nicht die Repo-Ordnung. Gruß Peter -- 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

Stephan Hemeier

15:12

Am Sonntag, 2. August 2015, 15:39:10 schrieb Peter Mc Donough:

...

Am 02.08.2015 um 14:48 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 13:45 schrieb Manfred Kreisl:

...
Am 02.08.2015 um 12:22 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 09:41 schrieb Stephan Hemeier:

...
...
Welchen Kernel verwendet dein System?

Kernel 4.1 aus kernel:stable

Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable"

ein klein wenig Eigeninitiative könnte man schon auch von dir erwarten, oder?

...

...
Eine Suche bei google nach "suse kernel repo" erbrachte gleich an erster Stelle den richtigen Treffer:

http://download.opensuse.org/repositories/Kernel:/stable/standard/

Du bist noch jung und mutig;-). Diesen Link hatte ich vor der 13.2 eingebunden. Er ist aber aus dem Repositoryverzeichnis von Suse verschwunden ...

Ergänzung: Bei Tumbleweed is "stable" aufgelistet, jedoch nicht unter 13.2

Das wäre nicht das richtige Repo für die 13.2 oder ich verstehe nicht die Repo-Ordnung.

Gruß Peter Zu kernel:stable: Es gibt nur ein Repo für alle openSUSE Versionen.

Und ich habe mich vertan, bei mir ist es eine 840. Die habe ich mit einem USB-Stick nach Anleitung foldgender Seite mit einer neuen Firmware versorgt: https://www.content-space.de/dokuwiki/blog/2012/updating_a_samsung_ssd_840_f... -- 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

Stephan Hemeier

15:20

Am Sonntag, 2. August 2015, 17:12:58 schrieb Stephan Hemeier:

...

Am Sonntag, 2. August 2015, 15:39:10 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 14:48 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 13:45 schrieb Manfred Kreisl:

...
Am 02.08.2015 um 12:22 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 09:41 schrieb Stephan Hemeier:

...
> Welchen Kernel verwendet dein System?

Kernel 4.1 aus kernel:stable

Welches Repository hast du eingebunden. Bei "download" finde ich keines mit "kernel:stable"

ein klein wenig Eigeninitiative könnte man schon auch von dir erwarten, oder?

...

...
Eine Suche bei google nach "suse kernel repo" erbrachte gleich an erster Stelle den richtigen Treffer:

http://download.opensuse.org/repositories/Kernel:/stable/standard/

Du bist noch jung und mutig;-). Diesen Link hatte ich vor der 13.2 eingebunden. Er ist aber aus dem Repositoryverzeichnis von Suse verschwunden ...

Ergänzung: Bei Tumbleweed is "stable" aufgelistet, jedoch nicht unter 13.2

Das wäre nicht das richtige Repo für die 13.2 oder ich verstehe nicht die Repo-Ordnung.

Gruß Peter

Zu kernel:stable: Es gibt nur ein Repo für alle openSUSE Versionen.

Und ich habe mich vertan, bei mir ist es eine 840.

Die habe ich mit einem USB-Stick nach Anleitung foldgender Seite mit einer neuen Firmware versorgt: https://www.content-space.de/dokuwiki/blog/2012/updating_a_samsung_ssd_840_f irmware_with_linux Ich meinte natürlich die SSD 840.

Für die SSD 850 gibt es kein firmware Update. http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/su... -- 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

Peter Mc Donough

16:31

Am 02.08.2015 um 17:20 schrieb Stephan Hemeier:

...

Am Sonntag, 2. August 2015, 17:12:58 schrieb Stephan Hemeier:

...
Am Sonntag, 2. August 2015, 15:39:10 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 14:48 schrieb Peter Mc Donough: ... Ergänzung: Bei Tumbleweed is "stable" aufgelistet, jedoch nicht unter 13.2 Das wäre nicht das richtige Repo für die 13.2 oder ich verstehe nicht die Repo-Ordnung. ... Zu kernel:stable: Es gibt nur ein Repo für alle openSUSE Versionen.

Whop, dieses Problem gelöst.

...

...
Und ich habe mich vertan, bei mir ist es eine 840.

... Für die SSD 850 gibt es kein firmware Update. http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/su...

Danke, noch besser und wenn du mich ganz happy machen willst, sieh doch einmal unter /usr/src/linux-4.1.was.auch.immer/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, was ich vermute. Gruß Peter -- 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

Stephan Hemeier

17:28

Am Sonntag, 2. August 2015, 18:31:33 schrieb Peter Mc Donough:

...

Am 02.08.2015 um 17:20 schrieb Stephan Hemeier:

...
Am Sonntag, 2. August 2015, 17:12:58 schrieb Stephan Hemeier:

...
Am Sonntag, 2. August 2015, 15:39:10 schrieb Peter Mc Donough:

...
Am 02.08.2015 um 14:48 schrieb Peter Mc Donough: ...

...
...
...
Ergänzung: Bei Tumbleweed is "stable" aufgelistet, jedoch nicht unter 13.2 Das wäre nicht das richtige Repo für die 13.2 oder ich verstehe nicht die Repo-Ordnung.

... Zu kernel:stable: Es gibt nur ein Repo für alle openSUSE Versionen.

Whop, dieses Problem gelöst.

...
...
Und ich habe mich vertan, bei mir ist es eine 840.

...

Für die SSD 850 gibt es kein firmware Update. http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/ support/downloads.html Danke, noch besser und wenn du mich ganz happy machen willst, sieh doch einmal unter

/usr/src/linux-4.1.was.auch.immer/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, was ich vermute.

Gruß Peter { "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |

Kernel: 4.1.3-7.xxxxx -- 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

Peter Mc Donough

17:32

Am 02.08.2015 um 19:28 schrieb Stephan Hemeier:

...

Am Sonntag, 2. August 2015, 18:31:33 schrieb Peter Mc Donough: ...

...

...
Danke, noch besser und wenn du mich ganz happy machen willst, sieh doch einmal unter

/usr/src/linux-4.1.was.auch.immer/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, was ich vermute.

Gruß Peter { "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |

Kernel: 4.1.3-7.xxxxx

Danke, jetzt kann es losgehen. Gruß Peter -- 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

David Haller

3 Aug 3 Aug

08:09

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, }, 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. 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. HTH, -dnh -- Der einzige echte Mann [tm] hier bin ja wohl ich :^P -- Gabriele Conrad -- 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

Stephan von Krawczynski

09:38

On Mon, 3 Aug 2015 10:09:32 +0200 David Haller wrote:

...

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

Peter Mc Donough

11:52

Am 03.08.2015 um 10:09 schrieb David Haller:

...

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: [...]

...

...
... 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, },

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.

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.

Danke für alle Antworten. Es hat sich wieder einmal bewährt, wenn man vor dem Einbau neuer Hardware sich über die Klippen schlau macht. Gruß Peter -- 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

3187

Age (days ago)

3190

Last active (days ago)

List overview

Download

33 comments

8 participants

participants (8)

Christian Boltz
David Haller
Hugo Egon Maurer
Manfred Kreisl
Peter Mc Donough
Stephan Hemeier
Stephan von Krawczynski
Wilhelm Boltz