Plötzlich Probleme beim Schreiben auf SSDs?

Doch das gibt es, bei früheren AM4, wenn die Lanes verbraucht waren gab es m.2 Slots die deaktiviert waren und nur noch der gekoppelt Sata Anschluss gelaufen ist. (Äußerst selten, aber hat es gegeben)

Nicht nur mit Sata auch U2 und im UEFI standardmäßig noch vorhanden:

Screenshot 2026-09-27 at 10-49-34 UEFI Editor.png
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Änder aber nichts daran, dass diese Einstellungen nur einmalig beim Bootvorgang erfolgen und danach so bleiben und sich nicht mehr ändern, also nichts mit dem Thema zu tun haben.
 
Geile Logik! So ziemlich JEDE Einstellung die man im UEFI vornimmt, lässt sich unter Windows i.d.R. nicht mehr ändern. :rolleyes:

..ist aber eher ein "Standard" Setting im AMI Bios, dass auch die AMD Boards nicht anders besitzen. Genau so wie halt den PCI(e) Xpander und dessen PCHX-Modi.

ps: Die Bugs die den TE betreffen sind, meiner Meinung nach, schon diagnostiziert und auch bei anderen X670E Boards bekannt (Google hilft) - hier sollte der TE mal abwarten was der MSI HQ dazu schreibt und warum diese im UEFI unterdrückt werden. Meine Vermutung: AMD möchte den Zugriff darauf nur über deren Treiber gestatten. Ist allerdings der jeweilige Treiber fehlerhaft oder gar nicht kompatibel, Popokarte! Da kann man dann in den Windowssettings fummeln wie man möchte, der Treiber wird deren Settings immer konteragierend ggü. stehen und zu 100% höhere Priorität besitzen.
 
Zuletzt bearbeitet:
@Erklärbär Besten Dank für das Angebot! Super Hilfbereitschaft! :love:
Ich werde die Antwort von MSIToWi abwarten. Ich denke, ich soll noch ein Ticket bei MSI aufmachen usw. Obendrein werde ich es mit einem SP Mega GM 1200W Netzteil prüfen.

Dass ich eine Gen-5-SSD nicht mit vollen Speed nutzen kann, ist für mich OK. Aber die anderen beiden SSD-M.2-Slots sollten schon ordnungsgemäß und verlässig funktionieren.
:fresse2: Natürlich geht es auch extern über USB. Der 10-Gbps-Anschluss reicht im Alltag, dennoch nervig.

Ich bin nach wie vor am Rätseln, dass dies unmittelbar nach dem Flashen auf das A52, vom A40 kommend, UEFI losging und seitdem mit keiner UEFI-Version wieder stabil war. Nicht mit A40, A42, A50 oder A52.
 
..dass dies unmittelbar nach dem Flashen auf das A52, vom A40 kommend, UEFI losging und seitdem mit keiner UEFI-Version wieder.
..das erklärt natürlich vieles, war wohl ein AGESA Update inklusive das sich in den Areas verewigt hat. Das wirst du natürlich so einfach nicht wieder los.

Eventuelle Lösung: Gutes altes CMOS_reset. Jumper setzen, Batterie raus. Nur via USB-Flash wird das wohl eher weniger klappen.

ps: Das kannst du eventuell auch optisch erkennen wenn dein Board diese Option beim Flash bietet. Bei Asus ist es zb. so, dass du während des Flashvorgangs unter den Fortschrittbalken den jeweiligen "Bereich" der gerade beschrieben wird angezeigt bekommst. Generell beginnen die mit den Areas 1-4. Die sind reserviert zum beschreiben der IMEI bzw. AGESA, MC Updates, AMITSE usw., erst danach folgt dann der Bereich der dann das grafikbasierte Bios (UEFI Menü) betrifft. Wenn du jetzt schreibst, dass das Problem erst nach Flash auf A52 auftrat, dann wird doch mit höchster Wahrscheinlichkeit ein AGESA Update mit drin gewesen sein das eine bestimmte Area "mit" beschrieben hat. Machst du danach wieder ein Backflash -> nutzlos, die Area ist ja schon mit einer anderen AGESA beschrieben, dass Backflash Bios wird wahrscheinlich nur den "normalen" Bereich neu beschreiben, die Areas ansich aber so lassen wie sie halt sind. Erkennt man dann daran, dass der Balken bei Backflash zb. von A52 auf A40 die ersten 20% schnell überspringt.

Eine wichtige Info für MSI, solltest du denen mitteilen.

