ASRock X470 Taichi (Ultimate) im Test - Gute Technik und niedriger Stromverbrauch

Möchte einen (wahrscheinlichen) BIOS-Fehler in 1.35A melden:

Geht um den S3-Modus unter Win 10 1803. Alle BIOS-Einstellungen UEFI Defaults, einzige Änderung: Advanced -> AMD PBS -> BIOS PSP Support auf Disabled. Führt dazu, dass das System zunächst normal in den S3-Modus geht (blinkende Power-LED), beim Wiederaufwecken kommt für 10 sec kein Monitor-Signal, dann schaltet sich das System für 2 sec vollständig aus und anschließend wird ohne weitere Hinweise das BIOS zurückgesetzt. In Windows gibt es nur das Kernel Power-Ereignis, dass das System zuvor nicht ordnungsgemäß heruntergefahren wurde.

Das PSP-Gedöns zu deaktivieren sollte eigentlich nicht eine solche Auswirkung haben.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zuletzt bearbeitet:
Da ich eine CSM-Legacy-Installation auf eine MBR-Partition gemacht habe, bin ich davon ausgegangen, dass ich diesen TPM-/UEFI-Mist umgangen bin...? Oder muss dafür sonst noch etwas unternommen werden?

Sollte das Deaktivieren dieses PSP-Feature tatsächlich generell den S3-Modus "killen" (bei der Beschreibung dachte ich, dass "Secure S3" eine optionale Unterart von S3 ist, die aber eben nicht verwendet werden muss), sollte aber auch dies das BIOS an Windows weitergeben, so dass "Energie sparen" aus Windows heraus nicht mehr ansteuerbar ist. So ist es ja bei diversen (Server-)Boards, wo manche Varianten je nach BIOS S3 unterstützen und manche nicht, obwohl es sich um den gleichen Chipsatz handelt.
 
Zuletzt bearbeitet:
Puh muss man halt mal ausprobieren ob unter Linux bei deaktivierte PSP der S3 Modus ebenfalls nicht funktioniert. Was ich aber bezweifele. Und dann wäre es ein Windows Bug oder eine falsche Konfiguration und nicht ein UEFI Bug.
War denn die PSP deaktiviert während der Windows Installation?
Bist du dir sicher, dass du überhaupt den legacy S3 Modus nutzt, denn der ist nur optional: Power configuration options | Microsoft Docs Das normale ist Modern Standby.
Da hab ich noch ne interessante FAQ gefunden: Modern Standby FAQs | Microsoft Docs
Q: Can I switch between S3 and Modern Standby by changing a setting in the BIOS?

A: No, switching the power model is not supported in Windows without a complete OS re-install.
lol ich weiß wieso ich Linux nutze.
 
Zuletzt bearbeitet:
Habe den hybriden Modus bzw. den "Ruhezustand" (S4) mittels "powercfg.exe -h off" deaktiviert, so dass es tatsächlich der "echte" S3-Modus ist, wenn man auf "Energie sparen" geht - was man auch am belegten Festplattenspeicherplatz sieht.

Während der Windows-Installation war PSP noch aktiviert, ich werde morgen eine schnelle Neuinstallation mit im BIOS deaktiviertem PSP testen.

UEFI-Default-mäßig ist Firmware-TPM (fTPM) auch deaktivert, wenn ich den älteren Heise-Artikel richtig interpretiere, erfüllt damit das X470 Taichi gar nicht die Anforderungen, den Win 10-Sticker haben zu dürfen (was für ein Verlust...).

*Edit*: Konnte das unter Win 10 auftretende Verhalten beim Versuch des Aufwachens vom S3 mit im BIOS deaktiviertem PSP mit Absturz ohne Bild für 10 Sekunden, Ausschalten und nach ein paar Sekunden mit UEFI-Defaults neustarten unter Linux exakt nachstellen (Diagnose-Distribution "Parted Magic" vom 30. April 2018 mit Kernel 4.16.3 x64).


Scheint also tatsächlich ein Fehler im BIOS zu sein.
 
Zuletzt bearbeitet:
Das ist dann schon ziemlich eindeutig. Dass der kernel vielleicht mit irgendeinem Chip nicht klarkommt und deswegen nicht mehr aufwachen kann, passiert schon mal. Eigentlich sollte dann zumindest ein Terminal (strg + alt + f1) noch ne Fehlermeldung ausspucken und nicht rebooten (Aber kann sein dass das einstellbar ist und manche Distributionen rebooten). Aber dass sich dann auch noch das UEFI zurücksetzt, kann ich mir bei Windows noch vorstellen aber Linux macht sowas ziemlich wahrscheinlich nicht. Das ist wirklich sehr seltsam.
 
