Rechner friert ein

[akjac]

Hallo,

mein Sohn interessiert sich nicht sonderlich für Linux... Hauptsache Minecraft läuft

Mit Debian 10 funzte der Minecraft-Launcher problemlos.
Seit Bullseye und Java-Minecraft 1.18.1 bleibt der Rechner in Minecraft nach einiger Zeit unvermittelt stehen und macht überhaupt keinen Mucks mehr. Da hilft nur der Kaltstart

Das ist mein System:

Code: Alles auswählen

 
root@tux:/var/log# inxi -b
System:    Host: tux Kernel: 5.10.0-10-amd64 x86_64 bits: 64 Console: tty 0 Distro: Debian GNU/Linux 11 (bullseye)
Machine:   Type: Desktop Mobo: ASRock model: H110M-STX/COM serial: 151685930000050 UEFI [Legacy]: American Megatrends v: P1.30
           date: 08/24/2016
CPU:       Info: Dual Core Intel Core i3-7100 [MT MCP] speed: 800 MHz min/max: 800/3900 MHz
Graphics:  Device-1: Intel HD Graphics 630 driver: i915 v: kernel
           Display: server: X.org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa tty: 189x44
           Message: Advanced graphics data unavailable in console for root.
Network:   Device-1: Intel Ethernet I219-V driver: e1000e
           Device-2: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
Drives:    Local Storage: total: 223.57 GiB used: 11.64 GiB (5.2%)
Info:      Processes: 174 Uptime: 1h 40m Memory: 7.48 GiB used: 1.53 GiB (20.5%) Init: systemd runlevel: 5 Shell: Bash
           inxi: 3.3.01

Installiert hatte ich wie immer...

1. Standard-Installation über Live-CD (d-live nf 11.2.0 xf amd64)
2. Installation von openjdk jre 17.0.1 aus Debian Repository

Meine source.list

Code: Alles auswählen

deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb http://deb.debian.org/debian bullseye-backports main contrib non-free

In /sys/var/log/messages finde ich nichts greifbares außer

Code: Alles auswählen

Dec 29 19:34:38 tux kernel: [  549.617933] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Dec 29 19:34:38 tux kernel: [  549.617950] i915 0000:00:02.0: [drm] Render thread[2309] context reset due to GPU hang
Dec 29 19:34:38 tux kernel: [  549.651375] i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85df7efb, in Render thread [2309]
das ist wohl der ABEND... es folgen an dieser Stelle viele ^@
Dec 29 19:42:47 tux rsyslogd: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.2102.0]
Dec 29 19:42:47 tux rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="540" x-info="https://www.rsyslog.com"] start
Dec 29 19:42:47 tux kernel: [    0.000000] microcode: microcode updated early to revision 0xea, date = 2021-01-05
Dec 29 19:42:47 tux kernel: [    0.000000] Linux version 5.10.0-10-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08)
Dec 29 19:42:47 tux kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-10-amd64 root=UUID=a2560a3f-5ccc-4532-8266-64cacd728c4f ro quiet

Hat der Abbruch etwas mit drm und der Grafikkarte zu tun oder werde ich hier vom Logfile hinters Licht geführt ?
Stöbern in Synaptic nach drm bringt auch libdrmaa1.0-java. Muss das eventuell ebenfalls installiert werden ?

Grüße

[debilian]

In so einem Fall versuche ich immer mich von einem anderen Rechner per ssh anzumelden und schaue dann, welcher Prozess rumspinnt...

gruss

[Huck Fin]

Wird die GPU eventuell zu heiß ?

[kalle123]

Was sagt denn 'journalctl'?

KH

[MSfree]

Wird die GPU eventuell zu heiß ?

Ich lese aus dem ersten Post:

Code: Alles auswählen

CPU:       Info: Dual Core Intel Core i3-7100 [MT MCP] speed: 800 MHz min/max: 800/3900 MHz
Graphics:  Device-1: Intel HD Graphics 630 driver: i915 v: kernel

Das ist also die integrierte GPU in dem i3-7100. Schonmal erlebt, daß sowas zu heiß wird?

OK, wenn der Kühlkörper auf der CPU nicht richtig sitzt, kann es schonmal zum thermal Throtteling kommen, aber ansonsten ist das kein Hitzkopf

[OrangeJuice]

Vielleicht liegt es nicht am PC.
Es gab die log4j Schwachstelle, welche eventuell auch in Bezug auf Minecraft relevt ist oder war.

log4j-Schwachstelle CVE-2021-44228: Minecraft dringend patchen
Exploitation continues on non-Microsoft hosted Minecraft servers

[akjac]

Hi,
wir haben jetzt folgendes gemacht:
Papa (also ich) habe mich mit ssh auf den Rechner meines Sohns aufgeschaltet.

Eingeloggt als root. Mangels besser Ideen einfach mal top aufgerufen zum Beobachten des Rechners. Dann Sohn zum Minecraft-Spielen zitiert
Nach 5 Minuten gab es einen exit-code 0 (unbekannter Fehler bei Minecraft, es tut den Minecraft-Entwicklern leid, schreiben die in der Fehlermeldung). Aber leider keine Details in den Logs. Minecraft wieder neu gestartet und weiter ging es. Hoffe, dass diese Info der Vollständigkeit halber niemanden auf die falsche Fährte führt, denn gestern war der exit.-code 0 nicht aufgetaucht, sondern der Freeze war zuerest da. Java und Minecraft ist alles auf dem neuesten Stand. Der Rechner ist frisch aufgesetzt und hat auch keine Besonderheiten.

Nach weiteren zehn Minuten in Minecraft ein Freeze des Rechners.
Top rührt sich nach dem Einfrieren auch nicht mehr, auch das ssh-Terminal steht still. Der Connect zum Host geht nach einigen Minuten flöten und läßt sich auch nicht mehr herstellen. Kann man daraus schliessen, dass der Rechner stillsteht ?
Ein Hitzeproblem würde ich vorsichtig auschließen, der Rechner ist relativ kühl und der Lüfter läuft. Staub und Fusel habe ich ebenfalls aus dem Gehäuse rausgesaugt, da war aber nicht viel drin (da habe ich schon schlimmeres gesehen).

Im Moment des Einfrierens war das die Angabe von top.

Code: Alles auswählen

root@tux:~# top

top - 17:12:25 up 21 min,  2 users,  load average: 4,80, 3,09, 1,75
Tasks: 179 total,   1 running, 178 sleeping,   0 stopped,   0 zombie
%CPU(s): 26,0 us,  1,6 sy,  0,0 ni, 72,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7660,1 total,   2563,2 free,   3440,9 used,   1656,0 buff/cache
MiB Swap:    976,0 total,    976,0 free,      0,0 used.   3666,2 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL                                                      
   2411 alex      20   0 7100336   2,8g  76800 S  90,3  37,5   8:59.83 java                                                        
   2494 root      20   0   10220   3704   3192 R   6,5   0,0   0:00.49 top                                                         
   1215 alex       9 -11  822960  29860  21268 S   3,2   0,4   0:23.04 pulseaudio                                                  
      1 root      20   0   98648  10672   7788 S   0,0   0,1   0:01.48 systemd                                                     
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kthreadd                                                    
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp                                                      
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp                                                  
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kworker/0:0H-events_highpri                                 
      7 root      20   0       0      0      0 I   0,0   0,0   0:00.28 kworker/0:1-events                                          
      8 root      20   0       0      0      0 I   0,0   0,0   0:00.27 kworker/u8:0-events_unbound                                 
      9 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq                                                
     10 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_rude_                                             
     11 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_trace                                             
     12 root      20   0       0      0      0 S   0,0   0,0   0:00.03 ksoftirqd/0                                                 
     13 root      20   0       0      0      0 I   0,0   0,0   0:00.87 rcu_sched                                                   
     14 root      rt   0       0      0      0 S   0,0   0,0   0:00.00 migration/0                                                 
     15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0                                                     

[akjac]

Was sagt denn 'journalctl'?

KH

welcher Parameter bei journalctl wäre hier sinnvoll ?
Da steht ziemlich viel Zeug drin, kann man das sinnvoll in eine Datei filtern und über ssh auf meinen Papa-Rechner übertragen ?

[kalle123]

welcher Parameter bei journalctl wäre hier sinnvoll ?

Schau mal hier rein. Da findet sich eine grobe Übersicht

https://wiki.ubuntuusers.de/systemd/journalctl/

Außerdem sollte das journal persistent sein, also wenn der Rechner abgeschmiert ist, neu starten und mal ins journal rein schauen ....

KH

[MSfree]

welcher Parameter bei journalctl wäre hier sinnvoll ?

Ich glaube nicht, daß in diesem Fall die Logs irgendwie weiterführen. Das Problem mit Aufhängern ist, daß sich die Kiste halt aufhängt und ein hängender Rechner die Ursache des Hängers nicht mehr protokollieren kann.

Was man machen kann ist:

Code: Alles auswählen

journalctl -f

über ein Terminal per SSH zu starten und dann den Junior zum Spielen aufzufordern. Die Meldungen laufen dann permanent durch das Terminal und im Falle eines Hängers hättest du den Text der letzten paar Meldungen noch im Terminal und der kann von dort kopiert und ins Forum gepostet werden. Ich befürchte aber, daß da keine hilfreiche Meldung mehr kommt.

Ähnlich kann man mit

Code: Alles auswählen

dmesg -w

verfahren. Entweder, indem man noch eine zweiten Versuch mit einem SSH Terminal macht, oder indem man zwei Terminals öffnet und in einem journactl und in dem zweiten dmesg mitlaufen läßt.

Die Ursache fürs Aufhängen zu finden, ist meist schwierig. Oft sind Hardwaredefekte schuld, ganz oben auf meiner Liste steht defektes RAM, das man mal mit einem Memory Checker testen kann.

[akjac]

welcher Parameter bei journalctl wäre hier sinnvoll ?

Schau mal hier rein. Da findet sich eine grobe Übersicht

https://wiki.ubuntuusers.de/systemd/journalctl/

Außerdem sollte das journal persistent sein, also wenn der Rechner abgeschmiert ist, neu starten und mal ins journal rein schauen ....

KH

also ich denke, dass das Log persistent ist, obwohl ich hier bei der Installation nichts geändert habe.
Bei -1 ist der Abbruch.

Code: Alles auswählen

root@tux:~# journalctl --list-boots
-11 4c8732c889f44759920db9c2b93665eb Tue 2021-12-28 22:09:46 CET—Tue 2021-12-28 22:42:16 CET
-10 e4f97486e6a74592839acd939949784b Tue 2021-12-28 22:46:26 CET—Tue 2021-12-28 23:06:40 CET
 -9 c75e2573e7954ae7b6d40b1b9d3cb4a5 Wed 2021-12-29 17:02:53 CET—Wed 2021-12-29 17:10:06 CET
 -8 8defcb4ed2ca4ecaa830ed99530bc4ac Wed 2021-12-29 18:01:15 CET—Wed 2021-12-29 18:13:28 CET
 -7 f7439f35cede4836a28cd1334e27efe7 Wed 2021-12-29 18:40:25 CET—Wed 2021-12-29 19:25:12 CET
 -6 a98a88991d7e45aa9feb5c8dfdbee0ab Wed 2021-12-29 19:25:33 CET—Wed 2021-12-29 19:39:59 CET
 -5 4c434e747a03470e825c53b77fc751a7 Wed 2021-12-29 19:42:46 CET—Wed 2021-12-29 20:11:33 CET
 -4 c9c1ee3fae504ca09207e47df5fca365 Thu 2021-12-30 18:09:15 CET—Thu 2021-12-30 19:55:01 CET
 -3 7c05c15f5cfc4d529dc13b97213eb719 Thu 2021-12-30 19:59:34 CET—Thu 2021-12-30 23:57:09 CET
 -2 78be95e92f2947c1a4df54223109a0bd Fri 2021-12-31 20:58:35 CET—Sat 2022-01-01 00:41:21 CET
 -1 95f8a32329cb43fc94db489c0ea1d936 Sat 2022-01-01 16:51:20 CET—Sat 2022-01-01 17:12:11 CET
  0 bc720e21b75f4ff1aa218f0687964ef4 Sat 2022-01-01 17:48:53 CET—Sat 2022-01-01 18:31:34 CET

In der -1 die letzten Zeilen sind folgende:

Code: Alles auswählen

-- Journal begins at Tue 2021-12-28 22:09:46 CET, ends at Sat 2022-01-01 18:16:17 CET. --
[.. many lines deleted, to keep moderator happy...]

Jan 01 17:10:07 tux systemd[1]: Starting system activity accounting tool...
Jan 01 17:10:07 tux systemd[1]: sysstat-collect.service: Succeeded.
Jan 01 17:10:07 tux systemd[1]: Finished system activity accounting tool.
Jan 01 17:12:11 tux kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Jan 01 17:12:11 tux kernel: i915 0000:00:02.0: [drm] Render thread[2413] context reset due to GPU hang
Jan 01 17:12:11 tux kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:84df7efc, in Render thread [2413]

[akjac]

Die Ursache fürs Aufhängen zu finden, ist meist schwierig. Oft sind Hardwaredefekte schuld, ganz oben auf meiner Liste steht defektes RAM, das man mal mit einem Memory Checker testen kann.

dann würde ich erstmal den Speicher durchtesten, bevor ich hier meine letzten Haare verliere
Was wird hier zum Speichercheck empfohlen ? mem86 oder so ?

[kalle123]

Code: Alles auswählen

GPU HANG: ecode 9:1:84df7efc

schaut doch interessant aus ....

KH

[akjac]

Code: Alles auswählen

GPU HANG: ecode 9:1:84df7efc

schaut doch interessant aus ....

KH

stimmt, das ist zumindest besser als nix. Aber sieht man hier eine Lösung ?
https://gitlab.freedesktop.org/drm/intel/-/issues/2865

[MSfree]

Code: Alles auswählen

GPU HANG: ecode 9:1:84df7efc

Stimmt, und nur, um die einfachen Fehlerquellen aus dem Weg zu schaffen:

Ist firmware-misc-nonfree installiert?
Ist intel-microcode installiert?

[kalle123]

stimmt, das ist zumindest besser als nix. Aber sieht man hier eine Lösung ?
https://gitlab.freedesktop.org/drm/intel/-/issues/2865

Was soll den so ein einzelner github Beitrag?

https://www.google.com/search?q=gpu+han ... nt=gws-wiz

liefert 'ungefähr 3.590! Ergebnisse'

KH

[akjac]

Code: Alles auswählen

GPU HANG: ecode 9:1:84df7efc

Stimmt, und nur, um die einfachen Fehlerquellen aus dem Weg zu schaffen:

Ist firmware-misc-nonfree installiert?
Ist intel-microcode installiert?

nachgeguckt:

• firmware-misc-nonfree installiert
• amd64-microcode und intel-microcode installiert

[akjac]

liefert 'ungefähr 3.590! Ergebnisse'
[/quote]

viele Ergebnisse... aber siehst Du hier einen klaren Lösungsweg ?

[kalle123]

viele Ergebnisse... aber siehst Du hier einen klaren Lösungsweg ?

'klaren Lösungsweg' Der war gut!

Soll ich mich da jetzt durch wühlen?