pps: Zum UEFI allgemein: Das bildet grundsätzlich nur einen eher bescheidenen Teil (unter 5%) des wirklichen, sehr mächtigen, AMI Aptio V Bios der derzeit aktuellen Intel/AMD Boards ab und auch nur das, was die Boardpartner nach Rücksprache mit Intel/AMD aus deren IMEI/AGESA verwenden "dürfen". Das administrative Entwicklerbios allerdings zeigt dann was wirklich hinter der "Benutzermaske" steckt und da sind dann auch so "Spielereien" wie das setzen des "Port8xh Decode"-Flag für die 7-Segment Anzeige des Boards (wenn optional vorhanden) inklusive, worüber man dann halt die Anzeige vom normalerweise Bios Post-Code hin zum Post-Code auslesen des PCIe-Bus switchen kann um deren Diagnose-/Fehlercodes auslesen zu lassen. Die noch tieferen Deepstate Settings L1_Substate und L1_Low, sowie das "echte", logische tauschen der PCIe Nummerierung/Reihenfolge/Funktionsweise sind dann noch weitere nützliche Funktionen, da schlampen die Boardpartner öfters halt mal mit und strukturieren die nicht benutzerfreundlich nach den WYSIWYG-Prinzip sondern eher nach der boardinternen IRQ-Reihenfolge:

MSI_SnapShot_00.png MSI_SnapShot_01.png MSI_SnapShot_02.png

DMI Link ASPM Control: Steuert das Power Management Verbindung zwischen CPU und Chipsatz (lieber "Deaktiviert" lassen für maximale Stabilität und minimale Latenz).

Port8xh Decode: Leitet Diagnose-Fehlercodes (POST-Codes) über den PCIe-Bus an die Port 80h-Siebensegmentanzeige des Mainboards weiter (Wichtig für Troubleshootings beim Booten).

Compliance Test Mode: Testmodus für Hardware-Entwickler, um die PCIe-Signalqualität mit Oszilloskopen zu messen.

PCIe function swap: Erlaubt es dem BIOS, die interne Nummerierung/Reihenfolge der PCIe-Funktionen logisch zu vertauschen.

PCIe EQ settings: Umfassendes Untermenü zur feinen Justierung der Signal-Equalization (Spannungssignale, Dämpfung uvm.) auf den PCIe-Leitungen, um Übertragungsfehler bei langen Signalwegen zu minimieren.

PCI Express Root Port x: Aktiviert oder deaktiviert diesen spezifischen PCIe-Anschluss logisch komplett.

Connection Type: Zeigt physisch, wie der Port angebunden ist.

PCI Express Root Port x ASPM: Aktiviert Stromsparmechanismen nur für diesen Port im Leerlauf.

L1 Substates: Sehr tiefgreifende, feingranularere Stromsparstufe für PCIe-Geräte.

L1 Low: Erlaubt dem Port, in einen extrem tiefen Niedrigenergiemodus zu wechseln.

ACS: Wichtig für Virtualisierung unter Proxmox/ESXi. Isoliert PCIe-Geräte voneinander, damit sie per Passthrough direkt an eine VM übergeben werden können.

PTM: Aktiviert hochpräzise Zeitsynchronisation zwischen der CPU und dem angeschlossenen PCIe-Gerät (wichtig für Echtzeitanwendungen).

DPC: Schutzmechanismus wenn am Port ein kritischer PCIe-Fehler auftritt, isoliert den Port, um einen kompletten Systemabsturz zu verhindern.

EDPC: erweiterte Version von DPC, die präzisere Fehlerprotokolle an das OS weitergibt, bevor der Port abgeschaltet wird.

URR: Meldet das System, wenn ein Gerät eine Anfrage stellt, die der Port nicht unterstützt.

FER: Meldet schwerwiegende, nicht behebbare Hardwarefehler sofort an die CPU.

NFER: Meldet Fehler, die das System zwar beeinträchtigen, aber nicht sofort zum Absturz führen.

CER: Meldet Fehler, die von der Hardware-Fehlerkorrektur automatisch repariert werden konnten (z.B. korrigierte Bitfehler).

SEFE: Löst einen globalen Systemfehler (NMI/Reset) aus, sobald ein fataler PCIe-Fehler auftritt.

SENFE: Löst einen Systemfehler bei nicht fatalen PCIe-Fehlern aus.

SECE: Löst einen Systemfehler aus, selbst wenn der Fehler eigentlich korrigierbar war.

