MCE Harware Error - Asrock A300 und AMD 3200G - Fedora 31 - Debian Sid

[Ratz_Fatz]

Ich habe ein paar Fragen. Ich verwende den Asrock A300 mit einem 3200G. Eine Zeitlang habe ich Fedora 30 dann Fedora 31 verwendet. Dann habe ich Debian Sid installiert.

Testweise habe ich die TSME und Iommu deaktiviert. Danach tauchten unter beiden Installationen Fehlermeldungen auf, die kurioserweise den ganzen Abend weiter bestanden, auch nach Neustarts. Am nächsten Morgen waren sie nicht mehr da.


Es tauchte nach Deaktivierung der Iommu das neu erkannte Gerät auf, vorher wurde es scheinbar nicht gefunden.

nct6775: Found NCT6793D or compatible chip at 0x2e:0x290

Fedora ABRT hat an der Stelle das dmesg Logging gestoppt, als "nct6775" aufgetaucht ist. Es tauchte dann mit ABRT eine mce: [Hardware Error] auf.Edit(sensors-detect hat dafür gesorgt, dass der chip gefunden wurde).

Außerdem habe ich Anfangs unter Fedora(auch mit aktivierter Iommu) öfters Probleme gehabt, dass mir ab und zu im Terminal Buchstaben eingefügt wurden, wenn ich z.B. Firefox mit "firefox -p multi" starten wollte, wurde ein "firefox -p mule" daraus gemacht, Firefox startete dennoch mit dem richtigen Profil.

EditDas mit folgende Problem scheint ein Fedora Bug zu sein, tritt unter anderen System auch auf(auch mit z.B. ".bash_-history")

Jetzt habe ich gesehen, unter Fedora 31 Probleme mit dem Thunderbird-Profil . Aus ".thunderbird" wurde ".-thunderbird".
Problem, ich bekomme das "-" nicht umbenannt, weil das "-" unter "Umbenennen" nicht mehr vorhanden ist.
Unter Debian Sid passiert das mit dem Thunderbird bis jetzt noch nicht, ist aber auch noch nicht so lange installiert.

Muss die Iommu aktiviert bleiben, weil darüber auch Fehlerkorrekturen stattfinden? Anderseits gab es auch mit Iommu einige segfault in Nautilus und dbus und die Veränderungen im Terminal.

Seit kurzem hatte ich auch Probleme mit dem Herunterfahren über Gnome(Ausschalten). Das wurde einfach nicht ausgeführt, auch nicht, im Anmeldebildschirm. Mit "systemctl poweroff" im Terminal fährt das System herunter. Das tritt aber nicht immer auf. Das war dann unter Debian Sid, Fedora 31 und Ubuntu 19.10 der Fall. Auf einem anderen Intel-System treten diese Fehler nicht auf.

Kann mir jemand erklären, was es mit den MCE auf sich hat?

 

[lokon]

Wenn du einen Ausschnitt aus dem Kernel-Log / die dmesg Ausgabe postest, dann achte darauf, dass vollständige Zeilen enthalten sind.

zB was für eine Zahl steht hinter microcode

Beim googlen finden sich viele verschiedene Machine Check Exception Fehler von AMD, wenn nach MISC d012000100000000 gesucht wird.
Der Fehler kann irgendwo sein - wie dieser Wikieintrag dokumentiert.
Bios/Firmware-Update, Microcode-Update, neuere Kernelversion, Kernelparameter (also ob IOMMU eingeschaltet ist) können alle das Auftreten beeinflussen.

Die IOMMU wird afaik bei Virtualisierung von PCIe Geräten benötigt.

 

[Ratz_Fatz]

Microcode habe ich oben eingefügt, hatte ich beim markieren und kopieren vergessen.

ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[drm] BIOS signature incorrect 0 0
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

Das konnte ich lösen, indem man im Bios CSM deaktiviert.

Dann hatte ich noch in dem Thread etwas zum TPM Problem geschrieben:

