Jesterfox schrieb:
Das zumindest manche 800er Samsungs Probleme mit Queued Trim haben würd ich als gesichert betrachten, komplett unabhängig von dem Fall hier. Die Kernelpatches vom März und Mai kamen sicher nicht ohne Grund.
Ob das so unabhängig vom dem Fall hier ist, ist ja gerade die Frage, da habe ich Zweifel, denn wenn Agolia mit einem Hinweis wie letztlich dem Blogeintrag bei den Linux Leuten meldet, dürfte das für die Aufnahme in die Blacklist schon gereicht haben und zuerst wurde ja offenbar die 850 Pro ausgenommen, wie man aus Deinem Zitat in Post#44 sieht.
Jesterfox schrieb:
Es deutet auch viel auf ein Firmwareproblem hin, die 840Evo soll es ja erst seit einem Update haben...
Mit dem FW Update der 840 Evo haben sie vielleicht nur deren in deren Identify Device Daten ein Flag gestetzt, z.B. Bit 6 im Word 222 um SATA 3.1 Unterstützung zu signalisieren und damit den Fehler ausgelöst. Ohne den Patch zu kennen, bleibt das aber alles Spekulation.
MichaG schrieb:
Wo zur Hölle findet man denn das "official statement" zum angeblichen Kernel Patch von Samsung? Das würde doch mal etwas mehr Licht in die Sache bringen.
Genau, dann muss eine Seite den Fehler eingestehen, entweder die Linux Entwickler oder eben Samsungs FW Entwickler.
Piktogramm schrieb:
Holt, Samsung hat bei der UEFI Geschichte trotz Öffentlichkeit trotzdem andere Beschuldigt,
Samsung ist ein Großkonzern mit viele unterschiedlichen Abteilungen, selbst die Enterprise und die Consumer SSDs sind auch unterschiedlichen Abteilungen, wobei es mich wundert, warum nur die Samsung 8, also die Consumer SSD in der Blacklist stehen und nicht die Enterprise Modelle.
Piktogramm schrieb:
Ansonsten, die M500 hat kein Firmwareupdate bekommen, weil sie mehr oder weniger EoL war
als der Fehler festgestellt wurde.
Das stimmt nicht und hier in den News war damals bei Erscheinen der MX100 auch extra noch darauf verwiesen worden, dass die m500 weiter produziert werden würde, so wie auch bei Erscheinen der BX100 der Hinweis kam, die MX100 wäre nicht EoL. Die m500 war EoL als Crucial endlich den Bug in der FW der MX100 und m550 behoben hatte, bekannt war er ja schon länger.
Das EoL Argument wird übrigens im Thrad um die Leseschwäche der alten 840 None-Pro bei alten Daten gar nicht gerne gehört
Piktogramm schrieb:
Da Curcial ne Endkundenmarke ist und der Fehler über die Blacklist entschärft wurde ist das hinnehmbar, wenn auch nicht schön.
Nur steht auch "Micron_M500*" und "Micron_M5[15]0*" mit der MU01 in der Blacklist und Micron ist die Marke für OEM und Enterprise SSD wie die M500 DC, die damit auch geblcklistet ist.
Piktogramm schrieb:
Eine Aussage, dass der Fehler nicht in der Firmware liegt lässt dieser Sachverhalt nicht zu.
Dazu steht im Update vom 17.07. im Blog:
Samsung had a concrete conclusion that the issue is not related to Samsung SSD or Algolia software but is related to the Linux kernel.
Solange das Gegenteil nicht bewiesen ist, ist diese Aussage auch Teil des Sachverhalts, oder etwa nicht nur weil Du Samsung nicht magst?
Piktogramm schrieb:
Entsprechend bleibe ich dabei, ich traue Samsung nicht, solang die das Problem nicht spezifisch benennen und verorte das Problem solang nach aller Wahrscheinlichkeit bei den SSDs von Samsung.
Die
Intel DC S3500,
DC S3600 und
DC S3700 sind nur SATA 3.0 und nicht 3.1 konform, die haben aber laut Datenblatt 0x101F im Word 222 der Identify Device Data und die unteren Bit bedeuten:
6: Supports SATA Rev 3.1
5: Supports SATA Rev 3.0
4: Supports SATA Rev 2.6
3: Supports SATA Rev 2.5
2: Supports SATA II: Extensions
1: Supports SATA 1.0a
0: Supports ATA8-APT ATA8-AST
Intel setzt nur die Bits 0,1,2,3 und 4, nicht einmal Bit 5 welches den Support der SATA 3.0 Norm kennzeichnet, die werden als von Linux nicht wie SATA 3.0 SSDs mit den Features der 3.0er Revision behandelt, auch wenn die physikalisch natürlich diese Geschwindigkeit haben und erreichen.
Also warum hat Intel das macht? Die Datenblatter sagen klar "- SATA Revision 3.0; compatible with SATA 6Gb/s, 3Gb/s and 1.5Gb/s interface rates", wieso geben die Controller aber das Bit 5 beim Wird 222 mit dem sie das auch dem OS mitteilen dann nicht als 1 aus? Das ist
bei den Nachfolgern DC S3710 nicht anders. Sind die wirklich so, oder wurden die Datenblätter genau an der Stelle einen seid der 320er nicht upgedatet, sonst aber überall?
Dann hat bei denen Intel das Word 105 "Maximum number of 512-byte blocks of LBA Range Entries per DATA SET MANAGEMENT command" nur den Wert 4, bei
Microns M500 dagegen den Wert 8.
Leider gibt es bei Samsung keinen so guten Zugang zu den Datenblättern, aber ich haben eines für die SM843T und demnach sind da die dentify Device Data Word 222: 0x107F, also auch bis 5 und 6 gesetzt für Supports SATA Rev 3.0 und Supports SATA Rev 3.1 und Word 105 ist 8.
Wenn jetzt Intel den Bug kannte und statt ihn zu beheben die Werte der Identify Device Data seiner SSD so gewählt hat, dass er bei ihren SSDs nicht ausgelöst wird? Dann wäre der Blog genau die Werbung die Intel braucht um seine Marktführerschaft im lukrativen Enterprise SSD Segment zu behaupten, denn Broken SSDs: Samsung Working SSDs: Intel, mehr kann sich deren Werbung doch nicht wünschen und wenn es darum geht die eigene Marktstellung zu behaupten und zu stärken, ist für Intel auch noch nie ein Trick zu schmutzig gewesen, frag mal AMD
Piktogramm schrieb:
Die M550 wurde zum Zeitpunkt als der Fehler auftrat noch gepflegt und hat einen Firmwarepatch bekommen, der Trim + NCQ standardkonform umsetzt und seitdem mit Linux funktioniert. Da ist dann auch der springende Punkt: "standardkonform". Daher dem Linux Kernel konnte bisher nicht nachgewiesen werden, dass er den Standard verletzt. Es bleibt also:
Linux Kernel mit standardkonformer M550 (aktualisierte Firmware) -> keine Probleme
Linux Kernel mit Samsung SSD ->Probleme
Weißt Du was Micron mit dem Patch wirklich genau gemacht hat? Wurden etwa die Identify Device Data einfach nur angepasst um einen Bug im Kernel zu umgehen, denn das nutzt den Kunden am Ende mehr, weil es sofort wirkt und nicht erst ein Update des Kernels durch die Kunden erfordert. Kannst Du das sicher ausschließen?
).