PME SCI: Ermöglicht es dem PCIe-Gerät, das System über einen Interrupt aus dem Ruhezustand aufzuwecken.

Hot Plug: sollte man kennen.

Advanced Error Reporting: Schaltet das erweiterte Fehlerprotokollierungs-Subsystem für diesen Port global ein oder aus.

M2_x Gen Mode: Erzwingt die PCIe-Generation für den x-ten M.2 Slot.

Transmitter Half Swing: Reduziert die Signalspannung des Senders um die Hälfte. Spart minimal Strom, verschlechtert aber die Signalqualität ab Gen4 SSDs. Ab Gen4 deaktiviert lassen!

Detect Timeout: Zeitdauer in Millisekunden, die das BIOS beim Systemstart wartet bis sich ein PCIe-Gerät an diesem Port anmeldet (15 ms ist Standard). <- *hier liegt im übrigen auch nochmal der Hund begraben, warum CDI den Counter für "unsafe Shutdown" erhöhen kann!!*

Extra Bus Reserved: Reserviert zusätzliche logische PCIe-Bus-Nummern für diesen Port. Wichtig für PCIe-Splitter oder Thunderbolt-Docks die intern eigene Busse nutzen.

Reserved Memory / Reserved I/O: Reserviert festen Arbeitsspeicher (MB) und I/O-Adressen für diesen Port im System-Adressraum. Verhindert Ressourcen-Konflikte beim dynamischen Zuweisen.

LTR: Ermöglicht es der NVMe SSD der CPU mitzuteilen, wie viel Latenz sie beim Wechsel aus dem Stromsparmodus vertragen kann. Verhindert, dass das System deepstate schläft, wenn schnelle Datenübertragungen anstehen.

Snoop / Non Snoop Latency Override: Ermöglicht es, die vom Gerät gemeldeten Latenzzeiten manuell zu überschreiben, für CPU-Cache-synchron (Snoop) oder direkte Speicherzugriffe (Non-Snoop).

LTR Lock: Sperrt die LTR-Einstellungen (siehe zuvor), damit das OS oder Treiber sie nach dem Booten nicht mehr verändern können.

Peer Memory Write Enable: Erlaubt es zwei PCIe-Geräten untereinander direkt Daten in den Speicher des jeweils anderen Geräts zu schreiben, ohne den Umweg über die CPU zu nehmen (sehr viel höherer Durchsatz für Multi-Device-Setup -> Nachteil: Das OS/CPU prüft den Datensatz nicht mehr auf korrumpierende Datenstruktur).
 
Zuletzt bearbeitet:
Änder aber nichts daran, dass diese Einstellungen nur einmalig beim Bootvorgang erfolgen und danach so bleiben und sich nicht mehr ändern, also nichts mit dem Thema zu tun haben.
Und ich ging hier von dem Umstand aus das durch das Flashen was an dem jeweiligen Slots verändert wurde, wenn das was @Erklärbär vermutet könnte das wie die Faust aufs Auge passen.
Durch das Update wurde eine Funktionen aus dem Bios in den AMD Treiber übertragen, der aber ein falschen Eintrag sendet. AMD Treiber übernimmt und nutzt die falsche Funktion oder so ähnlich.

Aber ja ich hatte auch so einen ähnlichen Fall das eben nach einem UEFI Upgrade die Defaults geändert wurden, dann stimmt alles hinten und vorne nicht mehr.

@patrock84 was du noch versuchen könntest -> auf das neueste Bios Flashen, CMOS Reset durchführen -> neues Windows auf anderen Datenträger aufsetzen und die aktuellsten Treiber installieren.
Wenn du das schon durchgezogen hast, dann vergiss es.

Es könnte auch ein Problem im Chipsatztreiber liegen in Kombination, hattest du schon mal einen älteren Chipsatztreiber versucht? Bzw. den von MSI selbst empfohlenen? (Nicht aktuellsten von AMD)
 
Obendrein werde ich es mit einem SP Mega GM 1200W Netzteil prüfen.
Das solltest Du auf jeden Fall machen.

Ich bin nach wie vor am Rätseln, dass dies unmittelbar nach dem Flashen auf das A52, vom A40 kommend, UEFI losging und seitdem mit keiner UEFI-Version wieder stabil war. Nicht mit A40, A42, A50 oder A52.
Wenn das Problem die Alterung des Netzteils ist, vor allem die Kondensatoren darin altern ja und sich dadurch die Qualität der Spannungsregelung der 3,3V Schiene verschlechtert hat, dann könnte es einfach Zufall sein, dass dies zeitlich gerade mit dem BIOS Update zusammenfiel. Dann sucht man die Ursache beim BIOS, obwohl sie dort gar nicht liegt. Deshalb solltest Du unbedingt das andere Netzteil testen oder eben mit einem PCIe Adapter mit eigener 12V auf 3,3 Spannungswandlung.