Zu den Problemen:
Bei mir besteht das USB-Problem weiterhin, sowohl unter Fedora 31,Debian Sid und Windows 10. Dort muss ich am Front USB 3.0 Anschluss das USB-Gerät immer ein zweites Mal anschließen.

Dann gibt es ein fTPM Problem. Hier ein Bug-Report dazu. Ich benötige nicht das fTPM, aber Debian scheint ein paar Probleme damit zu haben, wenn es deaktiviert ist: "secureboot: Secure boot could not be determined (mode 0)".

Debian Sid fTPM aktiviert:

kern  :err   : [    8.742639] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80

Ubuntu 19.10 fTPM aktiviert:

kern  :err   : [    0.636600] tpm_crb MSFT0101:00: can't request region for resource [mem 0xac171000-0xac174fff]
kern  :warn  : [    0.636605] tpm_crb: probe of MSFT0101:00 failed with error -16

Da muss Asrock langsam ein Bios Update herausbringen. Wenigstens ein paar Korrekturen mit einer neueren AGESA.

Iommu=soft geht nicht, es geht dafür z.B. "iommu=pt". Mit "noapic" bekomme ich mit dmesg mehr angezeigt, als ohne "noapic". Die Sternchen habe ich eingefügt.

dmesg -x -l crit,warn,err
kern :warn : [ 0.000000] secureboot: Secure boot could not be determined (mode 0)
kern :warn : [ 0.158106] ACPI: setting ELCR to 0200 (from 0000)
kern :warn : [ 0.408686] Expanded resource Reserved due to conflict with PCI Bus 0000:00
kern :warn : [ 0.430923] ACPI: PCI Interrupt Link [LNKE] disabled and referenced, BIOS bug
kern :warn : [ 0.430937] ACPI: PCI Interrupt Link [LNKE] BIOS reported IRQ 0, using IRQ 10
kern :warn : [ 1.208413] pci 0000:00:00.2: can't derive routing for PCI INT A
kern :warn : [ 1.208418] pci 0000:00:00.2: PCI INT A: not connected
kern :warn : [ 1.211862] PPR NX GT IA GA PC GA_vAPIC
kern :warn : [ 1.942673] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 1.967595] ata2.00: supports DRM functions and may not be fully accessible
kern :err : [ 2.061062] hid-generic 0003:****:****.0002: No inputs registered, leaving
daemon:warn : [ 17.432138] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
kern :err : [ 17.777975] sp5100-tco sp5100-tco: Watchdog hardware is disabled
kern :err : [ 17.879332] kvm: disabled by bios
kern :err : [ 17.921987] kvm: disabled by bios
kern :err : [ 17.972659] kvm: disabled by bios
kern  :err   : [   18.032016] kvm: disabled by bios

 

[Ratz_Fatz]

Ich habe rasdaemon aktiviert. Weiß jemand was das hier ist?

ras-mc-ctl --errors
No Memory errors.

No PCIe AER errors.

No Extlog errors.

No devlink errors.

Disk errors
1 2019-10-17 23:42:33 +0200 error: dev=0:0, sector=-1, nr_sector=0, error='I/O error', rwbs='N', cmd='',

...

213 2019-10-18 00:57:07 +0200 error: dev=0:0, sector=-1, nr_sector=0, error='I/O error', rwbs='N', cmd='', 
214 2019-10-18 00:57:07 +0200 error: dev=0:0, sector=-1, nr_sector=0, error='critical target error', rwbs='N', cmd='',

Das hatte ich unter Fedora und davon 232 Einträge. Einen kleinen Auszug habe ich hier eingefügt.

00:57:27 rasdaemon: rasdaemon: register inserted at db
00:57:27 rasdaemon: rasdaemon: register inserted at db
00:57:27 rasdaemon: cpu 00:rasdaemon: diskerror_eventstore: 0x557ab14aa0e8
00:57:27 rasdaemon:            <...>-21    [000]     0.000008: block_rq_complete:    2019-10-18 00:57:24 +0200

