Verwirrung um AGESA-Updates: AMD braucht klarere Vorgaben

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.564
Als Reaktion auf zahlreiche defekte Ryzen-7000-Prozessoren haben AMD und die Mainboard-Hersteller schnelle BIOS-Updates veröffentlicht, welche die SoC-Spannung beschränken. Diese Updates basieren allesamt noch auf der AGESA-Version 1.0.0.6. Die AGESA ist eine Programmbilbiothek, die ein Basisbaustein für das BIOS ist. AMD liefert mehr oder weniger regelmäßig neue AGESA-Versionen und verbessert darin zum Beispiel das Verhalten des Speichercontrollers.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"mit zahlreichen Bugs versehen und zudem Einschränkungen besitzen, die 192 GB an Speicher nur noch mit 4.400 MT/s arbeiten lassen"
Gut, dass ich zu der Minderheit gehöre, die nur 64GB RAM haben, die Mehrheit der USER leidet jetzt, dass sie ihre 192GB RAM nicht vollends nutzen können.:LOL::ROFLMAO:(y)
Beitrag automatisch zusammengeführt:

Ab 2026 soll ja endlich Silicon Initialization Library ( OpenSIL ) auf AMD Systemen erscheinen. AGESA tot ist vorbestimmt.
 
Der Artikel ist Top! Vielleicht bringt Ihr AMD dazu, ein wenig Licht in dieses Chaos zu bringen - Danke dafür 👍
Beitrag automatisch zusammengeführt:

Gut, dass ich zu der Minderheit gehöre, die nur 64GB RAM haben, die Mehrheit der USER leidet jetzt, dass sie ihre 192GB RAM nicht vollends nutzen können.:LOL::ROFLMAO:(y)
Beitrag automatisch zusammengeführt:

Ab 2026 soll ja endlich Silicon Initialization Library ( OpenSIL ) auf AMD Systemen erscheinen. AGESA tot ist vorbestimmt.
Wenn es nur dieser Bug wäre, würde ich auch keine Panik schieben. Aber leider gibt es wohl wesentlich mehr Bugs, wie bei einigen Asus-Usern mit AGESA 1.0.0.7, bei denen nach dem BIOS-Update kein RAM mehr erkannt wird und somit nicht mehr gebootet werden kann. Alleine das ist dann nicht mehr so lustig. Und wenn dann noch die eigentlich obligatorische Thermal-Control-Funktion nicht funktioniert (oder vielleicht sogar seit der Einführung von AM5 noch nie funktioniert hat), erst recht nicht 😉 . Jedenfalls habe ich in den ganzen Jahren noch nie eine CPU gesehen, bei der der Headspreader und das Lot geschmolzen sind! Bisher sagt man ja, das es nur wenige Fälle waren und das es nur mit dem S3-Bug zusammenhängt, aber wer weiss das schon? Vielleicht sind einfach noch nicht genug Kühler bei einem unbeaufsichtigten System ausgefallen… Man könnte ja mal versuchen, ein System ohne CPU-Kühler zu betreiben. Normalerweise throttelt die CPU dann und schaltet bei Überhitzung den Rechner ab, richtig? Verlassen würde ich mich bei AM5-CPUs aber lieber nicht darauf….Oder gab es dazu schon einen Test? Korrigiert mich dann bitte! Natürlich sind das alles nur Leaks, aber ich glaube, dass wir dazu nie eine Info von AMD bekommen werden. Die Gerichte in den USA hätten sonst wahrscheinlich Lust darauf, den Laden dann wegen Gefahr von Leib und Leben zu schliessen 😉
 
Zuletzt bearbeitet:
Also immer noch kein Fix für den Saustall...
..wenn man der Gerüchteküche glauben schenken darf, wird das auch noch ein bischen dauern.

@ Don: Ich bezweifel aber sehr, dass AMD sich vor HWLuxx "nackig" machen und ein entsprechendes Statement abgeben wird. Da hängt einfach zu viel dran. ;)
 
Also immer noch kein Fix für den Saustall...

Biose auf Basis von AGESA-Version 1.0.0.7 haben noch Beta Status, bis zur endgültigen Version werden vermutlich noch einige Fehler behoben.
Man hat sich wohl für die Betas entschieden, um die CPUs vor Defekten zu schützen, das ist ja erstmal nicht verkehrt.
 