Natürlich geht es auch extern über USB. Der 10-Gbps-Anschluss reicht im Alltag, dennoch nervig.
Das wäre ja nun eine ganz blöde Notlösung.

Und ich ging hier von dem Umstand aus das durch das Flashen was an dem jeweiligen Slots verändert wurde
Bei Shared Resources ist es eine Grundfunktion des BIOS wie es entscheidet, welche der Optionen aktiv wird und im übrigen ist bei dem Board des TE nichts geshared, zumindest habe ich im Handbuch nichts dazu gefunden und da müsste es stehen.

Durch das Update wurde eine Funktionen aus dem Bios in den AMD Treiber übertragen, der aber ein falschen Eintrag sendet. AMD Treiber übernimmt und nutzt die falsche Funktion oder so ähnlich.
Nein, so etwas gibt es nicht. Die Treiber können nur das BIOS ansprechen und Funktionen aktivieren oder deaktivieren, aber keine Funktionen des BIOS übernehmen. So funktioniert ASPM eben nur, wenn es im BIOS aktiviert ist, wenn es das nicht ist und der Treiber versucht ASPM zu aktivieren, denn macht das BIOS es einfach nicht und man hat kein ASPM. Aber ASPM sollte nicht für das Verschwinden von Laufwerken während Schreibvorgängen (wenn sie also nicht Idle sind) verantwortlich sein und wurde ja auch in Windows deaktiviert. Windows sollte also keinen Versuch unternehmen ASPM zu aktivieren, selbst wenn es einen Bug im BIOS geben sollte der dazu führt, dass ASPM aktiviert werden kann, obwohl es im BIOS deaktiviert ist.
 
Und ich ging hier von dem Umstand aus das durch das Flashen was an dem jeweiligen Slots verändert wurde, wenn das was @Erklärbär vermutet könnte das wie die Faust aufs Auge passen.

Meine Vermutung: Das A52 Bios hat ein AGESA-Update der Area(s) mit geflasht! Die Bios Versionen vor den Flash hatten ja scheinbar eine andere AGESA, siehe:
Ich bin nach wie vor am Rätseln, dass dies unmittelbar nach dem Flashen auf das A52, vom A40 kommend, UEFI losging und seitdem mit keiner UEFI-Version wieder stabil war. Nicht mit A40, A42, A50 oder A52.
Fazit: Wenn diese AGESA mit Bios A52 einmal diese Area mit einer anderen AGESA beschrieben hat und die Biosse zuvor kein AGESA Update bekommen hatten, dann wird diese Area natürlich auch nicht wieder bei Backflash älterer Biosse neu beschrieben, bleibt also selbst mit A50, A42 usw. auf Stand A52. Und selbst wenn zb. A40, denke das ist das first_Bios, logischerweise dann auch das erste AGESA include hat, muss das nicht bedeuten das mit dieser dann Register neu beschrieben bzw. umgeschrieben oder gecancelt werden die erst mit AGESA aus A52 dazu kamen. Hier wäre es aus meiner Sicht die zuverlässigste Lösung man macht den CUT -> heißt, Rechner stromlos, Jumper setzen, Batterie raus! Danach dann Jumper wieder raus, Batterie rein und halt via USB Stick das First_Release A40 Bios flashen. Sauberste und sicherste Lösung. Sind danach die Probleme weg -> Fall gelöst, A52 erst einmal meiden aber dennoch MSI das Problem melden.
Das Bios musst du dir ungefähr so vorstellen -> Area1-4 / UEFI / Sonstiges (Profile usw.) | bei einen normalen Biosupdate wird meist nur der mittlere Block, also das UEFI beschrieben, die Änderungen betreffen da meist nur die AMITSE und PE32_Dateien. Die Areas sind die Blöcke die Safe sind und nur von AMD/Intel genutzt werden für zb. MC, IMEI/AGESA usw., da wird niemals ein UEFI Update rein geschrieben werden. Das sowohl die AGESA als auch IMEI nicht immer so ganz sauber werkeln, hat man ja zb. anhand des SoC/ProcHot Geplänkel gesehen und bei IMEI halt das auch da immer wieder mal Sicherheitslöcher gestopft werden müssen.
Es wird dir auch kein Editor der Welt diese Areas unkodiert auslesen können (zumindest ist mir keiner bekannt), mit ein Grund dafür das selbst die schon sehr guten erst mit Adressbereichen ab 0x27xx beginnen. Alles davor würde, wenn es denn einen Editor gäbe der das eventuell doch könnte, höchstwahrscheinlich ein komplett genullter Bereich sein. AGESA und IMEI das ist Fort Knox seitens AMD und Intel. Keiner kennt auch eine wirklich gute Dokumentation dazu. Wenn ja, her damit!!! (und ich meine jetzt keine Beschreibung, was IMEI ist und macht, sondern den Quellcode).