01:01:52 gnome-shell: Set a breakpoint on '_pixman_log_error' to debug
00:57:27 rasdaemon: cpu 00:rasdaemon: diskerror_eventstore: 0x557ab14aa0e8
00:56:44 gnome-session-b: gnome-session-binary[1223]: WARNING: Error creating FIFO: Die Datei existiert bereits
00:56:41 rasdaemon: cpu 03:rasdaemon: diskerror_eventstore: 0x557ab14aa0e8

00:04:26 abrt-server: Not saving repeating crash in '/boot/vmlinuz-5.3.5-300.fc31.x86_64'
00:04:26 kernel: Not saving repeating crash in '/boot/vmlinuz-5.3.5-300.fc31.x86_64'
...
00:56:39 kernel: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rasdaemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Irgendwie wurde das alles für eine gewisse Zeit immer mehr unter Fedora 31. Manchmal geht die Passworteingabe(Luks) nicht oder es geht und dann hängt das System sich auf.

Ich nutze im Moment Debian Sid, damit scheint es besser zu laufen, bis auf die MCE Errors ab und zu oder Probleme mit den USB-Ports.

Kann jemand eine Einschätzung geben was das sein könnte?

 

[lokon]

rasdaemon

https://pagure.io/rasdaemon

Those tools provide a way to get Platform Reliability, Availability
and Serviceability (RAS) reports made via the Kernel tracing events.

Its long term goal is to be the userspace tool that will collect all
hardware error events reported by the Linux Kernel from several sources
(EDAC, MCE, PCI, ...) into one common framework.

Wenn du keine Bugs an den Kernel oder Fedora Bugtracker melden möchtest bzw. diese Fehler dann auch Debuggen möchtest oder die Entwicklerkernel wie linux-next, linux-drm-next usw. kompilieren und testen willst, dann brauchst du eigentlich auch keine Tracing Tools einschalten oder die Tracing Punkte abfragen.

Bei den Disk Fehlern macht Sector=-1 keinen Sinn - keine Ahnung was da genau im Kernel so gecodet ist, dass diese Nummer rausgegeben wird. Ist die Disk nicht vorhanden weil noch verschlüsselt ?

 

[Ratz_Fatz]

Das System bootet nicht richtig, wenn ich "acpi=off" einstelle. Nach der Eingabe des Passworts(mit Luks verschlüsselt) hängt das System fest.
Die anderen Systeme mit Intel CPUs (auch ein Asus mSTX dabei) starten hingegen mit "acpi=off" einwandfrei.

Dann scheint das System noch Probleme mit dem EFI Bootloader zu haben.

bootctl update
Failed to open "/boot/efi/EFI/systemd/systemd-bootx64.efi" for reading: No such file or directory
Skipping "/boot/efi/EFI/BOOT/BOOTX64.EFI", since it's owned by another boot loader.

grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Fehler: Kanonischer Pfad von »/efi« konnte nicht ermittelt werden.

Richtig ist /boot/efi.

 

[lokon]

Kanonischer Pfad von »/efi«

Anwendungsbeispiel bei https://wiki.archlinux.de/title/UEFI_Installation
sagt /boot - genauso die man page "use DIR as the EFI System Partition root."
Die EFI system partition ist meist unter /boot gemountet mit unterverzeichnissen oder unter /boot/efi

 

[Ratz_Fatz]

Ein Update.

Ich habe Fedora 31 neu installiert, seitdem verhält sich das System ruhig. Es treten bis jetzt keine "mce: [Hardware Error]" mehr auf, auch die "Disk errors" tauchen nicht mehr auf.

Ich habe dieses mal ein paar Grub Bootparameter gesetzt(schon beim Startvorgang vor der Installation):

amd_iommu=soft noapic pci=nocrs acpi_osi=Linux

Da muss irgendwas richtig schief gelaufen sein, denn auch die folgenden Updates hatten nichts geändert.

Ein Problem bleibt unter Windows. Dort verschwindet regelmäßig ein MBR Eintrag. Mit einem anderen System mit Intel CPU und ähnlichem Setup, Fedora, Ubuntu und Windows, passiert das nicht. Weil ich Windows und Ubuntu auf der anderen SSD nicht oft verwendet werden, ist das nicht so schlimm, aber komisch.

