alter PC mit i7-2600 und Asus P8H67-M EVO stürzt ab Thema ist als GELÖST markiert

[Clemens]

Ich habe hier noch einen alten PC aus 2013 mit i7-2600K CPU auf Asus Board P8H67-M EVO und 16GB RAM, SSD usw.. Den habe ich mir mit Manjaro XFCE wieder flott gemacht. Läuft für meine Verhältnisse super schnell dank 4 Cores und 8 Threads.

Leider stürzt er regelmäßig nach kurzer Zeit ab, sobald ich z.B. mittels Screenreader ein laufendes Video mitschneiden will. Um dem Fehler auf die Spur zu kommen, habe ich natürlich zunächst fwupd laufen lassen und danach stress-ng und den ffmpeg Stresstest. Da lief der PC über 30 Minuten stabil bei 100% CPU-Last. Auch ein RAM-Test lief einwandfrei durch.

Wenn ich nach einem Neustart dmesg anschaue, erhalte ich folgende Fehlermeldungen (in roter Schrift) incl. Meldungen vor dem Fehler und nachher:

Code: Alles auswählen

ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata3: SATA link up 1.5 Gbps (SStatus 133 SControl 300)
ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT1._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ata2.00: supports DRM functions and my not be fully accessible
ata2.00: ATA-8: ST1000NV000-1CX162, CE03, max UDMA/133
ata2.00: ....
...
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT2._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT2._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ata3.00: ATAPI: HL-DT-ST DVDRAM GH24NSB0, LM00, max UDMA/133
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT1._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT1._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT0._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT0._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ata2.00: supports DRM functions and my not be fully accessible
ata1.00: supports DRM functions and my not be fully accessible
ata1.00: ATA-9: Samsung SSD 850 PRO 256GB, EXM02B6Q, max UDMA/133
ata2.00: Security LoG not supported
ata2.00: configured for UDMA/133
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT2._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT2._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ata3.00 configured for UDMA/133
ata1.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 32), AA
ata1.00: Features: Trust Dev-Sleep NCQ-sndrcv
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0SPT0._GTF.DSSP]. AE_NOT_FOUND (20220331/psargs-330)
ACPI Error: Aborting method \_SB.PCI0.SAT0SPT0._GTF due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
ata1.00: supports DRM functions and my not be fully accessible
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct Access    ATA    SAMSUNG SSD 850 2B6Q PQ: 0  ANSI: 5
.....

Viel später im dmesg kommen dann noch ACPI Warnings:

Code: Alles auswählen

ACPI Warning: SystemIO range 0x0000000000000428-0x0x000000000000042F conflicts with OpRegion 0x0x0000000000000400-0x000000000000047F (\PMIO) 820220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?
ACPI Warning: SystemIO range 0x0000000000000540-0x0x000000000000054F conflicts with OpRegion 0x0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPCB.GPBX) (20220331/utaddress-204)
ACPI Warning: SystemIO range 0x0000000000000540-0x0x000000000000054F conflicts with OpRegion 0x0x0000000000000500-0x000000000000057F (\GPI0) (20220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?
ACPI Warning: SystemIO range 0x0000000000000530-0x0x000000000000053F conflicts with OpRegion 0x0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPCB.GPBX) (20220331/utaddress-204)
ACPI Warning: SystemIO range 0x0000000000000530-0x0x000000000000053F conflicts with OpRegion 0x0x0000000000000500-0x0000000000000563 (\GPI0) (20220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?
ACPI Warning: SystemIO range 0x0000000000000500-0x0x000000000000052F conflicts with OpRegion 0x0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPCB.GPBX) (20220331/utaddress-204)
ACPI Warning: SystemIO range 0x0000000000000500-0x0x000000000000052F conflicts with OpRegion 0x0x0000000000000500-0x000000000000050F (\_GPE.GPI0) (20220331/utaddress-204)
ACPI Warning: SystemIO range 0x0000000000000500-0x0x000000000000052F conflicts with OpRegion 0x0x0000000000000500-0x0000000000000563 (\GPI0) (20220331/utaddress-204)
ACPI: OSL: Resource conflict; ACPI support missing from driver?
lpc_ich: Resource conflict(s) found affecting gpio_ich
......

