AMD 3200G - Detected CPUs with inconsistent variable MTRR settings

Ratz_Fatz

Banned
Registriert
Mai 2011
Beiträge
1.111
Ich habe eine SSD mit Ubuntu 19.04 drauf, dmesg zeigte mir etwas an, worauf ich nachforschte. Aber ich kann das nicht einordnen. System ist ein Asrock A300 mit AMD 3200G CPU.

Kann mir jemand etwas dazu sagen?

Code:
dmesg -x -l crit,err,warn
kern  :warn  : [    0.349484] mtrr: your CPUs had inconsistent variable MTRR settings

Daraufhin habe ich "fwts"(Link) installiert und mit "fwts mtrr -" laufen lassen. Ergebnis:

...
Test 2 of 3: Validate the MTRR setup across all processors.
Detected CPUs with inconsistent variable MTRR settings which the kernel fixed.
FAILED [MEDIUM] MTRRCPUsMisconfigured: Test 2, It is probable that the BIOS does
not set up all the CPUs correctly and the kernel has now corrected this
misconfiguration.
...
================================================================================
2 passed, 1 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
...
Medium failures: 1
mtrr: It is probable that the BIOS does not set up all the CPUs correctly and the kernel has now corrected this misconfiguration.
...
 
BIOS ist v3.50? Irgendetwas im BIOS verstellt?
 
Ratz_Fatz schrieb:
Kann mir jemand etwas dazu sagen?
(selbst noch nie davon gehört) - bei solchen Fehlern/Warnungen kann der Linux-Quellcode oft weiterhelfen.
(alles weitere via suche im code)

Die Warnung wird vom Modul "mtrr" ausgegeben. Im Quellcode ist das unter arch/x86/kernel/cpu/mtrr/generic.c Zeile 511
Kommentar
/* Some BIOS's are messed up and don't set all MTRRs the same! */
Einen längeren Text liefert die Feature-Konfigurationsoption, (Kconfig: CONFIG_MTRR), die für das Modul verantwortlich ist. Da steht
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
processor access to memory ranges. This is most useful if you have
a video (VGA) card on a PCI or AGP bus. Enabling write-combining
allows bus write transfers to be combined into a larger transfer
before bursting over the PCI/AGP bus. This can increase performance
of image write operations 2.5 times or more. Saying Y here creates a
/proc/mtrr file which may be used to manipulate your processor's
MTRRs. Typically the X server should use this.
[...]
Saying Y here also fixes a problem with buggy SMP BIOSes which only
set the MTRRs for the boot CPU and not for the secondary CPUs. This
can lead to all sorts of problems, so it's good to say Y here.

Der Link & Inhalt auf die weitere Dokumentation mtrr legt dann nahe, dass im Kernel aktuell dieses CPU Feature nicht mehr genutzt wird und es außerdem ersetzt wird durch den Nachfolger PAT.
Direct MTRR use by drivers on Linux is now completely phased out

Selbst wenn der Kernel das Feature nicht nutzt, kann es eventuell durch Userspace (eventuell früher Xorg siehe oben, binary closed source Treiber ?) oder wie in mtrr.txt geschrieben
An example of platform use of MTRRs is through the use of SMI handlers, one case could be for fan control,
benutzt werden.

Da der Eintrag "gefixt wurde" , sollten keine Probleme entstehen
 
  • Gefällt mir
Reaktionen: Innensechskant und DiabloJulian
Okay, danke. Also deutet das auf ein buggy Bios hin, soweit ich verstanden habe. Bios Version ist die 3.50. Ich habe ein paar Einstellungen gemacht, wüsste aber nicht, welche davon Auswirkungen auf MTRR haben sollte.

Ich füge dann die Zeile
Code:
enable_mtrr_cleanup
in grub hinzu, wie hier vorgeschlagen.

#######################################################

Allerdings hatte ich ein paar Probleme nachdem ich Windows im UEFI Mode installiert habe(hier nachzulesen). Ich wüsste gern, warum die SSD nun kein SecureErase mehr unterstützt, vorher konnte ich sie im Bios damit löschen, nach der Windows Installation nicht mehr.

Weitere Probleme treten mit USB und powertop auf, wenn ich die Vorschläge aktiviere, dann freezt der PC nach dem Standby oder es taucht ohne powertop diese Meldung auf. Es reicht in Bezug auf "freeze", die Vorschläge von powertop für USB 3.1 und USB-Ports herauszunehmen.

Code:
kern  :err   : [   81.369907] kfd2kgd: cp queue preemption time out.
kern  :warn  : [   82.274446] [drm] psp command failed and response status is (-65529)

Außerdem erhalte ich ein:
Code:
[drm] BIOS signature incorrect 0 0

Nach dem Aufwachen aus dem Standby sehe ich manchmal nur die Meldung:
Code:
EXT4-fs error (device dm-1): _ext4_find_entry:1491: inode #655824: comm gdm-session-wor: reading directory lblock 0
Nach einem Neustart taucht dann ein "corrupt journal" Einträge auf. Hier hatte ich danach gefragt.
Code:
journalctl --verify
80cb60: Data object references invalid entry at 8eb1a0
File corruption detected at /var/log/journal/dabfb..../system@0005...bcf.journal~:8eaf58 (of 16777216 bytes, 55%).

