häufiger Absturz

[Linaxel]

Hallo zusammen,

mein Debian Buster stürzt fast täglich einmal ab. Die letzten Zeilen in daemon.log vor dem Absturz lauten:

Mar 10 09:39:20 debian20 systemd[1]: Started Hostname Service.
Mar 10 09:39:50 debian20 systemd[1]: systemd-hostnamed.service: Succeeded.
Mar 10 09:40:01 debian20 debarchiver: Error: Create lockfile debarchiver.lock
Mar 10 09:40:01 debian20 debarchiver:
Mar 10 09:40:01 debian20 debarchiver: EXIT: 2
Mar 10 09:45:01 debian20 debarchiver: Error: Create lockfile debarchiver.lock
Mar 10 09:45:01 debian20 debarchiver:
Mar 10 09:45:01 debian20 debarchiver: EXIT: 2

Wer kann hier helfen ?
Geben noch andere Log-Files wichtige Hinweise ?

Danke schon mal

[MSfree]

mein Debian Buster stürzt fast täglich einmal ab.

Wie äussert sich das? Ist noch irgendwas auf dem Bildschirm sichtbar, z.B. Kernel Panic?

Die letzten Zeilen in daemon.log vor dem Absturz lauten:

Das ist so ziemlich die letzte Datei, in der ich brauchbare Information vermuten würde.

Buster logt mittels journald in eine binäre Datei, die man mit dem Befehl journalctl untersuchen kann.

[Linaxel]

Danke erstmal.

Der Absturz äußert sich, indem der Bildschirm eingefroren ist und weder mit Maus noch Tastatur eine Eingabe möglich ist.

journalctl war mir nicht bekannt, aber es scheint, als ob damit nur logs seit dem letzten booten abgefragt werden können. Zumindest bin ich bis jetzt noch nicht an ältere logs dran gekommen.

VG

[Linaxel]

sorry, muss mich korrigieren :

o see previous boots, you can use a number to tell journalctl which boot you’re interested in

Code: Alles auswählen

journalctl -b 3

[MSfree]

Was für Hardware steckt in deinem Rechner?

Du hast nicht zufällig einen Intel Baytrail (Celeron J oder N)?

[Linaxel]

Zunächst ein Nachtrag zu meinem letzten Post: Buster merkt sich per default nur die logs seit dem letzten booten. Um das zu ändern, ist dies notwendig :

Code: Alles auswählen

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

Jetzt heisst es, den nächsten Crash abzuwarten....

Was für Hardware steckt in deinem Rechner?

Du hast nicht zufällig einen Intel Baytrail (Celeron J oder N)?

Was ist ein Intel Baytrail ? Wo sehe ich das ?

VG

[willy4711]

Was ist ein Intel Baytrail ? Wo sehe ich das ?

Am einfachsten:
inxi installieren
dann

Code: Alles auswählen

inxi -C

[willy4711]

sorry, muss mich korrigieren :

Code: Alles auswählen

journalctl -b 3

Kleine Korrektur:

Code: Alles auswählen

journalctl -b 3

gibt die Daten des 3. Boot- Vorgangs aus - von vorne gezählt (bei mir Irgendwann im Januar)

Code: Alles auswählen

journalctl -b -3

gibt die Daten des 3.-letzten Bootvorgangs aus (von hinten gezählt)

Wenn es "gekracht" hat, wäre es also sinnvoll in:

Code: Alles auswählen

journalctl -b -1

zu suchen.
Anzusehen mit:

Code: Alles auswählen

 journalctl --list-boots

[MSfree]

Was ist ein Intel Baytrail ? Wo sehe ich das ?

CPU-Informationen bekommt man (ohne Softwareinstallation) ganz einfach mit

Code: Alles auswählen

cat /proc/cpuinfo

oder mit

Code: Alles auswählen

lscpu

Baytrail ist der Codename für eine Linie von Intel Atom-CPUs, die z.B. als Celeron J1900 oder als Celeron N3450 verkauft wurden.

[willy4711]

Will ja nicht über die internen Tools meckern.
Aber:

Code: Alles auswählen

~$ inxi -Cxx
CPU:       Info: 8-Core model: Intel Core i9-9900 bits: 64 type: MT MCP arch: Kaby Lake note: check rev: D L2 cache: 16 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 99199 
           Speed: 800 MHz min/max: 800/5000 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 
           9: 800 10: 800 11: 800 12: 800 13: 800 14: 800 15: 801 16: 800 

Und:

Code: Alles auswählen

lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          16
On-line CPU(s) list:             0-15
Thread(s) per core:              2
Core(s) per socket:              8
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           158
Model name:                      Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz
Stepping:                        13
CPU MHz:                         1231.709
CPU max MHz:                     5000,0000
CPU min MHz:                     800,0000
BogoMIPS:                        6199.99
Virtualization:                  VT-x
L1d cache:                       256 KiB
L1i cache:                       256 KiB
L2 cache:                        2 MiB
L3 cache:                        16 MiB
NUMA node0 CPU(s):               0-15
Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
Vulnerability Srbds:             Mitigation; TSX disabled
Vulnerability Tsx async abort:   Mitigation; TSX disabled
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe s
                                 yscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf p
                                 ni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt t
                                 sc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp
                                  ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdse
                                 ed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_
                                 epp md_clear flush_l1d arch_capabilities