Ich habe jetzt noch pci=noapic eingefügt und dafür "noapic" weggelassen dann kommt das:

dmesg -x -l crit,warn,err
kern :err : [ 0.000000] PCI: Unknown option `noapic'
kern :warn : [ 0.209451] ACPI: setting ELCR to 0200 (from 0000)
kern :err : [ 0.210331] AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
kern :err : [ 0.210333] AMD-Vi: Disabling interrupt remapping
kern :warn : [ 0.471435] pci 0000:00:08.1: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 1.062012] pci 0000:00:00.2: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 1.065171] PPR NX GT IA GA PC GA_vAPIC
kern :warn : [ 1.076716] pcieport 0000:00:08.2: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 1.580852] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 1.609278] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 23.241498] printk: systemd: 24 output lines suppressed due to ratelimiting
kern :err : [ 24.451802] sp5100-tco sp5100-tco: Watchdog hardware is disabled
kern :err : [ 24.637261] kvm: disabled by bios
kern :err : [ 24.650668] kvm: disabled by bios
kern :err : [ 24.669178] kvm: disabled by bios
kern  :err   : [   24.689791] kvm: disabled by bios

Was ist das denn "AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found"? Wenn ich ein "noapic" einfüge verschwindet das mit "AMD-Vi" wieder.

Mit "acpi=off" kriege ich nur KernelPanics mit SMP NOPTI, mit noapic startet das System. Wenn ich "ignore_bad_msr=yes" hinzufüge zu "acpi=off", dann startet das System mit ATA Fehlern und hängt sich dann auf.

 

[lokon]

Dein Bericht ist etwas unübersichtlich mit den ganzen Kernel-cmdline-Parametern, Fehlern und Screenshots.

https://www.kernel.org/doc/html/v5.3/admin-guide/kernel-parameters.html

bzw. deine Kernelversion - da steht nicht das pci=noapic gültig wäre - also eine erlaubte option ist - deshalb meckert das "PCI:" im log auch über den noapic Parameter

Wenn du so viel mit den Kernelparametern experimentierst, solltest du die Bugs auch melden - den ersten Kernelfehler mit "Not tainted" zB.

Wieso kommst du auf NOPTI - in der Doku steht doch "entfernt Hardening" - also macht etwas potentiell instabiler.
Und woher kommt acpi_osi ? Das sorgt auch kein normaler Bootparameter und spielt mit den Bios / Acpi - keine Ahnung wie das mit acpi=off interagiert.

Un bei den Disk Errors - siehe Screenshot 1 IMG.... - da steht dass die SATA Geschwindigkeit reduziert wird, weil ein Kommando nicht geklappt hat.
Also kein SATA-6G gerät am Kabel hängt - vlt. irgendetwas altes, dass "normal" mit Sata-1.5G funktioniert ?

 

[Ratz_Fatz]

Die Parameter habe ich von hier. Ich habe die Parameter gesetzt, weil es damit besser läuft.
Beim ersten Versuch unter Debian und Fedora hatte ich ja nichts aktiviert und so belassen, das ging richtig schief. Ich habe ja weitere, ähnliche Intel Systeme, da war nichts dergleichen. Update liefen problemlos, die Systeme auch.

1. Auf "Ooops: [#2] SMP NOPTI" komme ich wegen dem hier smp nopti.jpg. Der Fehler, der nach dem einfügen von acpi=off passiert. Die anderen System lauf auch mit acpi=off.

2. apci=off endet immer in einem KernelPanic mit dem "SMP NOPTI".

3. Sata
Es sind beides Crucial SSD die jetzt damit laufen "ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)"

4. Der Kernel ist doch "tainted"(nur mit acpi=off und amd_iommu=soft).

The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
unloaded, the tainted value remains to indicate that the kernel is not
trustworthy. Quelle

Das Problem, manchmal kann ich nach einem Neustart nicht den Kernel laden, F11 und Fedora ausgewählt, lande ich im Bios. Ein weiteres Mal war unter Debian Testing die SSD Zuordnung vertauscht.

Ich gehe mittlerweile davon aus, dass es Hardware/Bios Fehler sein könnte.
Die Kiste hat mir wahrscheinlich eine NVME geschrottet. Nach einer Woche, wollte ich den PC einschalten, dann wurde sie in keinem der PCs mehr erkannt.
Ich denke, da werde ich auf das von Asrock "unbekannten Datums" versprochene Bios-Update warten müssen. Ich hatte die deswegen mal angeschrieben.

Danke für deine Hilfe. Ich denke, ich werde es dabei belassen, solange es so läuft.

 

[Ratz_Fatz]

Ich habe weiter ausprobiert. "acpi=off" geht alleine nicht. Der Kernel hängt dann immer fest.
Jetzt habe ich "acpi=off" zusammen mit "mitigations=off" verwendet. Das System lädt, aber mit nur einem Kern, 3 Kerne fehlen. Fällt jemand dazu etwas ein?

dmesg -x -l crit,warn,err
kern :warn : [ 0.072777] smpboot: Boot CPU (id 0) not listed by BIOS
kern :warn : [ 0.329905] pci 0000:00:08.1: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 3.660231] pcieport 0000:00:08.2: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 4.184090] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 4.211555] ata2.00: supports DRM functions and may not be fully accessible
kern :err : [ 5.346911] hid-generic 0003:045E:0823.0004: No inputs registered, leaving
kern :warn : [ 19.021717] printk: systemd: 27 output lines suppressed due to ratelimiting
kern :err : [ 22.505571] sp5100-tco sp5100-tco: Watchdog hardware is disabled
kern :err : [ 23.499517] kvm: disabled by bios
kern :warn : [ 23.775937] CRAT table not found
kern :warn : [ 23.776717] DSDT table not found for OEM information
kern :err : [ 24.077063] kfd kfd: error getting iommu info. is the iommu enabled?
kern :err : [ 24.077066] kfd kfd: Error initializing iommuv2
kern :err : [ 24.077176] kfd kfd: device 1002:15d8 NOT added due to errors
kern :warn : [ 24.194606] kauditd_printk_skb: 43 callbacks suppressed
kern :err : [ 28.554343] db_root: cannot open: /etc/target

 

[lokon]

Afaik haben AMD CPUs doch keinen großen Performance-Verlust durch die CPU - phoronix sagt 3% (geometrisches Mittel) bei Kernel 5.0 auf einem AMD Ryzen 7 2700X.

Eventuell kannst du die Cores via sysfs starten lassen.
Gibt aber genug einträge bei google über Bios, SMT und fehlende CPU Kerne mit acpi=off
Ansonsten greift mitigations= in den Kernel ein - vielleicht ist da Bug mit den Flags - da Varianten davon SMT deaktivieren.

Wär halt interessant zu wissen wo der Kernel konkret festhängt - nicht das ein Fehler in der Stromversorgung (PSU, Board) existiert, der zum "zufälligen" Abschalten von Komponenten führt - also das die CPU stillsteht, weil die Spannung schlecht ist.
Die Hardware läuft wohl unter Linux lt. Kommentaren vieler user bei reddit.

 

[Ratz_Fatz]

Ich habe ja kein SMT an, weil der AMD 3200G gar kein SMT kann. Im Bios kann man unter "Downcore Control" die Anzahl der Kerne einstellen, die reduziert werden sollen. Selbst das klappt nicht, nur "Auto" funktioniert. Der Tipp mit "sys" funktioniert auch nicht.

Irgendwie funktioniert es ja mit ACPI, aber die müssen irgendwas so verändert haben, dass ohne fast nichts mehr geht. Und die Frage ist warum man mitigations ausschalten muss, damit man mit ACPI=off starten kann.

Zum Kernel, der hängt dann mit "acpi=off" bei "Starting Load Kernel Modules ..." fest.

Ich habe jetzt noch ein "nosplash debug --verbose" angehängt damit kommt noch etwas mehr an Infos(mit DowncoreControl aus dem Bios).

dmesg -x -l crit,warn,err
kern :warn : [ 0.045550] smpboot: Boot CPU (id 0) not listed by BIOS
kern :warn : [ 0.117608] pci 0000:00:08.1: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 0.287539] pcieport 0000:00:08.2: can't find IRQ for PCI INT A; please try using pci=biosirq
kern :warn : [ 0.676113] platform eisa.0: Cannot allocate resource for EISA slot 1
kern :warn : [ 1.011917] powernow_k8: This CPU is not supported anymore, using acpi-cpufreq instead.
kern :warn : [ 1.750968] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc-early' as unstable because the skew is too large:
kern :warn : [ 1.765118] clocksource: 'refined-jiffies' wd_now: fffedc08 wd_last: fffedb88 mask: ffffffff
kern :warn : [ 1.776512] clocksource: 'tsc-early' cs_now: 30cefab7fc cs_last: 303c84249c mask: ffffffffffffffff
kern :warn : [ 1.799644] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
kern :warn : [ 2.115425] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 2.119449] ata1.00: READ LOG DMA EXT failed, trying PIO
kern :err : [ 2.127425] ata1.00: failed to set xfermode (err_mask=0x40)
kern :warn : [ 7.175746] ata2.00: supports DRM functions and may not be fully accessible
kern :warn : [ 13.515900] kvm: disabled by bios
kern :warn : [ 13.687616] CRAT table not found
kern :warn : [ 13.687618] DSDT table not found for OEM information
kern :err : [ 14.612855] kfd kfd: error getting iommu info. is the iommu enabled?
kern :err : [ 14.612861] kfd kfd: Error initializing iommuv2
kern :err : [ 14.613296] kfd kfd: device 1002:15d8 NOT added due to errors

Hältst du es für möglich, dass das ACPI von Asrock so fehlerhaft ist, dass dadurch die Symptome wie ich sie feststelle auftreten? Scheint mir fast so, als seien die Symptome maskiert worden.

Edit
Zu "Crat table":

The CRAT table, and disabled IOMMU in the BIOS has been an issue on many Carrizo laptops too. I think it's unrealistic to expect that OEMs will release updated BIOS images with fixes for that, because these features aren't used at all on Windows, which is typically the only OS the OEMs officially support. Quelle

Zu "DSDT table":

Die benötigten Software-Werkzeuge werden von Intel oder Microsoft zum kostenlosen Herunterladen angeboten, so dass es für Menschen mit ASL-Kenntnissen möglich ist, fehlerhafte Tabellen, hier vor allem die DSDT (Differentiated System Description Table) selbst zu reparieren.

Fehlerhafte Tabellen führen besonders unter alternativen Betriebssystem wie Linux oder xBSD zu Problemen, da einige Hauptplatinenhersteller ihre Tabellen nur unter Microsoft Windows testen. Die Microsoft-ACPI-Implementierung ist dafür bekannt, an einigen Stellen nicht zeichengetreu den Standard zu befolgen, so dass eventuelle Probleme den Herstellern nicht auffallen. Quelle

 

[lokon]

Ich würd ja inzwischen fast sagen das da irgendwo ein Hardwaredefekt ist - bei den seltsamen Problemen.
(Kurzschluss irgendwo beim Einbauen?, Verbogene Pins ? ....)

AMD 3400G mit A300 und erfolgreichem Solus Linux mit 5.1.x Kernel und Phoronix Testsuite
AMD 3400G mit A300 und Arch Linux mit 5.2.x
dazu noch andere Threads mit Cinnamon und Ubuntu Varianten.

Über den ACPI Schalter lese ich dabei nichts - also ist das ACPI eher nicht fehlerhaft, denn sonst sollten die anderen Distributionen auch Probleme haben.
Die Tabellen lassen sich vielleicht über Bios Reset und dann ein neuen Bios-Flash auch reparieren.

Vielleicht die PSU/Stromversorgung auswechseln (Kabel bzw. Netzteil) und vielleicht die SSD abklemmen und versuchen wie ein Live-Image von USB bootet. Läuft memtest ohne Probleme ?