Kurzes Update: Habe nochmals Win 10 frisch auf eine leere Platte installiert (diesmal mit vorher im BIOS bereits deaktiviertem PSP) und ohne was an den Standard-Windows-S3-Einstellungen zu ändern und das Fehlerverhalten bleibt genau gleich.

Egal ob "klassischer S3" oder was für einen speziellen S3 auch immer jetzt Win 10 in der Standardkonfiguration verwendet, beide funktionieren also nur bei aktiviertem PSP.

Wenn sich JZ nicht mehr meldet werde ich den ASRock-Support kontaktieren.
 
Zuletzt bearbeitet:
Ich hoffe es kommt bald ein neues Bios. Zusätzlich zu dem Cache/Speicherbandbreiten Problem bei OC habe ich auch Probleme mit meinen Virtuellen Maschinen sobald die CPU auch nur leicht übertaktet wird. Um meine Virtuellen Maschinen im übertakteten Zustand nutzen zu können muss ich deren Beschleunigung deaktivieren was natürlich zu Leistungseinbußen innerhalb der Maschinen führt.

Immerhin habe ich meinen RAM mit Hynix Chips im Dual Rank auf 3066MT/s bei 14-17-17-36 CR1 stabil bekommen, damit kann ich leben. 3133MT/s läuft nur benchstabil.
 
Aus Neugier: Verwendest Du bei Deinen VMs unter Linux (wenn ich es richtig gesehen habe?) AMDs Pendant zu Intels VT-d? Intel hatte auch lange Zeit Probleme mit VT-d und Übertakten, weshalb es diese Funktion bis zum 4770K nicht bei den K-CPUs gab und erst beim 4790K aktiviert wurde.

Hoffe auch in meinem Fall, dass sich die Geschichte S3 und deaktivertes PSP durch ein BIOS-Update beheben lässt, war mit ein Kaufgrund für mich, da ich ME, PSP & Co. im Privateinsatz verachte. Was für ein Mist solche weitreichenden Systeme unterhalb des OS sind, hat man ja die letzten Jahre bei Intel gesehen.
 
Ja, ich benutze AMD-V, zumindest glaub ich dass es so heißt.

Hab das PSP auch mal deaktiviert um dein Standbyproblem zu testen und kann es mit BIOS L1.36 voll und ganz bestätigen. Er wacht nicht mehr auf und macht dann einen CMOS Reset.
 
@CrazyCookie:

Da scheint es ein Missverständnis gegeben zu haben: Intel VT-d ist die Funktion, die benötigt wird, um PCI (Express)-Geräte nativ einem VM-Gast zu geben (beispielsweise eine GPU oder ein Storage-Controller), dabei kann dieses Gerät nicht mehr vom Host verwendet werden.

Wenn ich es richtig sehe, heißt das bei AMD "IOMMU", AMD-V ist das Gegenstück zu Intel VT-x, das hat meines Wissens nach beim Übertakten nie Probleme bereitet.

Welchen RAM verwendest Du mit dem 2700 (?) auf Deinem X470 Taichi und darf ich Dein erfolgreiches Nachvollziehen des "S3-stürzt-ab-wenn-PSP-aus"-Problems dem ASRock-Support weitergeben? JZ scheint zu dem Thema leider keine Meinung zu haben.
 
Welchen RAM verwendest Du mit dem 2700 (?) auf Deinem X470 Taichi und darf ich Dein erfolgreiches Nachvollziehen des "S3-stürzt-ab-wenn-PSP-aus"-Problems dem ASRock-Support weitergeben? JZ scheint zu dem Thema leider keine Meinung zu haben.

Ich benutze ein 2x16GB Corsair CMK32GX4M2A2666C16 Kit auf meinem X470 Taichi mit einem 2700 nonX. Ja wenn du willst kannst du das S3 Problem weiterleiten, mir ist es egal da ich Standby eh nie nutze. Das Problem mit den VMs wird schon irgendwann mit einem Biosupdate verschwinden. Bei meinem alten MSI Board traten das VM Problem und das Speicher/Cachebandbreitenproblem unter OC ab den BIOSen mit PinnaclePI AGESA auf, erst mit dem PinnaclePI AGESA 1.0.0.2A Bios lief dort dann wieder alles normal.
Hmmm vielleicht sollte ich das alte Taichi Betabios mit 1.0.0.2A mal flashen um zu gucken ob es da auch weg ist, wäre aber seltsam wenn sich der Fehler mit 1.0.0.2C wieder eingeschlichen hätte.
 