Ich hab eine PC Komponente bei dem Händler meines Vertrauens gekauft. Kriege nach einer gewissen Zeit (noch in Garantie) so eine Meldung hier und die Kiste stürzt regelmäßig ab, dann kriegt er die entsprechende Meldung als Reklamation auf den Tisch. Hatte ich vor nicht allzu langer Zeit mit einer SSD und dann mit einer GeForce GT 1030.

Bin ich raus aus der Garantie, hab ich das Problem am Bein. Dann fängt das Hardware Spiel an. Welche Komponenten sind unverdächtig, welche kann ich testen (Netzteil, Platten, Speicher). In dem Fall bleiben Prozessor und Mobo übrig. Alles auseinander nehmen, neu zusammenbauen soll schon wahre Wunder gewirkt haben.

Wenn es das nicht ist, geht das Jongliere los. Nur einen Ersatzprozessor oder doch besser eine Prozessor Mobo Kombi und passen da die Speicher ..... usw.

Ist alles nicht so easy und sicher nicht jedermanns Sache.

Drück die Daumen!

KH

PS. Meine persönliche Meinung, nachdem, was ich hier so lese über das Problem. Kann da richtig, aber auch total falsch liegen. Hab die Kiste nicht vor mir.
Hinzu kommt, wie hoch ist der momentane Wert diese PCs? Was kosten Fehlersuche und Komponententausch durch eine Fach! Werkstatt, wenn man das nicht selber machen kann oder will?

Drum fliegt viel (nicht nur PCs) auf den Elektronikschrott, was da eigentlich nicht hin gehört ....

[akjac]

viele Ergebnisse... aber siehst Du hier einen klaren Lösungsweg ?

'klaren Lösungsweg' Der war gut!

Soll ich mich da jetzt durch wühlen?

nein, wie kommst Du auf so einen Quatsch ?
Mein Gedanke war eigentlich folgender: beim groben Drübergucken kamen diffuse und obskure Probleme aus unterschiedlichen Jahren zutage. Irgendwelche generellen Lösung nach dem Motto "mach das, dann ist alles gut" konnte ich so spontan nicht erkennen. Allerlei Lösungsansätze wie Kernel aus Testing, Nomodeset usw tauchten zwar in diesem Zusammenhang auf, scheinen aber nicht unbedingt bei jeder Problemlage das Allheilmittel zu sein.

Ein Kontaktproblem beim Speicher, ein kaputter Speicher o.ä. wäre ja denkbar, denn das Minecraft scheint ja wohl gigabyteweise Speicher zu schaufeln... vielleicht ja mehr, als vor dem Update jemals bewegt wurde.

Hardware... ich kann mich noch lebhaft daran erinnern, dass ich mal vor etwa zehn Jahren bei meinen damaligen Motherboards zwei WIFI-Karten eingebaut habe, hierbei nur das Netztteil ausgeschaltet habe, aber ohne den Netzstecker zu ziehen... die gerechte Strafe hierfür waren zwei neue Motherboards, weil die Rechner zwar noch irgendwie liefen, aber im täglichen Betrieb mitunter blitzartig einen Kaltstart hingelegt haben, weil beim Einbau die Motherboard wohl einen Spannungsüberschlag gekriegt hat. Zugriff auf kaputte Motherboard-Ressource ergibt nunmal Peng.

Was die Kosten/Nutzen/Aufwand angeht: meinen Sohnemann habe ich vorläufig mit einem alternativen Rechner beglückt und mein regulärer Client-Arbeitsrechner ist sowieso ein ganz anderer.

Der Problem-Rechner ist ein Asus Deskmini... ein schnuckeliger ASROCK H110M-STX-COM mit 8 Gigabyte und einer SSD-Platte. Wenn es mit einem neuen Speicherriegel getan ist, wäre das auch kein Beinbruch. Einen ersten Speichertest habe ich mit Memtest86+ probiert... außer einem scheinbaren Stillstand nach Beginn des Prüfvorgangs habe ich hier erstmal nichts geerntet. Zumindest ging die Fortschrittsanzeige nach den ersten Prüfschritten nicht mehr weiter... ich probiere es nochmal und lasse den Rechner mal ein paar Stunden alleine werkeln... vielleicht tut er doch noch etwas