Es muss also irgend etwas mit ACPI und einem möglicher Weise fehlendem Treiber sein, der dann evtl. zu Adresskonflikten führt. Mich wundert dann aber, wieso die Stresstests einwandfrei durch gelaufen sind.

Wie gesagt, hatte ich fwupd durchlaufen lassen. Aber es meldet auch, dass "Aktualisierung der UEFI-Kapsel nicht verfügbar oder in der Firmware-Einrichtung aktiviert sei.
Da es zu diesem BIOS aber gewiss kein Update mehr gibt und ich sicher bin, dass ich damals das letzte verfügbare installiert hatte, dürfte diese Meldung keine Rolle spielen. FWUPD meldet auch, dass keine weiteren Updates für irgendwas verfügbar sind.

Übrigens hatte ich in 2015 das Mainboard und später auch das Netzteil (beQuiet) getauscht, weil da auch schon mal Absturzfehler vorkamen. Alle anderen Teile sind aber geblieben.

Die Abstürze geschehen übrigens ohne jegliche Fehlermeldung. Es ist, als ob man die Netzspannung abschaltet und der PC dann automatisch neu bootet. Daher habe ich auch noch kein Error.log usw. gefunden, in dem dieser Absturz protokolliert wäre.

Was kann ich jetzt noch tun, um den Fehler zu finden? Oder ist Wegwerfen die "Lösung"?

[LaGGGer]

Die Abstürze geschehen übrigens ohne jegliche Fehlermeldung. Es ist, als ob man die Netzspannung abschaltet und der PC dann automatisch neu bootet. Daher habe ich auch noch kein Error.log usw. gefunden, in dem dieser Absturz protokolliert wäre.

Wenn deine Tests/Stesstests einwandfrei durchlaufen und da nichts passiert, vermute ich mal das an deinem Screenreader liegt.

Verrätst du uns welchen Screenreader du benutzt?

Hast du die Systemüberwachung (gnome-system-monitor) installiert? Ich hätte schwören können die war früher bei XFCE dabei, jetzt anscheinend nicht mehr.
Damit kannst du die Auslastung grafisch sehen wenn dein Programm läuft. Möglicherweise gibts da was auffälliges zu sehen.

Könnte auch ein Temperatur Problem sein wenn sich der PC einfach so abschaltet.

[country]

https://web.archive.org/web/20171228022 ... .net/?p=24

[Clemens]

Vielen Dank für eure Antworten. Als ScreenRecorder nutze ich SimpleScreenrecorder auf allen meinen Linux-PCs. Überall läuft er bisher absolut stabil, nur auf diesem alten PC nicht. Ich habe noch einen Fujtsu Laptop aus dem Jahr 2011. Auch darauf läuft der ScreenRecorder einwandfrei.

Der Hinweis auf das Wayback-Archiv hat mich weiter gebracht: Nachdem ich ACPI in GRUB deaktiviert hatte, enthielt dmesg die im ersten Block meines Anfangspost enthaltenen Fehlermeldungen nicht mehr.

Jedoch wurden nach wie vor die Adresskonflikte gemeldet, die ich im zweiten Block genannt habe.

Hab gerade wenig Zeit dran zu bleiben. Aber ein erster kurzer Test mit dem ScreenRecorder lief stabil. Das heißt aber nix, weil die schlagartigen Voll-Abstürze immer erst nach ein paar Minuten erfolgt sind.

Übrigens dürfte es thermisch keine Probleme im PC geben, denn sonst wäre er schon bei den anfangs erwähnten Stress-Tests abgestürzt. Die Kühlkörper und Staubfilter sind sauber und alles wird überdimensioniert mit geregelten 120mm-Lüftern gekühlt.