Bei mir lag es am L1.36A Bios nun läuft alles problemlos 32GB 3200mhz
 
Zuletzt bearbeitet:
@Orange: mit welchem Bios schaffst du die 3200 jetzt? Kannst du dann einen Screenshot mit dem aktuellen Ryzen Timing Checker machen? Habe auch Hynix (AFR) Chips auf meinen Riegeln und vielleicht kann ich deine Timings als Vorlage benutzen.

Vielleicht sollte sich mal jemand zum Wohle der Allgemeinheit opfern und einen Sammelthread für das X470 Taichi machen.
 
X470 Taichi Ultimate - BetaBIOS 1.42
X470 Taichi - BetaBIOS 1.41
1. Improve Boost Overdrive
2. AGESA Code 1.0.0.4
*TestBetaBIOS auf Anfrage!
 
Nach einem kurzen Test kann ich sagen dass zumindest der Cache/Speicherbandbreitenbug mit dem neuen 1.41 unter OC jetzt weg zu sein scheint. Muss noch weiter testen aber bis jetzt schaut es nicht schlecht aus.

Edit: Meine VMs laufen jetzt auch wieder mit Hardwarebeschleunigung wenn die CPU OCed ist. :bigok:

Danke JZ für das Bios
 
Zuletzt bearbeitet:
X470 Taichi Ultimate - BetaBIOS 1.42
X470 Taichi - BetaBIOS 1.41
1. Improve Boost Overdrive
2. AGESA Code 1.0.0.4
*TestBetaBIOS auf Anfrage!

Wo gibts das 1.41 Beta Bios fürs normale Taichi? Auf der Seite find ich nichts zum Download :(
 
Zuletzt bearbeitet:
Wo gibts das 1.41 Beta Bios fürs normale Taichi? Auf der Seite find ich nichts zum Download :(
Ich hab mich mal auf seiner Seite registriert.

Es wurde mir mein Passwort im Klartext per Email zugeschickt. Eigentlich hätte ich hier schon aufhören sollen, aber die abschließende Krönung war dann noch nach Login auf die Downloadslinks zu gehen und von "Dieser Beitrag kann leider nur von bestimmten Mitgliedern oder von Kunden gelesen werden !" beglückt zu werden.

Passwort im Klartext müsste eigentlich gegen die DSGVO verstoßen (da Login & Passwort = personenbezogene Daten an einen Mail-Provider -> andere Firma geschickt werden), ist mir die Lebenszeit aber nicht wert.
 
Finde leider auch nicht die Version für's normale non-Ultimate X470 Taichi auf JZs Seite: Es gibt einen News-Beitrag zu neuen ASRock-AM4-BIOSen mit Verweis, sie unten herunterladen zu können. Im dortigen Drop-Down-Menü gibt es gegenwärtig den Punkt X470 Taichi - Version 1.56A, wählt man ihn aus wird jedoch in er Realität die Version 1.35A von ASRock heruntergeladen.

Ist denn nun tatsächlich Version 1.41 oder 1.56A die akuellste BIOS-Version?
 
Zuletzt bearbeitet:
Was gibt es an "TestBetaBIOS auf eMail Anfrage oder Download für Kunden im Forum!" nicht zu verstehen ?
 
Nun, wenn man Deine Seite als normaler Benutzer ansurft, man ohne Anmeldung ein Drop-Down-Download-Menü sieht, geht man in der Regel davon aus, dass das heruntergeladen wird, was man zuvor ausgewählt hat und nicht ohne jeglichen Hinweis der Download einer anderen Datei gestartet wird.
 
@CrazyCookie: Wärst Du so nett kurz zu prüfen, ob das schon ausführlich beschriebene kaputte S3 bei deaktiviertem PSP nach wie vor vorhanden ist oder ob zumindest das BIOS dann dem OS weitergibt, dass das System S3 nicht unterstützt?
 
Zuletzt bearbeitet:
Ich werd es heute Nacht testen. Ich muss ja auch erst noch den RAM neu austesten. Wie heißt es so schön, neues Bios neues Glück.

Edit: Auch mit dem Bios wacht der PC nicht mehr aus dem Standby auf wenn der PSP deaktiviert ist. Immerhin macht er nach einem Aufwachfail keinen Biosreset mehr.
 
Zuletzt bearbeitet:
Mir fehlt im neuen Bios irgendwie die AM4 Advance Boot Training Option.
 
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