gelöst: HP350G2 friert mit Buster manchmal komplett ein

[peter1969]

Hallo, mein Notebook HP350G2 friert gelegentlich mit Buster komplett ein. Das scheint mit keiner bestimmten Anwendung verbunden zu sein. Wenn es passiert, reagiert das Notebook auf keine Tastatureingabe mehr und muss per AN/AUS-Schalter neu gestartet werden. Mit Stretch gab es das Problem noch nicht. Hat jemand ein ähnliches Problem oder gar schon die Lösung?

[willy4711]

Bitte mal inxi installieren und die Ausgabe von

Code: Alles auswählen

inxi -F

hier einstellen.
Dann brauchen wir auch keine Glaskugeln mehr.
Hilfreich wäre auch die Ausgabe von Journal von den letzten "Zuckungen" des Systems.

[peter1969]

Hallo willy4711, ich musste noch das permanente journal einrichten und auf den nächsten Absturz warten. Hier die letzten Daten vor dem Einfrieren (im Browser lief übrigens gerade ein Video, und dessen letzte paar Tonfetzen liefen im eingefrorenenen Rechner immer wieder ab, wie eine Schallplatte mit Kratzer):

Code: Alles auswählen

Apr 29 22:06:31 HP350G2 kernel: perf: interrupt took too long (3997 > 3956), lowering kernel.perf_event_max_sample_rate to 50000
Apr 29 22:07:25 HP350G2 pkexec[3610]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:07:25 HP350G2 pkexec[3610]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:07:32 HP350G2 pkexec[3614]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:07:32 HP350G2 pkexec[3614]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:09:32 HP350G2 pkexec[3623]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:09:32 HP350G2 pkexec[3623]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:09:35 HP350G2 pkexec[3627]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:09:35 HP350G2 pkexec[3627]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:17:01 HP350G2 CRON[3656]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 29 22:17:01 HP350G2 CRON[3657]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr 29 22:17:01 HP350G2 CRON[3656]: pam_unix(cron:session): session closed for user root
Apr 29 22:17:29 HP350G2 pkexec[3660]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:17:29 HP350G2 pkexec[3660]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:17:31 HP350G2 pkexec[3664]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:17:31 HP350G2 pkexec[3664]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:20:56 HP350G2 pkexec[3677]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:20:56 HP350G2 pkexec[3677]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh
Apr 29 22:21:00 HP350G2 pkexec[3681]: pam_unix(polkit-1:session): session opened for user root by (uid=1001)
Apr 29 22:21:00 HP350G2 pkexec[3681]: barem: Executing command [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backligh

Hier die Ausgabe von inxi -F:

Code: Alles auswählen

System:
  Host: HP350G2 Kernel: 4.19.0-4-amd64 x86_64 bits: 64 Desktop: Xfce 4.12.4 
  Distro: Debian GNU/Linux buster/sid 
Machine:
  Type: Laptop System: Hewlett-Packard product: HP 350 G2 
  v: 098F200000000010000600087 serial: 5CG52711HY 
  Mobo: Hewlett-Packard model: 803A v: KBC Version 46.11 
  serial: PEYRL00WB8V01F UEFI: Insyde v: F.13 date: 06/10/2015 
Battery:
  ID-1: BAT0 charge: 13.8 Wh condition: 33.6/33.6 Wh (100%) 
CPU:
  Topology: Dual Core model: Intel Pentium 3805U bits: 64 type: MCP 
  L2 cache: 2048 KiB 
  Speed: 798 MHz min/max: 500/1900 MHz Core speeds (MHz): 1: 798 2: 798 
Graphics:
  Device-1: Intel HD Graphics driver: i915 v: kernel 
  Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel Broadwell GT1 v: 4.5 Mesa 18.3.4 
Audio:
  Device-1: Intel Broadwell-U Audio driver: snd_hda_intel 
  Device-2: Intel Wildcat Point-LP High Definition Audio 
  driver: snd_hda_intel 
  Sound Server: ALSA v: k4.19.0-4-amd64 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8169 
  IF: enp1s0 state: down mac: 30:8d:99:c2:60:c1 
  Device-2: Realtek RTL8723BE PCIe Wireless Network Adapter 
  driver: rtl8723be 
  IF: wlp2s0 state: up mac: 70:77:81:8e:97:b7 
Drives:
  Local Storage: total: 465.76 GiB used: 41.81 GiB (9.0%) 
  ID-1: /dev/sda vendor: HGST (Hitachi) model: HTS545050A7E680 
  size: 465.76 GiB 
Partition:
  ID-1: / size: 27.38 GiB used: 4.93 GiB (18.0%) fs: ext4 dev: /dev/sda2 
  ID-2: /home size: 425.62 GiB used: 36.87 GiB (8.7%) fs: ext4 
  dev: /dev/sda4 
  ID-3: swap-1 size: 3.90 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3 
Sensors:
  System Temperatures: cpu: 38.0 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 139 Uptime: 28m Memory: 3.76 GiB used: 831.9 MiB (21.6%) 
  Shell: bash inxi: 3.0.32

[peter1969]

eins ist mir noch aufgefallen: mein System brauchte von Installation an für viele Befehle ein /sbin/ davor, weil dieses offenbar nicht im Path war:

Code: Alles auswählen

root@HP350G2:/home/peter# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Das hab ich gerade noch mit einem beherzten

Code: Alles auswählen

export PATH=$PATH:usr/local/sbin:/usr/sbin:/sbin

repariert:

Code: Alles auswählen

root@HP350G2:/home/peter# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:usr/local/sbin:/usr/sbin:/sbin

[hikaru]

Apr 29 22:06:31 HP350G2 kernel: perf: interrupt took too long (3997 > 3956), lowering kernel.perf_event_max_sample_rate to 50000

Diese Meldung ist interessant, mehr aber auch nicht. Das kann auf ein Problem hindeuten, muss es aber nicht.

CPU:
Topology: Dual Core model: Intel Pentium 3805U bits: 64 type: MCP
L2 cache: 2048 KiB
Speed: 798 MHz min/max: 500/1900 MHz Core speeds (MHz): 1: 798 2: 798

Hast du intel-microcode installiert?

PS:
Bitte benutze code-Blöcke!

[peter1969]

Hast du intel-microcode installiert?

PS: Bitte benutze code-Blöcke!

Ja, ist installiert. Aber was sind code-Blöcke?

[willy4711]

Eine Bitte:
Pack die Ausgaben doch noch nachträglich in Code Tags , damit man keine Augenkrämpfe bekommt, wenn man das versucht zu entziffern. Danke

[willy4711]

Wenn dein Rechner das nächste Mal einfriert, wären die letzten Zeilen des letzten Journals interessant:

Code: Alles auswählen

journalctl -b -1 -n20

Das gibt die letzten 20 Zeilen vor dem erneuten Hochfahren (vorletzter boot) aus.

eins ist mir noch aufgefallen: mein System brauchte von Installation an für viele Befehle ein /sbin/ davor, weil dieses offenbar nicht im Path war:

Wird mit su - (in Sprech: Minus) umgangen

[peter1969]

ok, hiermit geschehen. Bei Stretch hat immer die Energiesparfunktion meiner WLAN-Karte Probleme gemacht. Allerdings führte das nur zum Abschalten des WLAN und nicht zum Einfrieren des ganzen Systems. Aber man weiss ja nie, deshalb nun auch:

echo 'options rtl8723be fwlps=0' | tee -a /etc/modprobe.d/rtl8723be.conf
echo 'KERNEL=="wlp2s0", RUN+="/sbin/iwconfig wlp2s0 txpower 18"' | tee -a /etc/udev/rules.d/75-wlan.rules

[hikaru]

Wenn intel-microcode installiert ist, dann würde ich annehmen*, dass zumindest die CPU nicht das Problem ist.
So ganz ohne verwertbare Fehlermeldung würde ich neben der CPU den Grafiktreiber verdächtigen. Ist xserver-xorg-video-intel installiert? Falls ja, bitte mal deinstallieren, falls nicht, bitte mal installieren und nach einem Reboot beobachten, ob sich die Situation ändert!

*) Das ist keine sachlich begründete Annahme, mehr eine den Möglichkeiten geschuldete - wie bei dem Betrunkenen, der nur unter der Laterne seinen Schlüssel sucht, weil er ihn ja woanders eh nicht sehen kann.