Also immer noch kein Fix für den Saustall...
Tja, es gibt auch welche, die halten das alles für übertrieben und finden, dass man den Leaks keinen Glauben schenken darf. Ich finde, dass die Leaks mit den tatsächlichen Ereignissen plausibel übereinstimmen.
Und die Folgen müssen dann Leute, die wie Du Pech gehabt haben und betroffen sind, ausbaden. Ich fühle da mit Dir 👍
Beitrag automatisch zusammengeführt:

Biose auf Basis von AGESA-Version 1.0.0.7 haben noch Beta Status, bis zur endgültigen Version werden vermutlich noch einige Fehler behoben.
Man hat sich wohl für die Betas entschieden, um die CPUs vor Defekten zu schützen, das ist ja erstmal nicht verkehrt.
Dann hätten sie AGESA 1.0.0.6 lassen sollen! Das hat mit den neuen BIOS-Versionen schon geholfen, statt ein 1.0.0.7 zu veröffentlichen, das noch mehr Bugs mitgebracht hat! Gott sei Dank haben nicht alle Boardpartner bei dem Chaos mitgezogen!
 
Man hat sich wohl für die Betas entschieden, um die CPUs vor Defekten zu schützen, das ist ja erstmal nicht verkehrt.
Grundsätzlich gebe ich dir da recht, auch wenn ich meine, dass die Boardpartner die Empfehlungen eher zum "Selbstschutz" ihrer Hardware (Boards) anbieten anstatt wegen der CPU.
Das aufspielen macht auch Sinn, blöd ist halt nur, dass in gewissen Konstellationen dann halt wieder neue Bugs auftreten können, wo man die Schuld nun nicht bei den Boardpartnern suchen sollte.
Da hat den Bockmist definitiv AMD zu verantworten, so wie halt auch Intel in der Vergangenheit (zb. Gen12 non_K OC).

Gott sei Dank haben nicht alle Boardpartner bei dem Chaos mitgezogen!
Sehe ich genauso. (y)
 
Zuletzt bearbeitet:
in gewissen Konstellationen dann halt wieder neue Bugs auftreten können, wo man die Schuld nun nicht bei den Boardpartnern suchen sollte.

Oder sogar alte bugs nicht mal gefixt wurden bisher.
Da ist einfach eine Portion Panik mit im Spiel, ja auch seitens AMD. /:

Bin aber relativ sicher, dass AMD die "Verwirrung" aufgelöst bekommt, nur vermutlich leider nicht von einem auf den anderen Tag.
Schön ist die Situation sicher nicht aber vor Eskalation sind die User hoffentlich erst mal sicher sein, Geduld werden sie vermutlich aber noch brauchen .....
 
Zuletzt bearbeitet:
Da ist einfach eine Portion Panik mit im Spiel, ja auch seitens AMD. /:
AMD macht keine Panik. Wäre ja auch schön dumm von denen, meinst nicht auch? ;)

Aussitzen, Füße still halten und durch die Hintertür Alternativen anbieten, die zu einer Lösung der Probleme führen könnten, dass wäre die klügere Strategie.
Die Medien brauchen eh nur Themen um das Sommerloch zu füllen, decken sich eher selten mit den Interessen der Hersteller wenn dann mal was nicht so glatt läuft.
 
Zuletzt bearbeitet:
Glaube ich auch nicht wirklich. Dumm gelaufen, paar Leute bekommen da jetzt mächtig auf den Deckel, vieleicht rollen auch Köpfe aber Panik? Never!

Nur glaube ich nicht wirklich daran, dass AMD nach außen kommunizieren wird was in gewissen Teilen des Unternehmens da nun intern läuft. So doof sind die nicht. ;)
 
Glaube ich auch nicht wirklich. Dumm gelaufen, paar Leute bekommen da jetzt mächtig auf den Deckel, vieleicht rollen auch Köpfe aber Panik? Never!
Ah Junge... Sprache und Kontext....
Man hat festgestellt, das man CPUs killen kann. AMD gefällt das nicht und sie wollten schnellstmöglich einen Fix dafür rausgeben -> Kurzschlusshandlung aka Panik. Das heisst nicht, das jetzt jeder einzelne Mitarbeiter panisch im Bürogebäude rumläuft.
 
Nicht wollten -> mussten. Und wie schon erwähnt, dass dient, meiner Meinung nach, vorrangig den Boardpartnern intern zum "Selbstschutz".
Nicht weil AMD einen caritativen Grundgedanken seinen Käufern ggü. verpflichtet ist (das sind die höchstens ihren Aktionären gegenüber).
 