Wie komme ich denn jetzt dem Fehler mit den Adresskonflikten denn auf die Spur?

[LaGGGer]

Überall läuft er bisher absolut stabil, nur auf diesem alten PC nicht. Ich habe noch einen Fujtsu Laptop aus dem Jahr 2011. Auch darauf läuft der ScreenRecorder einwandfrei.

Das hat nichts zu sagen. Hast du mal einen anderen Screenrecorde probiert und ob der stabil läuft?
Beispielsweise der leichtgewichtige VokoscreenNG, gut für alte Rechner.

Es geht sogar mit VLC:
https://www.globalsystem.ch/ratgeber/vi ... lc-player/

Es wäre die einfachste Lösung wenn ein Programm auf einem Rechner nicht gescheit läuft, einfach mal ein anderes testen.
Und vielleicht sogar behalten weils besser ist und absturzfrei läuft.

[Clemens]

So, bin zurück...
Der ScreenRecorder lief jetzt rund 45 min lang. Kein Absturz! Und die Meldungen des ScreenRecorders zeigten keine Auffälligkeiten wie z.B. Aussetzer in Bild oder Ton.

Habe gerade den VokoScreenrecorder installiert und kurz angetestet. Das Teil ist wirklich überzeugender, als der SimpleScreenrecorder und bietet bei einfacher Bedienung mehr Features. Herzlichen Dank für diesen Tipp!

Anscheinend läuft der PC jetzt trotz der Adress-Konflikte stabil. Aber wirklich trauen tue ich dem noch nicht. Die Adresskonflikte haben ja eine Bedeutung und eine Auswirkung…

Deshalb weiterhin meine Frage:
Wie komme ich denn jetzt dem Fehler mit den Adresskonflikten denn auf die Spur?

[LaGGGer]

Deshalb weiterhin meine Frage:
Wie komme ich denn jetzt dem Fehler mit den Adresskonflikten denn auf die Spur?

Sorry, da kann ich dir nicht weiterhelfen. Aber du hast doch keine Abstürze mehr, was solls.

Off-topic

Übrigens....

Wenn ich nach einem Neustart dmesg anschaue, erhalte ich folgende Fehlermeldungen (in roter Schrift).....

....funktioniert das nicht in einer CodeBox, auch nicht die anderen Formatierungen. In Zitaten geht es wie du siehst.
Habe ich schon mehrfach angemahnt, ist aber anscheinend nicht gewollt.

Ich mache das manchmal, wenn ich was farblich hervorheben will, mit der NFO-ASCII-Art-Text Formatierung:
[⁣nfo]Text[/nfo]
Ist ähnlich wie ne CodeBox, aber bei langen Texten leider Unbrauchbar.
Das nur nebenbei.

[country]

Deshalb weiterhin meine Frage:
Wie komme ich denn jetzt dem Fehler mit den Adresskonflikten denn auf die Spur?

Würdest du meinen link folgen und durchlesen wäre es schön längst passiert. Laut der Website gibt es ein ACPI Problem mit dem Chipsatz H69 Abhilfe mit grub parameter

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="libata.noacpi=1

" und grub neu generieren.
Soll das Problem lösen.

[Clemens]

Es tut mir Leid, dass ich diese essenziell wichtige Info nicht deutlich genug mitgeteilt hatte:

Der PC läuft "anscheinend" stabil, nachdem ich dem Link gefolgt bin und ACPI durch den Eintrag in der GRUB-Datei libata.noacpi=1 deaktiviert hatte.

Dennoch bleiben die genannten Adress-Konflikte. Und deshalb blieb auch meine Frage, wie ich die Ursache dafür finden und ggfs. beheben kann.

[country]

OK und der Versuch mit

Code: Alles auswählen

acpi=off

In die cmdline von grub?

[Clemens]

Danke für den Tipp. Nachdem ich acpi=off eingefügt hatte, grub-update durchgeführt und neu gebootet habe, blieb der Bildschirm schwarz.

Wie kann ich das nun wieder rückgängig machen? Komme ich noch über ein Lifesystem vom USB-Stick an die veränderte grub Datei heran?

Mit so etwas habe ich noch keine Erfahrung.

[country]

Wie kann ich das nun wieder rückgängig machen?

ops, sorry, aber um das rückgängig zu machen:
Im Grub gehst du auf deinen Manjaro Eintrag und drückst "e" (Grub Commandline)
dort kannst du mit den courser Tasten zum falschen Eintrag gehen und löschen.
Drück dann die F10 taste um zu booten.
Normal solltest du dann wieder normal auf dein Desktop einloggen. Dort entfernst du dann wieder in /etc/default/grub den falschen parameter. Grub neu generieren, fertig.


besp.

[Clemens]

Schade, Missverständnis!
Wenn ich schrieb "schwarzer Bildschirm", dann meine ich damit, dass vom Manjaro OS nichts geladen wurde, was auch angezeigt wird. Nach dem BIOS wird der Screen halt kurzzeitig schwarz, ehe dann später Manjaro Screen erscheint. Diese Schwärze meine ich.

Und da kann ich nix eingeben und auf Tastatur reagiert der PC dann auch nicht.

Deshalb ja meine Idee, es evtl. mittels Life-System zu versuchen. Oder ich müsste die Systemplatte ausbauen und die GRUB-Datei verändern. Aber das würde vermutlich auch nichts bringen, weil ja anschließend noch update-grub auf dem laufenden OS ausgeführt werden muss, damit die Änderung wirkt.

Erschwerend kommt evtl. hinzu, dass ich BTRFS nutze und jede Änderung, also auch die am GRUB zur Erstellung einer neuen Sicherungsdatei in Timeshift führt. Bei einer früheren Gelegenheit hatte ich das nicht beachtet und mit einer kleinen Änderung das ganze System zerschossen.

Was tun?

[country]

Ja dann hilft es nur mit einer Manjaro - LiveIso zu booten.
in der live-ISO musst du Wurzelverzeichnis chrooten.

in der wikisteht dazu

Code: Alles auswählen

root # pamac install manjaro-tools-base
root # manjaro-chroot -a 

damit hoffe ich das der Befehl automatisch chrootet... das kannst du dann überprüfen indem du eben deine /etc/default/grub mit dem falschen parameter Eintrag siehst..bearbeitest und neu generierst.

[Clemens]

Ich komme da mangels Kenntnissen nicht weiter und scheitere leider bereits daran, wie ich im Life Manjaro im Terminal mit su root-Rechte bekomme.

Daher kann ich auch manjaro-tools-base nicht installieren. Denn dazu müsste ich ja, deiner Anleitung entsprechend, vorher su aktiviert haben.

Und wenn ich das auf dem Life-System hinbekommen habe, dann habe ich die Frage, ob ich damit dann mit root auch auf das defekte System zugreifen kann.

Hier in der Anleitung https://wiki.manjaro.org/index.php?titl ... Bootloader, die du mir verlinkt hattest, finde ich sogar den Hinweis, dass bei einem BTRFS volume (wie bei mir also), die Subvolumes gemounted werden müssen.

Mich überfordert das Vorgehen, weil ich damit nicht vertraut bin und mir anscheinend Grundlagenkenntnisse dazu fehlen. Ich benötige sozusagen eine Schritt-für-Schritt-Anleitung, angefangen mit so primitiven Dingen wie die Sache mit su.
Ohne das komme ich trotz Beachtung der Wiki usw. nicht weiter.

Ich würde mich sehr freuen, wenn du für meine Bitte Verständnis hast und mir diese Schritte detaillierter mitteilen würdest, sodass ich sie auch gehen kann. – Vielen Dank im Voraus!