In meinem Fall: Die Baureihe "Kaby Lake" liefert nur inxi

[Linaxel]

ok, der nächste Absturz.

journalctl -b 1 bringt nix anderes als das, was ich vorher gepostet hatte:

Code: Alles auswählen

Mär 10 18:15:01 debian20 CRON[15056]: pam_unix(cron:session): session closed for user debarchiver
Mär 10 18:17:01 debian20 CRON[15088]: pam_unix(cron:session): session opened for user root by (uid=0)
Mär 10 18:17:01 debian20 CRON[15089]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mär 10 18:17:01 debian20 CRON[15088]: pam_unix(cron:session): session closed for user root
Mär 10 18:20:01 debian20 CRON[15112]: pam_unix(cron:session): session opened for user debarchiver by (uid=0)
Mär 10 18:20:01 debian20 CRON[15114]: (debarchiver) CMD (test -x /usr/bin/debarchiver && /usr/bin/debarchiver -so | logger -t debarchiver -p daemon.info)
Mär 10 18:20:01 debian20 debarchiver[15116]: Error: Create lockfile debarchiver.lock
Mär 10 18:20:01 debian20 debarchiver[15116]: 
Mär 10 18:20:01 debian20 debarchiver[15116]: EXIT: 2
Mär 10 18:20:01 debian20 CRON[15112]: pam_unix(cron:session): session closed for user debarchiver

... und dies mehrmals vor dem Absturz.

Kann jemand damit was anfangen ?

VG

[MSfree]

Sag uns doch bitte mal, was du für eine CPU in der Kiste hast. Entweder mit

Code: Alles auswählen

lscpu

oder mit

Code: Alles auswählen

cat /proc/cpuinfo

oder, von mir aus auch mit inxi, wie willy4711 oben vorgeschlagen hat.

In deinem Log steht jedenfalls nichts, was einen Absturz rechtfertigen würde.

[Linaxel]

Hi,

dann tu ich das mal.
lscpu ergibt:

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 43 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 1
Model name: AMD Ryzen 3 1200 Quad-Core Processor
Stepping: 1
CPU MHz: 3171.586
CPU max MHz: 3100,0000
CPU min MHz: 1550,0000
BogoMIPS: 6187.70
Virtualization: AMD-V
L1d cache: 32K
L1i cache: 64K
L2 cache: 512K
L3 cache: 4096K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

cat /proc/cpuinfo kann ich gerne nachliefern, falls das helfen sollte.

Nachtrag : Auf dem PC war vorher 2 Jahre lang Debian 9, da gab es die Probleme nicht.

VG

[MSfree]

Code: Alles auswählen

Model name:          AMD Ryzen 3 1200 Quad-Core Processor

Das ist zwar kein Intel Atom, aber der Ryzen der ersten Generation hatte wohl einen ähnlichen Fehler in seinen Stromsparmechanismen.

cat /proc/cpuinfo kann ich gerne nachliefern, falls das helfen sollte.

Das liefert praktisch das gleiche wie lscpu.

Probiere mal folgendes:

Öffne die Datei /etc/default/grub mit einem Texteditor und ändere die Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT anfängt und hänge

Code: Alles auswählen

processor.max_cstate=1

an (zwischen die Anführungszeichen). Dann mußt du noch update-grub ausführen und neu starten.

Es gibt im Internet noch mehrere unterschiedliche Anleitungen, um dem Problem Herr zu werden, hier z.B. eine andere Lösung:
https://forum.kuketz-blog.de/viewtopic.php?t=107

[kalle123]

Nachtrag : Auf dem PC war vorher 2 Jahre lang Debian 9, da gab es die Probleme nicht.

Nur so am Rande. Schon mal den PC aufgemacht, ausgeblasen, Karten, Steckverbindungen neu gesteckt.

Soll manchmal Wunder wirken.

Gruß KH

PS. Meiner hier war heute wieder mal fällig.

[Linaxel]

Vielen Dank für Eure Tips.

Mit Staub im PC hab ich auch schon schlechte Erfahrungen gemacht. Daher werde ich das Gerät morgen erst mal auseinandernehmen (und die Stecker prüfen, habe den PC damals selbst zusammengesteckt)

Wenn das nix hilft, prüfe ich die anderen Optionen. Werde nann Rückmeldung geben.

VG

[Linaxel]

So, die Entstaubung war erfolgreich . Ich muss immer noch husten

Jetzt heisst es erst mal abwarten, was passiert.

VG

[Linaxel]

so, danke nochmal für die Tips.

Seit der Entstaubung vor 8 Tagen sind die Probleme nicht wieder aufgetreten. Ich denke, damit ist der Fall klar.

VG

[kalle123]

Dank dir für die Rückmeldung

cu KH

[Linaxel]