[peter1969]

*) Das ist keine sachlich begründete Annahme, mehr eine den Möglichkeiten geschuldete - wie bei dem Betrunkenen, der nur unter der Laterne seinen Schlüssel sucht, weil er ihn ja woanders eh nicht sehen kann.

Mit ebendieser Strategie habe ich soeben das WLAN-Modul ein bisschen modifiziert. Vorschlag: Wir üben uns in Geduld und warten bis zum nächsten Absturz, bevor ich den durchaus installierten xserver-xorg-video-intel deinstalliere. Sonst wissen wir am Ende nicht, welcher Schuss ins Blaue ins Schwarze getroffen hat.

[willy4711]

Mit ebendieser Strategie habe ich soeben das WLAN-Modul ein bisschen modifiziert. Vorschlag: Wir warten bis zum nächsten Absturz, bevor ich den durchaus installierten xserver-xorg-video-intel deinstalliere. Sonst wissen wir am Ende nicht, welcher Schuss ins Blaue ins Schwarze getroffen hat.

Wäre ja mal interessant, ob die Hänger auch mit LAN-Verbindung auftreten. Dass ein System es übel nimmt, wenn der "Datenfluss" nicht mehr stimmt, habe ich - ob bei Windows oder Linux - auch schon oft beobachtet.

