Firmware gegen Bluescreens: SSDs von Western Digital haben Probleme unter Windows 11 24H2

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.722
Das diesjährige Windows-11-Update macht rein von der Build-Nummer 22631 (23H2) auf 26100 (24H2) einen großen Sprung nach vorne und inzwischen wurde das 24H2-Update auch bereits für alle Anwender in Form von ISO-Images freigegeben. Gleich fünf SSD-Serien von Western Digital haben mit dem neuen Windows-11-Update große Probleme, sodass das Betriebssystem mit einem Bluescreen abstürzen kann. Der Grund hierfür liegt beim Host Memory Buffer (kurz: HMB), dessen Zuweisung mit dem 24H2-Update geändert wurde. Doch zum Glück gibt es bereits Firmware-Updates, die dieses Problem aus der Welt schaffen.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
HMB haben mittlerweile viele SSDs, aber nur ein paar WD sind betroffen?
 
Wenigstens gibt es eine schnelle Lösung. Ich frage mich nur, wie das passieren konnte. Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft? Ich meine, es gibt Standards, die eingehalten werden müssen. Wenn jeder sein Süppchen kocht, dann ist Instabilität vorprogrammiert und frustriert nur. Wenn ich meine Arbeit schlampig machen würde, dann war es mit meinem Job. Das ärgert mich, weil bei jeder Installation von Patches/Updates immer die Angst mitschwingt, dass das System nicht richtig hochfährt oder gar abstürzt. Das darf einem standardisiertem, ins Detail vorgegebene System nicht passieren. Es kann nicht sein, dass ich im Vorfeld bei großen Updates eine Sicherungskopie oder Wiederherstellungsimage machen muss und bei evtl. Wiederherstellung unnötig Zeit verbrate. Ich bin immer noch dafür, dass Windows umsonst sein muss, weil es unfertig auf dem Markt kommt und ständig wegen irgendwas gepatcht werden muss. Der Spruch "never change a running system" kommt nicht von ungefähr.
 
Ich hab das Update erstmal für 4 Wochen pausiert - kein Bock auf Beta-Tester...

Ich hab allerdings WD Black SN850 - wußte garnicht das es die auch als "Blue" gibt...
 
Ich frage mich nur, wie das passieren konnte. Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft?
Laut golem ist wohl folgendes passiert:
Dies klingt jetzt erstmal, als wäre MS schuld, wie können sie einfach mehr als 64MB erlauben, aber tatsächlich sieht meines Wissens nach die Spezifikation kein Limit von 64MB vor, dies war einfach so der übliche Höchstwert den die Betriebssystem für HMB erlaubt haben. SSDs die HMB nutzen, identifizieren dafür zwei Werte, einen Mindestwert wie viel sie mindestens haben wollen und einen Optimalwert, wie viel sie am liebsten hätten. Der Host (also hier Windows) entscheidet dann ob er einen HMB mit einer Größe im Bereich dieser beiden Werte anbietet oder gar keinen HMB zuteilt.

Mit diesem Wissen wird dann klar, dass WD hier die Schuld hatte, die haben offenbar einen Bug in ihrer FW gehabt der dazu geführt hat, dass die SSD mehr als 64MB HMB als Optimalwert angefordert hat, dann aber offenbar nicht mit so viel HMB umgehen konnte, vermutlich weil sie das beim Testen nie testen konnten, da ja vor 24H2 alle Betriebssystem maximal 64MB HMB zugewiesen haben.
Ich hab allerdings WD Black SN850 - wußte garnicht das es die auch als "Blue" gibt...
Die Blue wäre die SN580. Die SN850 und SN850X haben einen DRAM Cache und nutzen daher kein HMB, sind also von dem Problem nicht betroffen.
 
..der "Bug" ist kein Bug sondern einfach nur hausgemacht:

wd hmb-bug.png


Daher auch WD Firmware Refresh. Man sollte halt nicht mehr fordern wollen als das System vorgibt nur weil man denkt: Mehr würde mehr bringen. Bringt nur mehr Bugs. (y)