NACHTRAG @ TE: Du hattest ja geschrieben, dass du auch mal unter Linux getestet hättest und dort das gleiche Problem mit den SSDs unter Bios A50/A52 hast. Mit Bios A50 kam ein großes AGESA-Combo Update, dass dann auch in A52 enthalten ist. Du könntest unter Linux mit folgenden Syntax zwei Sachen testen:
dmesg | grep -E "nvme|PCIe"
A: Wird dir zb. sowas wie: "nvme(X): Device not ready... clearing queues oder frozen state." angezeigt, bedeutet das die SSD stürzt ab, weil die Spannungsversorgung (3.3V) über das Board bei Schreiblast einbricht.
B: Wird dir zb. sowas: "PCIe Bus Error: severity=Corrected/Uncorrected, type=Physical Layer." angezeigt, deutet das schwer darauf hin, dass der AGESA-Microcode das physische Link-Training der Leitungen beschädigt hat. Die Hardware verliert buchstäblich die elektrische Synchronisation zum Chipsatz. Gerade die X870 Boards sollen wohl immer mal Probleme mit Taktsignalschwankungen des X870E-Chipsatz (Promontory 21) generieren (siehe MSI Forum). Wenn das so ist -> HardCUT wie zuvor beschrieben und ein Downgrade auf ein älteres Bios mit älteren ComboUpdate (vieleicht sogar unter A40), anders wird man das nicht lösen können.
 
Zuletzt bearbeitet:
Hey, ich werde erst Mittwoch zum Testen kommen.
Beim ersten Flashen im August hatte ich nicht unmittelbar danach ein CMOS Reset gemacht. Also über den Button auf der Rückseite mind. zehn Sekunden wie es im Handbuch steht. Erst ein Tag später. Nach jedem anderen Flashen habe ich es ebenso gemacht.
 
Heute kam ich nun endlich zum Anschließen vom FSP Mega GM 1200W Netzteil. Wegen der Wasserkühlung habe ich es außerhalb vom Gehäuse verkabelt.
Dadurch ist auch kein Luftzug über die Crucial T705 gezogen. Die KC3000 habe ich wieder eingebaut, auf die Schnelle ohne separaten Kühler.

3x Durchläufe von CrystalDiskMark mit der Kingston KC3000 - stabil
ich habe noch nebenbei YT laufen lassen und noch was anderes am PC gemacht. Es soll lediglich ein Stresstest und kein Benchmark für Spitzwerte werden.
Screenshot 2026-09-30 181931.png

Dann war ich optimistisch und habe die Crucial T705 im UEFI auf Gen5 gestellt. ASPM ist weiterhin für den M2_1 im UEFI deaktiviert und "Link State Power Management" ist ebenso in Windows deaktiviert.
3x Durchläufe von CrystalDiskMark mit der Crucial T705- stabil
Screenshot 2026-09-30 185741.png
Ich weiß, dass die Maximaltemperatur zu hoch ist. Das ist jedoch erst beim dritten Durchlauf kurz beim Seq Read Test gewesen.

:love:
Ich werde die wilde Verkabelung erstmal so lassen und wenn es für ein paar Tage sich weiter als stabil abzeichnet, kommt das Netzteil ins Gehäuse.
Der spannende Teil wäre dann noch, ob das Seasonic PRIME Ultra Titanium 1000W einen Treffer weg hat oder die Instabilitäten durch die Kabelverlängerungen für 24-Pin-ATX und 2x 8-Pin-EPS.
:confused:

EDIT: Dass die Probleme so eng nach dem UEFI-Update kamen, nicht mal eine Stunde später, verwundert mich dennoch.
 
Der spannende Teil wäre dann noch, ob das Seasonic PRIME Ultra Titanium 1000W einen Treffer weg hat oder die Instabilitäten durch die Kabelverlängerungen für 24-Pin-ATX und 2x 8-Pin-EPS.
Sind die Verlängerungen jetzt gerade auch angeschlossen?
Wenn nein, teste nochmal damit.
Und danach wieder mit der ursprünglichen NT/Kabel Konfiguration.
 
Dass die Probleme so eng nach dem UEFI-Update kamen, nicht mal eine Stunde später, verwundert mich dennoch.
Es gibt manchmal sehr dumme Zufälle. Ob es nun am Netzteil oder der Kabelverlägerung liegt, kannst Du entweder testen, indem Du diese Verlängerung auch für das aktuelle Netzteil nutzt, sofern dies geht oder eben das ursprüngliche Netzteil ohne diese Kabelverlängerung, notfalls eben auch wild verkabelt. Beachte nur, dass die Kabelstränge von modularen Netzteilen nicht genormt sein, die Pinbelegung der Anschlüsse am Netzteil kann teils sogar bei Modelle der gleichen Serien abweichen und es kann zu sehr teuren Schäden führen, wenn dann die falsche Spannung oder gar Polung anliegt!
 
Dass die Probleme so eng nach dem UEFI-Update kamen, nicht mal eine Stunde später, verwundert mich dennoch.
Ja sind mögliche Zufälle. Ist wie beim OC/UV manchmal reichen schon 10mv um Instabilität zu verursachen. Vielleicht hätte das UEFI Update noch was an der Stromaufnahme geändert/angepasst, dass lief vorher vielleicht schon auf "Kante" und das hat das Ganze aus dem Konzept gebracht.
Könnte auch passieren das wenn du dein Altes Netzteil längere Zeit nicht mehr am Strom hast, das sich das wieder etwas erholt und bei einem Test in ein Paar tagen wieder alles mit dem Alten Netzteil laufen würde... Veränderungen an der Luftfeuchtigkeit im Raum, Temperaturen etc. könnten alles minimalsten Einfluss nehmen. (Kontakte sind minimal weniger nah bei einander etc.)
 
Hatte letztens ne Meldung von Windows das meine SSD bald hin ist!
Samsung SSD, Samsung Magician installiert alles Bestens SSD Zustand Gut!
Soviel zu WIN Laufwerk Kontrollen. mfg
 
Poste doch mal einen Screenshot von CrystalDiskInfo für die betroffene SSD.
 
Der spannende Teil wäre dann noch, ob das Seasonic PRIME Ultra Titanium 1000W einen Treffer weg hat oder die Instabilitäten durch die Kabelverlängerungen für 24-Pin-ATX und 2x 8-Pin-EPS

@patrock84 wahrscheinlich war die Kabelverlängerung am 24 Pin ATX Kabel das Problem.



Da das Problem direkt nach dem Bios update auf Version A52 aufgetreten ist, ist ein Kaltstartproblem (PCIe Link Speed Problem) an deinem MSI Pro X870E P Wifi Mainboard möglich, die M.2 Slots und PCie Slots werden dann nicht korrekt angebunden, Bild unten.

Windows hängt beim Kaltstartproblem und alles funktioniert nur noch im Zeitlupentempo.
Das Kaltstartproblem ist bei meinem MSI MAG B850 Tomahawk Max WIFI ebenfalls vorhanden, und hat sich mit aktuellen Bios Versionen verschlimmert, die Latenz liegt dann bei 146 434 µs.
PCIe Link Speed Problem.jpg

Deine RX 9070XT Grafikkarte muss ausreichend ausgelastet sein, um einen Link Speed von 32 GT/s zu erreichen, man kann den GPU-Z Rendertest verwenden,
sollte dann aber den Haken bei Render in Full-Screen setzen, damit die Grafikkarte mit ca. 300 Watt ausgelastet ist,
ca. 70 Watt im normalen Rendertest sind manchmal zu wenig um die 32 GT/s Link Speed zu erreichen.
GPU-Z.jpg

Lösen lässt sich das Kaltstartproblem relativ oft, wenn man im Mainboard Bios FCH Spread Spectrum aktiviert, Bild unten.
FCH Spread Spectrum.jpg

Eine Diskussion zum Thema Kaltstartproblem gab es zuletzt unten im Link.
@Induktor kennt sich mit dem Problem gut aus, er ist von einem MSI MPG X870E Carbon WIFI auf ein ASUS X870E Dark Hero Mainboard gewechselt und hat seitdem keine Kaltstartprobleme mehr.
 
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