@Don
Können AM5 Platinen überhaupt schon mit den neuen Speichervolumen umgehen?
In einem Test zu 2x 24GB Speicherriegel wird geschrieben, dass es mit AGESA 1.0.0.6 noch nicht möglich sei.
 
Nur weil die Programmbibliothek anders heißt, muss das ja nicht heißen, dass die Hersteller damit dann besser umgehen was die Kommunikation betrifft ;)
OpenSIL wäre dann Open Source unter MIT Lizenz. Somit wäre (in Fachkreisen) kein Rätselraten mehr nötig, welche Features / Änderungen jetzt in welchem Release enthalten sind oder nicht. Und der allgemeine Cargo Cult um AGESA Versionen etc. würde sich hoffentlich auch endlich auflösen. (Vermutlich nicht, aber man kann ja hoffen…)

Was die Kommunikation von Boardherstellern an Endkunden betrifft sollten sich letztere eh nicht mit Details wie der AGESA Version befassen müssen.
Hier sollten die Hersteller imo in der Form „Wir haben Änderung X durchgeführt, was für Nutzer Auswirkungen YZ hat.“ kommunizieren. Und damit meine ich Konkrete Informationen, nicht so generische Nichtaussagen wie „Sicherheits- und Stabilitätsverbesserungen“.
 
Und damit meine ich Konkrete Informationen, nicht so generische Nichtaussagen wie „Sicherheits- und Stabilitätsverbesserungen“.
Das wird aber schon seit sehr langer Zeit so kommuniziert -egal ob nun AMD oder Intel -und muss man, wenn man nähere Infos benötigt, beim jeweilen Tech Support oder HQ anfragen.

..auch da ist meine persönliche, subjektive Erfahrung eher diese, dass ausgerechnet der Platzhirsch Asus sehr dürftig (teils verwirrend und sich selbst widersprechend) mit weiteren Infos ggü. dem Kunden hantiert.
 
@Don
Können AM5 Platinen überhaupt schon mit den neuen Speichervolumen umgehen?
In einem Test zu 2x 24GB Speicherriegel wird geschrieben, dass es mit AGESA 1.0.0.6 noch nicht möglich sei.
Doch, diverse Hersteller hatten schon ein BIOS, welches die 24/48 GB Module erkennt – mit AGESA 1.0.0.6.
 
Ist doch immer noch so wenn ich mich nicht irre:


..sind halt nur Betas ohne Erfolgsgarantie. Hier eine Tabelle: https://docs.google.com/spreadsheet...H4MlJ7meeDbEHYP-FHYW-PMyOk/edit#gid=522016589
 
OpenSIL wäre dann Open Source unter MIT Lizenz. Somit wäre (in Fachkreisen) kein Rätselraten mehr nötig, welche Features / Änderungen jetzt in welchem Release enthalten sind oder nicht. Und der allgemeine Cargo Cult um AGESA Versionen etc. würde sich hoffentlich auch endlich auflösen. (Vermutlich nicht, aber man kann ja hoffen…)

Was die Kommunikation von Boardherstellern an Endkunden betrifft sollten sich letztere eh nicht mit Details wie der AGESA Version befassen müssen.
Hier sollten die Hersteller imo in der Form „Wir haben Änderung X durchgeführt, was für Nutzer Auswirkungen YZ hat.“ kommunizieren. Und damit meine ich Konkrete Informationen, nicht so generische Nichtaussagen wie „Sicherheits- und Stabilitätsverbesserungen“.
Wenn man weiß wo man suchen muss, würde das wohl jeder verstehen was für Änderungen da vorgenommen wurden, da bei Open Source Projekten durchaus üblich ist, eine entsprechende Beschreibung der Änderungen (weshalb wurde dies geändert?) für jede Änderung abzuliefern. In Momenten wie diesen würden wir dann aber wohl auch viele Änderungen von einer @valvesoftware.com E-Mailadresse sehen und nicht nur von einer @amd.com E-Mailadresse, so wie man es bei den Linux-Treibern ja auch sieht, ganz schön clever von AMD jedem die Möglichkeit zu geben daran zu arbeiten.
 
Wenn also nun die ersten BIOS Versionen mit AGESA 1.0.0.7 Fehler aufweisen, liegt das dann an der neuen AGESA Version, oder am BIOS der Hersteller?
 