ES ist wieder da.
Diesmal konnte ich die letzte Ausgabe vor dem Absturz von journalctl ermitteln:

E: [alsa-sink-ALC887-VD Analog] alsa-sink.c: ALSA weckte uns auf, um neue Daten auf das Gerät zu schreiben, doch es gab nichts zum Schreiben!
E: [alsa-sink-ALC887-VD Analog] alsa-sink.c: Dies ist höchstwahrscheinlich ein Fehler im ALSA-Treiber »snd_hda_intel«. Bitte melden Sie diesen Fehler den ALSA-Entwicklern.
E: [alsa-sink-ALC887-VD Analog] alsa-sink.c: Wir wurden durch das POLLOUT-Set geweckt, allerdings lieferte ein anschließender snd_pcm_avail() den Wert 0 oder einen anderen Wert < min_avail.

Ich werde schauen, wo ich das den Entwicklern melden kann.

Oder hat vlt. jemand einen Tip ?

Danke

[MSfree]

ES ist wieder da.

Laß dir doch nicht alles aus der Nase ziehen. Beschreibe einfach mal, was, wann, unter welchen Umständen passiert ist.

Der Log-Auszug sagt jedenfalls mal wieder gar nichts aus. Der sagt, daß das Soundsystem aufgeweckt wurde, was immer passiert, wenn die CPU aus einem der Schlafzustände zurückkehrt. Dabei wurde festgestellt, daß das nichts über das Soundsystem auszugeben ist.

Das ist schlicht kein Fehler und der Hinweis, das den Entwicklern zu melden, ist wohl eher noch alter Debug-Code, der eigentlich nicht mehr vorhanden sein solte, denn die Situation wird sauber abgefangen und hat mit an Sicherheit grenzender Wahrscheinlichkeit nichts mit dem Absturz zu tun.

Die Ryzen-CPU in deinem Rechner hat einen bekannten Designfehler. Zum Stromsparen versetzen sich alle modernen CPUs regelmässig in einen Schlafzustand. Bei wenig Last wird erst der CPU-Takt runtergesetzt, bei noch weniger Last wird die CPU für kurze millisekundenlange Intervalle komplett angehalten. Das Aufwecken aus so einem angehaltenen Zustand ist hier das Problem, dabei kann sich das Teil aufhängen. Das Problem dabei ist, daß dann auch nichts mehr gelogt werden kann. Die letzten Logausgaben haben also nichts mit deinem Crash zu tun.

[willy4711]

Noch eine Anmerkung zu deinen Log's:
Wenn du das Journal so wie du es angegeben hast aufrufst:

Code: Alles auswählen

journalctl -b 3

Bekommst du irgendein Journal von irgendwann (Datum ??)
Die letzten 20 Zeilen vom letzten Bootvorgang bekommst du so:

Code: Alles auswählen

journalctl -b -1 -r -n20

Wobei das MINUS vor der 1 (bzw einer anderen Boot- Sequenz) zu beachten ist.

[Linaxel]

Danke für Antworten.

Mehr gibt

journalctl -b -1

leider nicht her.

Ich denke, ich werde es zunächst mit einem BIOS-Update versuchen. Wobei dies auch mein erster Versuch wäre, daher bin ich dankbar für Tips.

Meine ersten Recherchen auf der Suche nach updates für "AMD Ryzen 3 1200" waren noch nicht so erfolgreich.
Der Hersteller bietet dort Driver-Download für Windows an, was mich nicht überzeugt hat, außerdem habe ich eine zip-Datei names "furyx_nano_uefi_firmware" gefunden, von der ich nicht weiß, ob sie das richtige ist.

Gruß

[Linaxel]

Probiere mal folgendes:

Öffne die Datei /etc/default/grub mit einem Texteditor und ändere die Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT anfängt und hänge

Code: Alles auswählen

processor.max_cstate=1

an (zwischen die Anführungszeichen). Dann mußt du noch update-grub ausführen und neu starten.

ichhab gesehen, dass es eine ganze Menge an Parametern gibt, die man der Variable mitgeben kann.
Ich werde das mal probieren, vielleicht kannst Du mir sagen , was der Wert genau bedeutet.
(Ich vermute, dass die Parameter durch Leerzeichen getrennt werden müssen ?)

Gruß

[MSfree]

vielleicht kannst Du mir sagen , was der Wert genau bedeutet.

Weiter oben hatte ich beschrieben, daß deine CPU einen Designfehler hat, Details werde ich hier also nicht wiederholen.

Die verschiedenen Schlafzustände werden als C-States bezeichnet, wobei z.B. C6 mehr Stromersparnis bedeutet als C1. Mit max_cstate=1 teilst du dem Kernel mit, daß die CPU nur in den "leichten Schlaf" mit C1 verfallen darf. Vor allem die Zustände C7 und C6 bereiten bei einigen CPUs (erste Ryzen Serie, Intel Baytrail Atoms) Probleme beim Aufwachen und das System hängt sich komplett auf. Durch das Verhindern der tiefen Schlafzustände vermeidet man das Aufwachen auf den tiefen Schlafzuständen und somit auch die Crashes.