[willy4711]

Dumme Frage :
i965-va-driver ist installiert ?

[peter1969]

Ja:

Code: Alles auswählen

root@HP350G2:/home/peter# apt list i965*
Auflistung... Fertig
i965-va-driver-shaders/testing 2.3.0-1 amd64
i965-va-driver/testing,now 2.3.0+dfsg1-1 amd64  [Installiert,automatisch]

Übrigens hat mich dieser Beitrag dazu inspiriert, die Sache mit dem Modul rtl8723be auszuprobieren; immerhin gehts da anscheinend auch um eine marodierende Energiesparfunktion (bzw. eine Überreaktion des Systems auf eine Energiesparfunktion) wenn auch ein völlig anderes Modul betreffend:
viewtopic.php?f=13&t=172870&hilit=buster

[peter1969]

Am Modul rtl8723be lags wohl doch nicht, gerade ist der Rechner wieder abgestürzt. Hier die Ausgabe von journalctl -b -1 -n20:

Code: Alles auswählen

peter@HP350G2:~$ journalctl -b -1 -n20
-- Logs begin at Mon 2019-04-29 13:28:06 CEST, end at Tue 2019-04-30 11:56:34 CEST. --
Apr 30 11:21:24 HP350G2 org.freedesktop.thumbnails.Thumbnailer1[714]: Registered thumbailer /usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o
Apr 30 11:21:24 HP350G2 org.freedesktop.thumbnails.Thumbnailer1[714]: Registered thumbailer atril-thumbnailer -s %s %u %o
Apr 30 11:25:33 HP350G2 su[1908]: (to root) peter on pts/0
Apr 30 11:25:33 HP350G2 su[1908]: pam_unix(su:session): session opened for user root by (uid=1000)
Apr 30 11:27:21 HP350G2 wpa_supplicant[432]: wlp2s0: WPA: Group rekeying completed with f4:06:8d:cb:61:51 [GTK=CCMP]
Apr 30 11:28:01 HP350G2 kernel: battery: [Firmware Bug]: battery: (dis)charge rate invalid.
Apr 30 11:30:01 HP350G2 CRON[1975]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 30 11:30:01 HP350G2 CRON[1976]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc
Apr 30 11:30:01 HP350G2 CRON[1975]: pam_unix(cron:session): session closed for user root
Apr 30 11:34:53 HP350G2 systemd[1]: Started Run anacron jobs.
Apr 30 11:34:53 HP350G2 anacron[2014]: Anacron 2.3 started on 2019-04-30
Apr 30 11:34:54 HP350G2 anacron[2014]: Will run job `cron.daily' in 5 min.
Apr 30 11:34:54 HP350G2 anacron[2014]: Jobs will be executed sequentially
Apr 30 11:39:53 HP350G2 anacron[2014]: Job `cron.daily' started
Apr 30 11:39:53 HP350G2 anacron[2060]: Updated timestamp for job `cron.daily' to 2019-04-30
Apr 30 11:39:53 HP350G2 cracklib[2084]: no dictionary update necessary.
Apr 30 11:39:54 HP350G2 anacron[2014]: Job `cron.daily' terminated
Apr 30 11:39:54 HP350G2 anacron[2014]: Normal exit (1 job run)
Apr 30 11:39:54 HP350G2 systemd[1]: anacron.service: Succeeded.
Apr 30 11:40:20 HP350G2 kernel: perf: interrupt took too long (2538 > 2500), lowering kernel.perf_event_max_sample_rate to 78750