Wenn also nun die ersten BIOS Versionen mit AGESA 1.0.0.7 Fehler aufweisen, liegt das dann an der neuen AGESA Version, oder am BIOS der Hersteller?
Gute Frage, nächste Frage.
Beitrag automatisch zusammengeführt:

Biose auf Basis von AGESA-Version 1.0.0.7 haben noch Beta Status, bis zur endgültigen Version werden vermutlich noch einige Fehler behoben.
Man hat sich wohl für die Betas entschieden, um die CPUs vor Defekten zu schützen, das ist ja erstmal nicht verkehrt.
Schützen hilft nichts, wenn es dann schlechter läuft😂
Beitrag automatisch zusammengeführt:

Tja, es gibt auch welche, die halten das alles für übertrieben und finden, dass man den Leaks keinen Glauben schenken darf. Ich finde, dass die Leaks mit den tatsächlichen Ereignissen plausibel übereinstimmen.
Und die Folgen müssen dann Leute, die wie Du Pech gehabt haben und betroffen sind, ausbaden. Ich fühle da mit Dir 👍
Beitrag automatisch zusammengeführt:


Dann hätten sie AGESA 1.0.0.6 lassen sollen! Das hat mit den neuen BIOS-Versionen schon geholfen, statt ein 1.0.0.7 zu veröffentlichen, das noch mehr Bugs mitgebracht hat! Gott sei Dank haben nicht alle Boardpartner bei dem Chaos mitgezogen!
Danke. Die Preise für die X3D CPUs fallen gerade "zufällig" sehr deutlich in kurzer Zeit...ein Schelm wer böses denkt😉
 
Doch, diverse Hersteller hatten schon ein BIOS, welches die 24/48 GB Module erkennt – mit AGESA 1.0.0.6.
Etwas OT: Ist es so ein riesiges Problem 24/48 GB Module zum laufen zu bringen? Oder ist das erst ein Problem seit DDR5? Ich frage nur, weil ich selbst 6x 4GB (24GB) RAM Module habe. Etwas was mal Standard war, aber wohl heute, nicht mehr.
 
Etwas OT: Ist es so ein riesiges Problem 24/48 GB Module zum laufen zu bringen? Oder ist das erst ein Problem seit DDR5? Ich frage nur, weil ich selbst 6x 4GB (24GB) RAM Module habe. Etwas was mal Standard war, aber wohl heute, nicht mehr.
Verstehe ehrlich gesagt nicht worauf Du genau hinaus willst. Du hast 6x 4GB...ist das ein Triple-Channel DDR3 auf Intel Sockel 1366 oder was? Das wäre nicht mit mit 4x 48GB auf Dual Channel zu vergleichen, völlig andere Herausforderungen. Je mehr Module man pro Kanal einsetzt, desto schwieriger für den Speichercontroller das Ganze stabil zu bekommen, Größere Module tragen ebenfalls Ihren Teil dazu bei.
Generell ist das eher leichter als schwerer geworden mit DDR5 aber 4x 48GB oder auch nur 4x 24GB ist trotzdem nicht alltäglich für einen Consumer-Chipsatz, sowas findet man eher bei den Workstations und Servern. Von daher glaube ich nicht das es eine besonders große technische Herausforderung ist, aber man muss es halt trotzdem testen und entsprechende Routinen im BIOS dafür vorsehen. Und Priorität hätte das für mich als UEFI Entwickler auch nicht wirklich, die meisten Leute die sowas bisher brauchten haben Workstations.
 
Die krummen Grössen sind auch eben was neues - das dauert bis es überall wie Standard 8/16/32 läuft (war auch nicht anders zu erwarten...).
 
AMD hat wirklich alles nicht mehr im Griff.

Schon vor zwei Agesa Versionen 1.0.0.5c lief mein RAM nur noch mit 4800MHz. Und erst seit Agesa 1.0.0.6 wieder mit 6000MHz.
Und nun mit Agesa 1.0.0.7 wieder das gleiche Spiel, das EXPo Profil lässt sich nicht laden!

Was genau macht AMD da? Die sind einfach zu blöde für alles.
Das nun auch noch die 3D CPUs durchbrennen wegen zu hoher Spannung ist ein very big Fail.


Der Artikel hier ist viel zu nett geschrieben um dem Userfrust Weltweit Ausdruck zu geben.


1683568057190.png
 
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