X570: Bug in AMD CBS-Optionen brickt USB-Controller eines Mainboards dauerhaft? (DMAr Support)

[JBG]

Hallo,

ich kopiere als Warnung mal, was ich auf Wochenende gefunden habe und bereits an JZ im Hardwareluxx-Forum weitergegeben habe.

Ein Bug (?) in den AMD CBS-Optionen von X570-Mainboards scheint die BIOSe dauerhaft zu beschädigen, so dass keine USB-Geräte mehr erkannt werden, es betrifft die Option "DMAr Support" unter Advanced -> AMD CBS -> NBIO Common Options.

Ausgelöst wird es, wenn man "IOMMU" von Auto auf Enabled und danach "DMAr Support" von Auto auf Enabled stellt.

Anschließend werden bei einem Neustart des Systems keine USB-Geräte mehr gefunden, ein CMOS Reset und Entfernen der BIOS-Batterie helfen nicht (!).

Konnte es mit zwei Mainboards nachstellen:

• ASUS Pro WS X570-ACE (UEFI 2206)
• ASRock X570 Taichi (UEFI P3.40)
  (CPU/APU: 4750G)

Das X570 Taichi hat eine USB Flashback-Funktion, wenn das Mainboard aus ist und über das Netzteil mit Strom versorgt wird, damit konnte ich dessen BIOS neu flashen und das Mainboard funktioniert anschließend wieder normal.

Das Pro WS X570-ACE hat leider kein USB Flashback, keinen gesockelten BIOS-Chip und keinen PS/2-Tastatur-Anschluss, dadurch bootet es nicht mehr, da es mit der Meldung "No keyboard detected, press F1 to enter BIOS" beim POST stehen bleibt.

Sollte ich irgendwo einen Logikfehler gemacht haben, so möge man mich bitte teeren und federn
(Ich hoffe es offen gesagt)

In der Zwischenzeit hoffe ich, dass sonst niemand auf die Idee kommt, diese BIOS-Option (DMAr Support) zu aktivieren!

 

[v3locite]

Als Besitzer eines Pro WS X570-ACE bedanke ich mich mal und füge diesen Punkt der langen Liste von Dingen hinzu, die bei diesem Mainboard nicht stimmen.

 

[JBG]

Habe gestern auch schon eine Anfrage dazu an den ASUS-Support gestellt, hoffe, dass sie etwas dazu sagen können oder das Problem eskaliert wird.

 

[Holt]

Ausgereift ist der X570 nicht, der X570 ist ja schon für seine schwachen IOPS an den SATA Ports bekannt, auch wenn kaum darüber geschrieben wird.

 