Ob mein Prozessor auch in einen C6-Ruhezustand fällt (ähnlich wie der AMD Ryzen im oben verlinkten Thread)? Und wie kann ich den C6 bei meinem Prozessor verhindern? Im BIOS gibts jedenfalls keine Einstellmöglichkeit.

[JTH]

eins ist mir noch aufgefallen: mein System brauchte von Installation an für viele Befehle ein /sbin/ davor, weil dieses offenbar nicht im Path war:

Das ist kein Fehler, sondern eine bewusste Änderung am Verhalten von su, siehe

Code: Alles auswählen

$ zcat /usr/share/doc/util-linux/NEWS.Debian.gz
[…]

  The util-linux implementation of /bin/su is now used, replacing the
  one previously supplied by src:shadow (shipped in login package), and
  bringing Debian in line with other modern distributions. The two
  implementations are very similar but have some minor differences (and
  there might be more that was not yet noticed ofcourse), e.g.

  - new 'su' (with no args, i.e. when preserving the environment) also
    preserves PATH and IFS, while old su would always reset PATH and IFS
    even in 'preserve environment' mode.
  - new 'su -' (creating new environment) will do just that […]

[…]

  The first difference is probably the most user visible one. Doing
  plain 'su' is a really bad idea for many reasons, so using 'su -' is
  strongly recommended to always get a newly set up environment similar
  to a normal login. If you want to restore behaviour more similar to
  the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

Um das alte Verhalten zu haben – su setzt PATH inklusive /sbin und /usr/sbin – sollte man

Code: Alles auswählen

$ su -

benutzen.

[peter1969]

ok danke. ich jedenfalls probiere gerade den boot-Parameter processor.max_cstate=5. Vielleicht bringts das ja.

[peter1969]

Hier habe ich noch einen interessanten Artikel gefunden:

https://www.golem.de/news/intel-einfrie ... 23546.html

Die letzte Journal-Zeile vor dem letzten Absturz hatte immerhin irgendwas mit interrupts zu tun:

Apr 30 11:40:20 HP350G2 kernel: perf: interrupt took too long (2538 > 2500), lowering kernel.perf_event_max_sample_rate to 78750