Abhilfe bringt da nur, reg DW auf 0 (aus) oder 3 (FW Setup) setzen.
 
Man sollte halt nicht mehr fordern wollen als das System vorgibt nur weil man denkt: Mehr würde mehr bringen.
Mehr würde schon mehr bringen, da man ja dann einen größeren Teil der Mappingtabelle dort unterbringen kann. Man sollte aber eben dann auch so viel HMB korrekt verwalten können, wenn man schon so viel anfragt. Man darf so viel anfragen wie man will, wenn man zu viel als Minimum anfordert, wird man am Ende keinen HMB bekommen und sonst bekommt man eben einen HMB dessen Größe Minimum Size oder Preferred Size oder irgendwas dazwischen ist und muss dann damit umgehen können. Die Fikwot macht es sich einfach, denn indem bei ihr der Minimum und der Preferred Size gleich sind, muss sie nur mit einem HMB von genau dieser Größe oder ganz ohne HMB arbeiten können, die WD muss dagegen mit einer ganzen Bandbreite unterschiedlicher HMB Größen umgehen können.
 
Nur zum Teil richtig.

WD hat selbst in umfangreichen HMB Workflow studies (RU 17) die L2P Tables bei 16MB mit 98,6% Adressierung abgedeckt.
100% wurden dabei schon mit 38MB erreicht die 40MB der Fikwot ist absolut deckend. Wenn WD da 200MB adressieren möchte ist das oversized^10 und sorgt nur für Troubles wie man sieht.

The results were quite intriguing. When as little as 16MB of host RAM was allocated as HMB,
the results showed that there was almost no impact on user experience. Specifically, for all
workloads tested, 95% of all activities experienced no loss of performance. Additionally, 98% of
most typical use cases such as installing software, copying files/folders, and general
productivity for office users had no performance degradation whatsoever.
 
Zuletzt bearbeitet:
Mal zum generellem Verständnis:
Wenn die (bis zu) 200MB im volatilem Ram zwischengespeichert werden, bevor sie auf die SSD geschrieben werden, sind die doch im Falle eines Stromausfalls weg und soo ein "Cache" ohne USV oder battery backup damit reichlich unklug?
 
Machen die ja nicht. Der Fix wird den HMB @ 64MB fixen und damit ist der Bug bereinigt.

HMB Cache ist auch kein DRAM Cache. HMB speichert die Mapping Table, DRAM dazu auch Nutzerdaten.
Worstcase kann man mit beiden Caches erreichen (Stromausfall). Passiert aber so gut wie nie.

The greatest utilization of host DRAM is to cache mapping information which often only requires tens of MBs of buffer size.
 
Zuletzt bearbeitet:
WD hat selbst in umfangreichen HMB Workflow studies (RU 17) die L2P Tables bei 16MB mit 98,6% Adressierung abgedeckt.
100% wurden dabei schon mit 38MB erreicht die 40MB der Fikwot ist absolut deckend.
Das habe ich hier gefunden, aber wie vermutet, bezieht es sich auf synthetische Benchmarks:

WD_HMB_Study.png


Bei mir läuft da aber eben einiges mehr, auch VMs und nicht nur eine und gerne auch eine mit einer Datenbank. Daher gibt es bei meiner SSD regelmäßig Zugriffe über einen viel größeren Adressraum als in diesen Benchmarks und idealerweise hat der DRAM Cache 1GB RAM pro 1TB Kapazität, so dass man mit 40MB HMB dann nur einen Adressraum von 40GB abdecken kann. Gibt es regelmäßig Zugriffe über einen größeren Adressraum, wird man den Nachteil des fehlenden DRAM Cache also auch bei der Fikwot merken. Den meisten Heimanwendern mag so eine DRAM lesss NVMe SSD mit HMB ja genügen, aber wer behauptet der HMB könnte einen DRAM Cache vollständig ersetzen, der ist einfach nur unehrlich.

Anandtech hat das damals bei der BG4 mit und ohne HMB ermittelt:

BG4_HMB.png


Wie man sieht, reicht der Adressraum für den die Mappingtabelle im internen SRAM des Controllers ausreicht, gerade mal 1GB, also gerade genug für Benchmarks wie AS-SSD oder CDM in deren Defaulteinstellung. Mit HMB reicht es für einen Adressraum von 32GB, also genug für über 95% der Zugriffe der meisten Benchmark wie sie auch WD genutzt hat. Danach fallen die IOPS aber eben massiv ab, weil dann die Cache das der passende Teil der Mappingtabelle im HMB steht, halt immer geringer wird und damit immer öfter erst aus dem NAND nachgeladen werden muss. Zum Vergleich eine 970EVO mit vollem DRAM Cache:

BG4_HMB_vs_970EVO.png


Hier es eine Linie, da eben die ganze Mappingtabelle im DRAM Cache steht und es daher keinen Unterschied macht, auf welche Adresse und damit auch über welchen Adressraum zugegriffen wird. Dies wird man mit HMB so nie erreichen, außer der HMB wäre eben auch so 1GB pro 1TB Kapazität groß.
Wenn die (bis zu) 200MB im volatilem Ram zwischengespeichert werden, bevor sie auf die SSD geschrieben werden
Im HMB wird nur ein kleiner Teil der Mappingtabelle gecacht, aber keine Userdaten und HMB wird auch nur als Lesecache für die Daten der Mappingtabelle verwendet. Bei Schreibzugriffen werden die Änderungen der Mappingtabelle direkt ins NAND geschrieben und dies ist auch bei den SSD mit DRAM Cache so üblich, außer wenn sie eine Full-Power-Loss Protection haben und damit diese Änderungen auch nach einen unerwarteten Spannungsabfällen noch ins NAND zurückschreiben können. Auch der DRAM Cache ist übrigens kein Schreibcache für Userdaten, die paar Userdaten die SSD im Schreibcache halten, meist nur bis es genug sind um eine ganze Page (meist so 16k oder 32k) vollständig beschreiben zu können, halten die Controller in aller Regel in ihrem internen SRAM.

Das war schon bei Intel X-25M so, der ersten modernen Consumer SSD mit DRAM Cache:
HMB Cache ist auch kein DRAM Cache.
Doch natürlich, denn es ist ein Teil des RAMs des Rechners und wer hat hier schon einen Rechner bei dem das RAM kein DRAM ist? Steht doch sogar in dem Zitat welches du unten in dem Beitrag gemacht hast: "The greatest utilization of host DRAM is to cache mapping information"

HMB speichert die Mapping Table, DRAM dazu auch Nutzerdaten.
Blödsinn, HMB kann nur einen kleinen Bruchteil der Mappigtabelle cachen und der DRAM Cache von SSDs ist nicht als Cache für Nutzerdaten da, anderes als bei HDDs, sondern damit der Controller eben da die Mappingtabelle cache kann. Deshalb ist die Größe des DRAM Cache ja in aller Regel auch proportional zur Kapazität, da die Größe der Mappingtabelle eben auch proportional zur Kapazität ist, wenn man die optimale Datenstruktur einer flachen Tabelle verwendet. Warum eine flache Tabelle optimal ist, wird deutlich wenn man hier liest wie es vorher gemacht wurde und auf der folgenden Seite den Hinweis: "the table itself should require roughly 100MB of DRAM per 100GB of storage space on the drive itself".

Wer also behauptet eine komplette Mappingtabelle würde in den HMB passen, der zeige bitte Belege dafür und ebenso wenn jemand behauptet, bei SSDs wäre der DRAM Cache für Userdaten zuständig! Außerdem sollte alleine die Tatsache das die NVMe SSDs entweder einen DRAM Cache oder eben HMB nutzen, doch schon deutlich darauf hinweisen, dass beide für die gleichen Daten genutzt werden, sonst würde es ja Sinn machen auch beides zu haben und nicht immer nur entweder oder!
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh