News AMD fixt systemd- und "Destiny 2"-Fehler bei Ryzen 3000 über BIOS-Update

pipin

Administrator
Teammitglied
Mitglied seit
16.10.2000
Beiträge
24.365
Renomée
9.689
Standort
East Fishkill, Minga, Xanten
  • SIMAP Race
  • QMC Race
  • RCN Russia
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2019
  • SETI@Home Intel-Race II
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
  • BOINC Pentathlon 2023
Wie heise online meldet, wird AMD die aufgetretenen Probleme mit systemd (wir berichteten) und auch für das Spiel Destiny 2 per BIOS-Update beseitigen, das an die Mainboard-Hersteller bereits verteilt wurde und von diesen dann nur noch implementiert werden muss.
(…)

» Artikel lesen
 
Tja, jetzt ist's doch kein systemd-Fehler mehr. Wer hätte das wohl gedacht. Hätte der Schreiberling mal die Links im Heise-Artikel entsprechend verfolgt.
 
Tja, jetzt ist's doch kein systemd-Fehler mehr. Wer hätte das wohl gedacht. Hätte der Schreiberling mal die Links im Heise-Artikel entsprechend verfolgt.

Sagen wir es mal so: es haben sich hier beide Seiten nicht gerade mit Ruhm bekleckert.
Aber zumindest ist das nun aus der Welt geschafft. :)

Generell hat man als Early Adopter eigentlich immer die Arschkarte. Zahlt die höchsten Preise und bekommt auch noch einiges an Bugs oder Unzulänglichkeiten ab.
 
Solange die üblichen "Trolle" nicht wieder Ihre Kommentare ablassen nach dem Muster "AMD liefert nur fehlerhafte Hardware und Linux ist unfertiges Frickelsystem." wie es in den entsprechenden Foren auf heiße.de ab und an zu lesen ist.
 
Tja, jetzt ist's doch kein systemd-Fehler mehr. Wer hätte das wohl gedacht. Hätte der Schreiberling mal die Links im Heise-Artikel entsprechend verfolgt.
Das eine schließt doch das andere nicht aus!
Fakt ist, dass systemd einfach Mist gebaut hat!

Erkläre doch einfach mal, was man mit "Random Nummern" bei einem Start Programm will!
 
Sagen wir es mal so: es haben sich hier beide Seiten nicht gerade mit Ruhm bekleckert.

Ne, systemds Vorgehensweise, RDRAND zu nutzen ist völlig o.k. wenn man nur einen Zufalls-Generator mittlerer Qualität braucht.

Das eine schließt doch das andere nicht aus!
Fakt ist, dass systemd einfach Mist gebaut hat!
Erkläre doch einfach mal, was man mit "Random Nummern" bei einem Start Programm will!

UUIDs für die generieren die die Daemons System-weit identifizieren wie es de-facto ist?
Du hast nicht ausreichend Sachverstand um die Sachze beurteilen zu können.

Theoretisch hätte /dev/urandom gereicht, das bei mangelnder Entropie einfach "arithmetischen" Zufall liefert (siehe hier, da steht sogar, dass Unix prinzipiell ausschließlich arithmetischen Zufall liefern dürfte; Linux nutzt trotzdem halt ggf. Entropie). Die UUIDs müssen ja nur unter den Daemons für jeden Systemstart jeweils eindeutig sein und nicht über alle Systemstarts hinweg. Eigentlich hätte systemd da sogar intern den primitivsten LCG-RNG nehmen können, aber wenn man das in einem generischen RNG implementiert nimmt man halt gern die höchste Qualitätsstufe die sich noch performant implementieren lässt.
 
Zuletzt bearbeitet:
Tja, jetzt ist's doch kein systemd-Fehler mehr. Wer hätte das wohl gedacht. Hätte der Schreiberling mal die Links im Heise-Artikel entsprechend verfolgt.
Ja, es sind letztendlich 2 Fehler, die zusammenkommen müssen. Zum Einen die fehlerhafte Funktion von AMD und zum Anderen die nicht befolgte Programmieranleitung.
 
Ne, systemds Vorgehensweise, RDRAND zu nutzen ist völlig o.k. wenn man nur einen Zufalls-Generator mittlerer Qualität braucht.
Ja, aber man hätte dennoch Vorkehrungen treffen können um eine Endlosschleife zu verhindern, e.g. max. 10 Versuche o.ä.
 