Mein Prozessor ist ein Pentium 3805U. Der könnte das Problem ja auch haben. Bloss, wie wende ich so ein Shell-Script an? Und warum gab es das Problem nicht mit Stretch?

[MSfree]

Hier habe ich noch einen interessanten Artikel gefunden:

https://www.golem.de/news/intel-einfrie ... 23546.html

Mein Prozessor ist ein Pentium 3805U.

Der Prozessor aus deinem Link ist ein Atom-Prozessor der Baytrail-Reihe. Du hast aber einen Prozessor der Broadwell-Reihe, also der Reihe, auf dem alle Core-i-5000 basieren. Atom und Core-i sind nun aber zwei völlig unterschiedliche CPU-Designs. Ich mag nicht so recht daran glauben, daß das C-State-Problem auch beim Core-i existieren soll.

Die letzte Journal-Zeile vor dem letzten Absturz hatte immerhin irgendwas mit interrupts zu tun:

So, wie ich das interprätieren, stammt die letzte Zeile aus deinem Journalauszug schon vom Bootvorgang nach dem Absturz, hat also mit dem Absturz nichts zu tun.

Ich hege ohnehin Zweifel, daß das Journal auch nur ein Quäntchen Information birgt, das man mit dem Absturz in Verbinung bringen könnte. Solche Hänger kündigen sich nicht an, folglich wird im Journal auch keine Ursache erkennbar sein.

[KP97]

...Und warum gab es das Problem nicht mit Stretch?

Weil Stretch einen anderen Kernel hat?
Zum Intel Grafiktreiber:
Es reicht nicht, das Paket installiert zu haben. Damit der auch benutzt wird, sollte man einen Eintrag in der /etc/X11/xorg.conf haben:

Section "Device"
Identifier "Intel"
Driver "intel"
EndSection

Sonst wird der kerneleigene modesetting benutzt. Welcher nun läuft, kann man im Xorg.log sehen.
Zum testen ist es einen Versuch wert.

[peter1969]

Ok, das probiere ich mal. Aber xorg.conf ist wohl nicht mehr ganz modern, ich habe die conf-Datei zum Laden des Intel-Treibers daher so erzeugt /usr/share/X11/xorg.conf.d/80-intel.conf. Laut cat /var/log/Xorg.0.log und inxi -F läuft derselbige nun auch. Schaumermal, ob wieder ein Absturz kommt. Ich teste und melde mich.

[KP97]

... Aber xorg.conf ist wohl nicht mehr ganz modern...

Na ja, aber wenn eine xorg.conf existiert, wird diese auch verarbeitet. Die ist spätestens dann wieder notwendig, wenn man außerhalb des Standards bzw. des Kernels eigene Parameter setzen will.
Ich hätte die config allerdings nicht nach /usr/share/X11 gestellt, da die Inhalte bei einem Update überschrieben werden. Ob das dann auch Deine angelegte Datei betrifft, weiß ich nicht. Aber sicherheitshalber sollte man immer eigene Konfigs nach /etc/X11 stellen, da passiert das keinesfalls.

Läuft denn jetzt alles?

[MSfree]

...da die Inhalte bei einem Update überschrieben werden.

Ein Update überschreibt unter /etc nichts ungefragt.

[peter1969]

Läuft denn jetzt alles?

Es scheint so. zumindest hatte ich bis jetzt keinen Absturz mehr (aber man soll den Tag ja nicht vor dem Abend loben ). Das Tearing, dass ich bis jetzt bei h.264 Videos hatte, ist jetzt jedenfalls weg. Vielen Dank mal alle zusammen. Ich werde demnächst mal ans Forum spenden.

[KP97]

Hab ich auch nicht gesagt, ich sprach von /usr/share...und weiterhin von einer eigenen Konfig. Wahrscheinlich bleibt die bestehen, aber sicherheitshalber....usw.
Eine Abfrage kann man auch mal schnell übersehen....wie gesagt....sicherheitshalber...;-)