[kalle123]

Hi, als Garantie geht das wohl nicht mehr, Restwert 'überschaubar'.
Dann lohnt es kaum, das Sorgenkind in (ev. teure) kundige Hände zu geben.

Oder du machst Fehlersuche an PCs zum Hobby. Und ich schreibe bewusst Hobby, man muss da schon etwas Spass dran haben

Gruß KH

[reox]

Einen ersten Speichertest habe ich mit Memtest86+ probiert... außer einem scheinbaren Stillstand nach Beginn des Prüfvorgangs habe ich hier erstmal nichts geerntet. Zumindest ging die Fortschrittsanzeige nach den ersten Prüfschritten nicht mehr weiter... ich probiere es nochmal und lasse den Rechner mal ein paar Stunden alleine werkeln...

Das memtest komplett hängt hatte ich bisher einmal - Ich kann mich leider nicht mehr erinnern was das Problem war, aber ich habe ziemlich sicher danach CPU und RAM getauscht - wenn nicht sogar das Board dran glauben musste...
Hängt memtest denn wirklich so richtig? Es gibt da ja eine Anzeige das es noch rennt und die sollte schon immer weiterspringen. Hast du es im multithread oder singlethread modus gestartet? Ggf einmal im Singlethread laufen lassen.

[Huck Fin]

Ich sehe da auch einen Hardware Defekt.
Wenn der PC so richtig hängt, ist meist der RAM oder die CPU dran schuld.
Wenn der sich schon beim Memtest aufhängt, dann hier mal suchen.

Wenn 2 Ram-Riegel im PC sind, mal einzeln testen mit Memtest.
Oder mal andere RAM testen.

[akjac]

Einen ersten Speichertest habe ich mit Memtest86+ probiert... außer einem scheinbaren Stillstand nach Beginn des Prüfvorgangs habe ich hier erstmal nichts geerntet. Zumindest ging die Fortschrittsanzeige nach den ersten Prüfschritten nicht mehr weiter... ich probiere es nochmal und lasse den Rechner mal ein paar Stunden alleine werkeln...

Das memtest komplett hängt hatte ich bisher einmal - Ich kann mich leider nicht mehr erinnern was das Problem war, aber ich habe ziemlich sicher danach CPU und RAM getauscht - wenn nicht sogar das Board dran glauben musste...
Hängt memtest denn wirklich so richtig? Es gibt da ja eine Anzeige das es noch rennt und die sollte schon immer weiterspringen. Hast du es im multithread oder singlethread modus gestartet? Ggf einmal im Singlethread laufen lassen.

das memtest86 habe ich auf dem Problemrechner und auf meinem Arbeitsrechner laufen lassen... beide legen nach dem Start einen Stillstand hin. Die Bildschirme von 10 Sekunden nach dem Start sind identisch mit den Bildern nach über 8h in der Nacht. Nein, verstehe ich nicht und ich denke, ich mache hier irgendwas grundlegendes falsch.
Installiert habe ich das memtest 4.3.7 mit synaptic aus dem Debian-Repository, gestartet habe ich es dann jeweils mit dem grub.

[reox]

Kannst du noch ins Menü (c drücken)? Versuch mal SMP abzuschalten, falls es aufgedreht ist.

edit: ups ich wusst gar nimmer wie das geht... SMP macht man mit F2... Das hast du vermutlich eh nicht gedrückt?
Versuch mal direkt nach dem starten in den Failsafe Modus zu gehen (F1)

Wenn unter State der Spinner nichts tut (bzw das rote + im titel nicht blinkt), dann hat sich memtest wirklich aufgehängt, was bei manchen CPUs auftreten kann. ggf hilft es auch unter c -> (4) core selection -> zB auf Sequential (3) zu wechseln.