Ja, es sind letztendlich 2 Fehler, die zusammenkommen müssen. Zum Einen die fehlerhafte Funktion von AMD und zum Anderen die nicht befolgte Programmieranleitung.

Aha, welchen Programmierfehler hat systemd denn gemacht?
De-facto haben die jetzt nur einen Work-Around um den CPU-Fehler eingebaut.

Ja, aber man hätte dennoch Vorkehrungen treffen können um eine Endlosschleife zu verhindern, e.g. max. 10 Versuche o.ä.

Es geht nicht um die RDRAND-Eigenschaft, dass die dauerhaft CF=0 liefern kann - das ist so oder so berücksichtig.
Es geht darum, dass RDRAND ohne den BIOS-Fix eben fehlerhafter-weise CF=1 bei dauerhaftem Ergebnis ULONG_MAX liefert.
 
Aha, welchen Programmierfehler hat systemd denn gemacht?
Falls die Frage ernst gemeint ist und auf Unwissenheit beruht, suche ich noch mal danach. Wenn nicht, sag einfach, was Du denkst/meinst/willst.
Es ging darum, dass AMD in einem guide die Abfrage und Plausibilität beschrieben hat und wenn man das beachtet, dann wird man den Fehler nicht haben.
 
Falls die Frage ernst gemeint ist und auf Unwissenheit beruht, suche ich noch mal danach.

Es wurde ja gesagt, dass systemd einen Programmierfehler hatte. Den hatte es aber nicht, denn es hatte sich entsprechend der Spezifikation verhalten. Dass RDRAND auf dem 3xxx-Ryzens bei CF=1 fortlaufend ULONG_MAX liefern kann wurde nur nicht berücksichtigt, ist aber ein Fehler der CPU und nicht von systemd. Der Fix von systemd ist ein Workaround um den CPU-Fehler, d.h. der Fehler liegt nicht bei systemd.

Es ging darum, dass AMD in einem guide die Abfrage und Plausibilität beschrieben hat und wenn man das beachtet, dann wird man den Fehler nicht haben.

Nein, es geht hier nicht darum, dass RDRAND fortwährend CF=0 liefern kann; diese Eigenheit hat systemd von Anfang an korrekt behandelt.
Siehe hier:
"Apparently on some AMD CPUs RDRAND will sometimes (after a suspend/resume cycle?) report success
* via the carry flag but nonetheless return the same fixed value -1 in all cases. This appears to be
* a bad bug in the CPU or firmware. Let's deal with that and work-around this by explicitly checking
* for this special value (and also 0, just to be sure) and filtering it out. This is a work-around
* only however and something AMD really should fix properly. The Linux kernel should probably work
* around this issue by turning off RDRAND altogether on those CPUs.
"
Siehste: es geht nicht um die Besonderheit mit dem CF=0-Fall!!!
 
Zuletzt bearbeitet:
Ist kein Scherz, wurde Ende der 90er bei einem ISDN Telefon gebraucht, eine 16 bit Zufallszahl ungleich 0 für den Layer2.
Anonsten ist "(RandValue * 214013L + 2531011L) >> 16" die einfachste, aber auch voll deterministische Art, Zufallszahlen zu erzeugen.
Findet man in den Standard C Bibliotheken für rand().

Der Random Generator ist später etwas umfangreicher geworden (nicht mehr so deterministisch, mit Einbeziehung anderer Zufälle).
Ist __OS_RAND_NO_ZERO__ konfiguriert, liefert er immer noch die Antwort auf die Frage „nach dem Leben, dem Universum und dem ganzen Rest“ statt nichts zurück.

Siehe: Douglas Adams & The Hitchhiker’s Guide to the Galaxy
 
Zuletzt bearbeitet:
Ist kein Scherz, wurde Ende der 90er bei einem ISDN Telefon gebraucht, eine 16 bit Zufallszahl ungleich 0 für den Layer2.
Anonsten ist "(RandValue * 214013L + 2531011L) >> 16" die einfachste, aber auch voll deterministische Art, Zufallszahlen zu erzeugen.
Findet man in den Standard C Bibliotheken für rand().

Klar, das ist ein LCG. Aber das mit dem 42 (Herkunft ist klar) kam mir halt verdächtig vor weil das dann ja keine symmetrische Zufälligkeit mehr ist.
 
Zurück
Oben Unten