X2xx/s (X200/s-260) x220 4290WCU / Kubuntu 24.04 friert ein

[TuxTP]

Hallo,


Mein x220 4290WCU mit 16GB RAM mit Kubuntu 24.04 friert in den letzten Wochen immer mal wieder ein. 30 min, 1h funktioniert alles normal und dann passiert es, ohne dass ich noch in eine virtuelle Konsole wechseln kann. Interessanterweise passiert das nicht beim Videoschauen bei maximaler Last, sondern dann, wenn ich das Fenster wechsle.

Betriebssystem: Kubuntu 24.04
KDE-Plasma-Version: 5.27.12
KDE-Frameworks-Version: 5.115.0
Qt-Version: 5.15.13
Kernel-Version: 6.14.0-27-generic (64-bit)
Grafik-Plattform: X11
Prozessoren: 4 × Intel® Core™ i5-2540M CPU @ 2.60GHz
Speicher: 15,5 GiB Arbeitsspeicher
Grafikprozessor: Mesa Intel® HD Graphics 3000
Hersteller: LENOVO
Produktname: 4290WCU
Systemversion: ThinkPad X220

Woran kann das liegen? Lüfter säubern? Mainboard? (Habe noch ein Ersatzboard mit I7, bin aber nicht versessen darauf es zu tauschen.)

Haenge an dem Teil, es ist mein einziger Rechner.

Danke für alle Tips!

 

[linrunner]

Klingt nach RAM-Defekt. Lass einige Stunden (über Nacht) memtest laufen.

Falls dein X220 nicht per UEFI bootet, findest Du memtest86 im GRUB-Menü, ansonsten kannst Du einen USB-Stick erzeugen: https://www.memtest86.com/tech_creating-linux-mac.html

 

[hikaru]

In Ergänzung zu memtest:
Falls du ein persistentes Journal hast*, schau nach dem Reboot nach, ob vor dem Einfrieren noch verwertbare Infos geschrieben wurden!

Haenge an dem Teil, es ist mein einziger Rechner.

Dann betrachte die aktuelle Situation als Warnschuss! Zu einem Backupkonzept gehört es nicht nur Daten zu sichern, sondern auch einen Plan zu haben, wie man an diese Daten herankommt, wenn Hardware ausfällt.


*) Falls nicht, richte es ein!

 

[Mornsgrans]

Einfrieren kann ein Rechner auch bei HDD/SSD Defekten. ---> SMART-Werte auslesen.

 

[TuxTP]

Klingt nach RAM-Defekt. Lass einige Stunden (über Nacht) memtest laufen.

Vielen Dank für all eure Antworten!

Ich mache das mit dem Memtest heute Nacht, anchdem ich es geschafft habe, ins GRUBMenu zu kommen - ich nehme den EIntrag "serial Konsole"

Beitrag automatisch zusammengeführt: 19 Aug. 2025

In Ergänzung zu memtest:
Falls du ein persistentes Journal hast*, schau nach dem Reboot nach, ob vor dem Einfrieren noch verwertbare Infos geschrieben wurden!

Dann betrachte die aktuelle Situation als Warnschuss! Zu einem Backupkonzept gehört es nicht nur Daten zu sichern, sondern auch einen Plan zu haben, wie man an diese Daten herankommt, wenn Hardware ausfällt.

Alles klar, backup habe ich, sowohl die Daten als auch eine SSD mit einem Image. Sowohl Onsite als auch OFFsite
Koenntest Du vielleicht kurz erklären, wie ich das mit dem "persistenten journal" einrichte? Vielen Dank!

 

[Mornsgrans]

Ich mache das mit dem Memtest heute Nacht, anchdem ich es geschafft habe, ins GRUBMenu zu kommen - ich nehme den EIntrag "serial Konsole"

Besser ist es, MEMTEST vom Installationsmedium direkt zu starten, dann steht mehr freier RAM zum testen zur Verfügung.
Auf dem Installationsmedium startet ein Auswahlmenü, oft mit Punkten wie z.B.:
- Live-System starten
- Installation
- Rescue System starten
- MEMTEST
...
Hier "MEMTEST" auswählen.

 

[TuxTP]

@ Mornsgrans: OK versuche ich.

GSmartcontroll ergab:

- Selbstests ok
- der einzige auffällige Wert bei 232 Reserved space :

ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   -O--CK   100   100   ---    -    0
  9 Power_On_Hours          -O--CK   100   100   ---    -    5230
 12 Power_Cycle_Count       -O--CK   100   100   ---    -    3185
165 Total_Write/Erase_Count -O--CK   100   100   ---    -    253476406216
166 Min_W/E_Cycle           -O--CK   100   100   ---    -    3
167 Min_Bad_Block/Die       -O--CK   100   100   ---    -    103
168 Maximum_Erase_Cycle     -O--CK   100   100   ---    -    23
169 Total_Bad_Block         -O--CK   100   100   ---    -    630
170 Unknown_Marvell_Attr    -O--CK   100   100   ---    -    0
171 Program_Fail_Count      -O--CK   100   100   ---    -    0
172 Erase_Fail_Count        -O--CK   100   100   ---    -    0
173 Avg_Write/Erase_Count   -O--CK   100   100   ---    -    10
174 Unexpect_Power_Loss_Ct  -O--CK   100   100   ---    -    494
184 End-to-End_Error        -O--CK   100   100   ---    -    0
187 Reported_Uncorrect      -O--CK   100   100   ---    -    0
188 Command_Timeout         -O--CK   100   100   ---    -    0
194 Temperature_Celsius     -O---K   062   056   ---    -    38 (Min/Max 14/56)
199 SATA_CRC_Error          -O--CK   100   100   ---    -    0
230 Perc_Write/Erase_Count  -O--CK   001   001   ---    -    349 256 349
232 Perc_Avail_Resrvd_Space PO--CK   100   100   004    -    100
233 Total_NAND_Writes_GiB   -O--CK   100   100   ---    -    10730
234 Perc_Write/Erase_Ct_BC  -O--CK   100   100   ---    -    14380
241 Total_Writes_GiB        ----CK   253   253   ---    -    12020
242 Total_Reads_GiB         ----CK   253   253   ---    -    30070
244 Thermal_Throttle        -O--CK   000   100   ---    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

Ist das die Ursache?

 

[linrunner]

Nein. Die Werte sind allesamt OK.

 

[Mornsgrans]

Sehe ich auch so.

Aber "spiele" mal mit der hervorgehobenen Einstellung im BIOS unter Config Power, wenn er existiert:

 

[ubu]

Alles klar, backup habe ich, sowohl die Daten als auch eine SSD mit einem Image. Sowohl Onsite als auch OFFsite
Koenntest Du vielleicht kurz erklären, wie ich das mit dem "persistenten journal" einrichte? Vielen Dank!

mkdir /var/log/jounal, dann reboot

sudo journalctl -b zeigt dir die Einträge seit dem booten,
sudo journalctl -b -1 die vom letzten Boot, runterscrollen (oder Shift-G, springt zum Ende)
zeigt dir die Einträge vor dem Crash.

 

[TuxTP]

Besser ist es, MEMTEST vom Installationsmedium direkt zu starten,

Auf meinem Installationsmedium gabs Memtest nicht. Habe also so Memtest 18h laufen lassen - keine Fehler.

Habe auch ein permanentes Journal angelegt.

Beitrag automatisch zusammengeführt: 20 Aug. 2025

Ich habe jetzt auch mal Compositing deaktiviert, vielleicht ist es ja doch ein Softwareproblem (uralte Grafik und neuer Kernel 6.14 ...)

Beitrag automatisch zusammengeführt: 21 Aug. 2025

Mit abgeschaltetem Composisting gings besser, ist aber doch nochmal passiert.

Das mit dem journal hat nicht geklappt:

sudo journalctl -b -1

[sudo] Passwort für user: 
Specifying boot ID or boot offset has no effect, no persistent journal was found.

Weiter Ideen?

 