dmesg|grep corrupted
[ 18.938433] systemd-journald[928]: File /var/log/journal/dabfb.../system.journal corrupted or uncleanly shut down, renaming and replacing.
[   22.783302] systemd-journald[928]: File /var/log/journal/dabfb.../user-1000.journal corrupted or uncleanly shut down, renaming and replacing.

Wenn das wirklich alles nur am Bios liegt, dann sollte es mal demnächst ein update geben. Mit HDMI hatte ich dann noch ein paar mehr Probleme, der Bildschirm ist jetzt an Display-Port angeschlossen, damit kamen zu den hunderten Kernel-Warnungen in Fedoras Fehlerberichterstattung keine neuen mehr hinzu.

Code:
kern  :warn  : [    2.495006] WARNING: CPU: 2 PID: 462 at drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1690 core_link_enable_stream.cold+0xa7/0x1ef [amdgpu]
kern :warn : [ 2.495007] Modules linked in: amdgpu amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel drm ghash_clmulni_intel r8169 wmi video pinctrl_amd
kern :warn : [ 2.495013] CPU: 2 PID: 462 Comm: plymouthd Not tainted 5.2.8-200.fc30.x86_64 #1
kern :warn : [ 2.495014] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A300M-STX, BIOS P3.50 05/15/2019
kern  :warn  : [    2.495060] RIP: 0010:core_link_enable_stream.cold+0xa7/0x1ef [amdgpu]

Vielleicht fällt dem ein oder anderen noch etwas dazu ein.
 
Zuletzt bearbeitet:
Das System ist irgendwie eigenartig. Ich dachte letztens, als ich einen Befehl ins Terminal von Gnome eingegeben habe, dass dort was falsch angezeigt wird. Nun konnte ich es direkt festmachen.

Per Terminal-Auswahl mit Pfeiltasten, wollte ich den Firefox öffnen, wurde schon öfter ausgeführt. Es wurde auch soweit korrekt angezeigt, in dem Moment wo ich die Eingabetaste drücke, ändert sich die Befehlszeile leicht.

Eigentlich müsste am Ende folgendes stehen: "firefox -p home".

Der Browser wird auch geöffnet, nachdem ich den wieder geschlossen habe steht dort "firefox -p home" statt wie vorher "mule".

Ich habe kein Ahnung, wie so ein Verfälschung zustande kommt. Es gibt einfach auch kein "mule" Profil.

Weiß jemand dazu etwas?
 

Anhänge

  • firefox.png
    firefox.png
    30,8 KB · Aufrufe: 306
Also ich würde Asrock um ein Betabios bitten.
Du hast ja einen 3200G, der eigentlich erst mit Agesa 1.0.0.3ABB richtig vernünftig läuft.
 
Ratz_Fatz schrieb:
Ratz_Fatz schrieb:
in grub hinzu, wie hier vorgeschlagen.
Unnötig eigentlich. Der Kernel in 19.04 = Disco Dingo fixt doch das potentielle "MTRR" Problem per default (weil Kernel Message) - seit "Oneiric" also 11.10 (!) lt. Doku der MTRR seite
Ratz_Fatz schrieb:
freezt der PC nach dem Standby
Korrekt funktionierendes Standby braucht viele Tests, korrekte Bios/UEFI Einträge & Einstellungen und passende Hardware.
Angesichts der vielen Modi reicht die Fehlerbeschreibung "freeze" nicht wirklich aus - (zB geht hier bei reddit um ältere Ryzen & sleep/power saving modes) - vielleicht einfach Bios Einstellungen durchtesten.
Da die meisten User keine Zeit haben und wenig Expertise haben und bei den Linux-Entwicklern nicht genug Geld zum (Nach-)Kauf der Hardware zum Bug-Replizieren vorhanden ist, können die Fehler nicht schnell behoben werden - Hibernate Debugging Best Practises ist sehr umfangreich - Lesen, Suchen und Testen kostet dann richtig viel Zeit - in der der PC auch uU nicht produktiv genutzt werden kann, weil auf den Fehler gewartet werden muss.

Tendenziell gilt bei den Bugs auch immer/wird oft gefragt : Tritt das Problem im neuesten (Mainline/Developer) Kernel auf ?
Ratz_Fatz schrieb:
ändert sich die Befehlszeile leicht.
Gibt es schon solchen Bug in den Bugtrackern von Gnome ... ?
Bug im Software-Stack beim Terminal-Programm -> anderes Terminal testen (xfce4-terminal, konsole, lx-terminal ...)
Bug im Software-Stack an anderer Stelle -> Desktop Beschleunigung deaktivieren und nochmal das gleiche versuchen/Software Rendering nutzen : Bei einem "Redraw" des Gnome Fensters wird irgendwoher die falsche Glyphe (Buchstabe) benutzt oder die "Textur" des Fensters wird korrupt ; das gleiche in KDE/XFCE ... testen

Ich vermute dass deine Probleme mit der Festplatte (ext4....) und Journal durch den Standby mitverursacht sind - unvollständiger Schreibvorgang auf SSD beim Herunterfahren/Wechseln in Standby bei den Logdaten oder ein Bug im "Suspend" Vorgang irgendeiner Komponente.

Ratz_Fatz schrieb:
dc_link.c:1690 core_link_enable_stream.cold
Naja - es könnte der gleiche oder ein ähnlicher Bug sein wie
https://bugs.freedesktop.org/show_bug.cgi?id=108940 - immerhin nur ein "Warning" ^^
 
  • Gefällt mir
Reaktionen: Ratz_Fatz
Zurück
Oben