gelöst: HP350G2 friert mit Buster manchmal komplett ein

[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...;-)

[peter1969]

Also ich lege immer in /usr/share/lightdm/lightdm.conf.d/ eine eigene config-Datei ab, die im Anmeldebildschirm die Nutzernamen sichtbar macht (bin zu faul, die immer einzutippen). Die ist noch nie überschrieben worden. Ich denke, es würde Sinn ergeben, wenn ein Update höchstens nur solche Dateien überschreibt, die Debian bei der Installation selbst angelegt hat.