[ubu]

Gefühlt haben die alten Intel Chips Probleme mit den Anforderungen moderner Guide und produzieren hängende Systeme bei z.B. Wechsel zu oder aus Fullscreen.

Ist ausdrücklich nur gefühlt, Haiku hat auf den gleichen Rechnern, x201, T430s, x230 keine Hänger, Ubuntu schon

 

[Ambrosius]

Ich bin da Ubu's Meinung. Hatte mit nem x220 vor etlichen Jahren auch Probleme mit wie von dir beschriebenen Hängern und hatte auch die Grafik als Übeltäter verdächtigt. Hatte aber keine tiefergehende Diagnose verfolgt und stattdessen direkt zum Nachfoger geupgradet.

Nichts desto trotz

Prozessoren: 4 × Intel® Core™ i5-2540M CPU @ 2.60GHz
Grafikprozessor: Mesa Intel® HD Graphics 3000

Laut dieser Tabelle von NBC taktet die HD Graphics 3000 zwischen 650 und 1100 bzw 1300 Mhz.
Ist also fraglich ob dein i7 Board eine Veränderung brigen würde, obwohl ich es nicht ausschließen mag

Wichtig wäre zu ermitteln ob deine GPU ordentlich hochtaktet. Ich würde vorschlagen intel_gpu_top zu installieren und mal paar Tests auszuprobieren (glmark2, den Aquarium Test im Browser) schau dabei wie hoch die Auslastung ist und wie hoch er nach oben taktet.

Außerdem, wenn es noch nicht erwähnt wurde, wieviel Watt hat dein Netzteil?

 

[TuxTP]

Wichtig wäre zu ermitteln ob deine GPU ordentlich hochtaktet. Ich würde vorschlagen intel_gpu_top zu installieren und mal paar Tests auszuprobieren (glmark2, den Aquarium Test im Browser) schau dabei wie hoch die Auslastung ist und wie hoch er nach oben taktet.

Außerdem, wenn es noch nicht erwähnt wurde, wieviel Watt hat dein Netzteil?

Hallo

intel_gpu_top als Paket habe ich nicht gefunden. Netzteil 65W. Hatte bis jetzt nicht den Eindruck, dass es daran liegt - waere dann wohl ein Grund, in den Bios Energieeinstellungen zu tunen (vgl. Mornsgrans). Bis jetzt geht es aber nach Abschalten des Eye-candy ganz gut. Werde mal weiter beobachten und dann ev. den Thread auf gelöst setzten. Hab jetzt auch mal die SSD getauscht - obwohl die andere lt. smart aj ok war.
Danke für euren Input!

 

[Ambrosius]

Ist aber auf jeden Fall im Debian Repo, versuch sonst mal mit Bindestrichen

90W NT wäre auch zu empfehlen

 

[Ravensberger]

Weiter Ideen?

Schau einmal, ob der Dienst überhaupt läuf. Das geht auch ohne sudo, genau wie der Blick ins Journal.

~$ systemctl status systemd-journald

Dann schau in der /etc/systemd/journald.conf nach. 'Eigentlich' sollte der Dienst auch laufen, wenn hier nichts gesondert festgelegt ist.
Setze einmal

Storage=persistent

und starte den Dienst durch.

sudo systemctl restart systemd-journald

P.S.: Wegen zu geringer Prozessortaktrate ist noch nie ein System eingefroren.

 

[TuxTP]

Schau einmal, ob der Dienst überhaupt läuf. Das geht auch ohne sudo, genau wie der Blick ins Journal.

~$ systemctl status systemd-journald

Dann schau in der /etc/systemd/journald.conf nach. 'Eigentlich' sollte der Dienst auch laufen, wenn hier nichts gesondert festgelegt ist.
Setze einmal

Storage=persistent

und starte den Dienst durch.

sudo systemctl restart systemd-journald

P.S.: Wegen zu geringer Prozessortaktrate ist noch nie ein System eingefroren.

Hm, sollte laufen:

systemctl status systemd-journald
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
    Drop-In: /usr/lib/systemd/system/systemd-journald.service.d
             └─nice.conf
     Active: active (running) since Sat 2025-08-23 10:34:57 CEST; 11h ago
TriggeredBy: ○ systemd-journald-audit.socket
             ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 504 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18883)
   FD Store: 92 (limit: 4224)
     Memory: 11.4M (peak: 11.9M)
        CPU: 1.980s
     CGroup: /system.slice/systemd-journald.service
             └─504 /usr/lib/systemd/systemd-journald

Aug 23 10:34:57 x220 systemd-journald[504]: Collecting audit messages is disabled.
Aug 23 10:34:57 x220 systemd-journald[504]: Journal started
Aug 23 10:34:57 x220 systemd-journald[504]: Runtime Journal (/run/log/journal/0b033636cd9a4e25924f24cc890cd656) is 8.0M, max 158.7M, 150.7M free.
Aug 23 10:34:57 x220 systemd-journald[504]: Runtime Journal (/run/log/journal/0b033636cd9a4e25924f24cc890cd656) is 8.0M, max 158.7M, 150.7M free.
Aug 23 10:34:57 x220 systemd-journald[504]: Received client request to flush runtime journal.
Notice: journal has been rotated since unit was started, output may be incomplete.

In der .conf steht noch "storage=auto" ... es läuft momentan super, werde es ausprobieren, wenn es wieder haengt.

Ich vermute, dass Hauptproblem war das "eyecandy"

 

[TuxTP]

Hallo


Greife das Thema nochmal auf.
Das Einfrieren ist seltener ohne Eyecandy, aber doch noch mal passiert. Das Log habe ich jetzt auf Permanent gesetzt. glmark2 habe ich auch laufen lassen, kann aber intel-gpu-top nicht interprestieren, beiligend das Photo

Beitrag automatisch zusammengeführt: 27 Aug. 2025

Laut dieser Tabelle von NBC taktet die HD Graphics 3000 zwischen 650 und 1100 bzw 1300 Mhz.
Ist also fraglich ob dein i7 Board eine Veränderung brigen würde, obwohl ich es nicht ausschließen mag

Mir schien mit dem von Dir vorgeschlagenen Test dass es bis zu 1300 raufgeht

Beitrag automatisch zusammengeführt: 27 Aug. 2025

mkdir /var/log/jounal, dann reboot

sudo journalctl -b zeigt dir die Einträge seit dem booten,
sudo journalctl -b -1 die vom letzten Boot, runterscrollen (oder Shift-G, springt zum Ende)
zeigt dir die Einträge vor dem Crash.

sudo journalctl -b -1
[sudo] Passwort für user:
No journal boot entry found from the specified boot offset (-1).

sudo journalctl -b zeigt ein langes Journal, aber das ist wohl nicht so interessant.

 

[Ambrosius]

Mir schien mit dem von Dir vorgeschlagenen Test dass es bis zu 1300 raufgeht

Ja das tut es. Sieht man auch gut in deinem Screenshot oben rechts.
Dann ist zumindest deine GPU gut versorgt.

sudo journalctl -b zeigt ein langes Journal, aber das ist wohl nicht so interessant.

Mitnichten.

mkdir /var/log/jounal, dann reboot

sudo journalctl -b zeigt dir die Einträge seit dem booten,
sudo journalctl -b -1 die vom letzten Boot, runterscrollen (oder Shift-G, springt zum Ende)
zeigt dir die Einträge vor dem Crash.

So wie ich ubus Vorschlag verstanden hat, sollst du dass Journal unmittelbar nach dem graphischen Schluckauf konsultieren. So kannst du den letzten Eintrag auch direkt verorten und zuordnen können.

 

[TuxTP]

So wie ich ubus Vorschlag verstanden hat, sollst du dass Journal unmittelbar nach dem graphischen Schluckauf konsultieren. So kannst du den letzten Eintrag auch direkt verorten und zuordnen können.

OK aber ich dachte journalctl -b bezieht sich auf die AktuelleSitzung - da ist ja nix passiert