[micha`]

Das X570 Taichi hat eine USB Flashback-Funktion, wenn das Mainboard aus ist und über das Netzteil mit Strom versorgt wird, damit konnte ich dessen BIOS neu flashen und das Mainboard funktioniert anschließend wieder normal.

Witzig, das funktioniert dann aber - obwohl eigtl. keine USB Geräte erkannt werden?!

Danke für die Warnung.

 

[matze313]

Vielen Dank für die Warnung!

 

[Hito360]

is das nurn x570 Problem? hat JZ eventuell mehr Infos? HWLUXX thread link?

 

[Powl_0]

Witzig, das funktioniert dann aber - obwohl eigtl. keine USB Geräte erkannt werden?!

Danke für die Warnung.

Wohl, weil Bios Flashback nicht vom BIOS per se gehandhabt wird. Dafür muss das Board ja nichtmal gebootet sein.

 

[JBG]

is das nurn x570 Problem? hat JZ eventuell mehr Infos? HWLUXX thread link?

Letzter Beitrag in meinem großen Thread zum X570 Taichi:

https://www.hardwareluxx.de/community/threads/asrock-x570-taichi-phantom-gaming-x-alles-mögliche.1236069/page-28#post-27711786

Leider noch keine Reaktion, was ein Indiz dafür sein könnte, dass das Problem bei einem schnellen Test nachgestellt werden konnte, also nicht vor dem Monitor sitzt und erst mit ASRock/AMD Rücksprache gehalten werden muss, was das weitere Vorgehen ist.

Auch noch keine Reaktion vom ASUS-Support.

Ergänzung (29. September 2020)

Was die "DMAr Support"-Funktion ansich angeht:

Wenn ich es richtig sehe, ist dies eine Sicherheitsfunktion für den Inhalt des RAM, um möglichst viele Wege für DMA-Angriffe zu verhindern.

Dabei scheint gewollt zu sein, dass Geräte/Controller (hier USB-Controller), die RAM-Zugriff haben, nicht schon beim POST initialisiert sondern erst nach dem Booten des OS "sicher" gestartet werden.

Ungeil ist dabei, dass beispielsweise ASUS aber standardmäßig das "Stoppe Booten, wenn keine Tastatur vorhanden ist" aktiv hat und diese Option nicht automatisch durch das Aktivieren vom "DMAr Support" deaktiviert wird.

Aber warum diese "DMAr Support"-Aktivierung einen CMOS Reset übersteht ist mir ein Rätsel.

Gibt es bei X570-Mainboards für (manche?) BIOS-Optionen einen nicht flüchtigen Speicherbereich auf dem BIOS-Flashchip?

 

[Powl_0]

AMD CBS Bereich ist glaub ich generell von cmos reset unberührt. Bei meinem X370 haben auch ram settings und spannungen im CBS einen cmos reset überlebt.

 

[JBG]

@Powl_0

Das ist interessant, war mir noch gänzlich unbekannt.

 

[Powl_0]

Mir davor auch, habs erst durch ein frustrierendes Wochenende rausgefunden, nachdem ich stark instabiles Ram OC im RM eingestellt hatte.

 

[JBG]

Konnte ich aus Zeitgründen noch nicht testen:

Vom ASUS-Support kam die Antwort, einen "hardwarenahen" CMOS Reset durchzuführen:

• Netzteil vom Strom trennen
• BIOS-Batterie entfernen
• CLRTC Jumper für ca. 10 sec verbinden
• BIOS-Batterie wieder einsetzen
• Wieder starten, ins BIOS gehen und Standardeinstellungen mit F5 laden

Frage von mir:

Ist das eine 08/15-Antwort oder macht das Entfernen der BIOS-Batterie mit Brücken des CLRTC-Jumper für ein paar Sekunden einen Unterschied im Vergleich zu meinen bisherigen Tests (BIOS-Batterie war für etwa 8 h ausgebaut (über Nacht)).

 

[JBG]

Einen Workaround gefunden!

DMAr ist eine PRO-only Funktion, baut man eine nicht-PRO-CPU ein, startet das Mainboard wieder mit normaler USB-Initialisierung.

Doof, wenn man nur die eine PRO-CPU gehabt hätte. Es kam sogar beim ersten Einschalten die Meldung, dass eine neue CPU installiert wurde, obwohl vorher ein CMOS Reset gemacht wurde ("New CPU installed! [...]").

Habe dann gegengeprüft, als die Tastatur kein Problem mehr war: Macht man mit unveränderter CPU einen CMOS Reset, so kommt beim ersten Einschalten eine andere Meldung ("Please enter setup to recover BIOS setting").

Es gibt also definitiv einen nicht flüchtigen Speicherbereich, der protokolliert welche CPU zuletzt verwendet wurde.

Würde sagen 50/50: Mein Fehler/ASUS:

• Ich hatte keine Ahnung, dass DMAr nicht durch einen normalen CMOS Reset zurückgesetzt werden kann.
• ASUS hätte vielleicht nicht die "Booten wird angehalten, wenn keine Tastatur gefunden wurde" bei einem "Workstation"-Mainboard als CMOS-Standard hinterlegen sollen, bei dem ja nicht sooo unwahrscheinlich ist, dass eine PRO-CPU-Variante verbaut wird.

 

[JBG]

Konnte nun auch verlässlich mit der nicht-PRO-CPU belegen, dass AMD CBS-Einstellungen durch einen CMOS Reset nicht zurückgesetzt werden, Methodik:

Diesmal statt der PRO 4750G-APU einen 3700X mit WX4100 als GPU verbaut, Mainboard nach wie vor das ASUS Pro WS X570-ACE mit UEFI 2206.

Jetzt gibt es zwar die Option "DMAr Support" nicht mehr, aber "IOMMU" ist nach wie vor vorhanden.

Habe IOMMU von Auto zu Enabled geändert, gespeichert, neugestartet und alles funktioniert noch normal.

Nun habe ich einen CMOS Reset durchgeführt, beim ersten Einschalten kommt wie erwartet:

Gehe ich nun ins UEFI und lade via F5 die Standard-Einstellungen und wähle speichern und neustarten, kommt beim letzten Dialog eine Liste mit veränderten Einstellungen und siehe da, IOMMU war nach wie vor auf Enabled statt Auto:

Dadurch entsteht eine Sackgassensituation, wenn nur eine PRO-CPU vorhanden ist, auch wenn kein Hardware-Defekt vorliegt:

- Deaktiviert man unter Boot -> Boot Configuration die F1-drücken-wenn-keine-Tastatur-vorhanden-Einstellung, die standardmäßig aktiviert ist, so kann das Mainboard auch mit aktiviertem DMAr Support in den AMD CBS-Einstellungen beispielsweise über SATA booten.

- Tritt nun aus irgend einem Grund ein anderer Fehler auf, weswegen man einen CMOS Reset machen muss, so ist das Mainboard gebrickt, da das "F1-drücken" wieder aktiviert ist, DMAr Support dagegen nach wie vor vom CMOS Reset unberührt weiterhin aktiviert ist.

- Ohne eine nicht-PRO-CPU ohne DMAr-Unterstützung, womit man wieder mit einer USB-Tastatur ins BIOS kommt, wüsste ich nach wie vor nicht, wie man das Mainboard wieder booten lassen könnte.

Habe ASUS gebeten, bei künftigen UEFI-Versionen die F1-drücken-Einstellung standardmäßig auf deaktiviert statt aktiviert zu stellen, bin gespannt, ob da mehr als "Vielen Dank für Ihre konstruktiven Hinweise" kommt.