Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #121023 > unrolled thread

Kernelbug

Started byHolger Schauer <Holger.Schauer@gmx.de>
First post2022-01-26 11:22 +0100
Last post2022-01-27 08:19 +0100
Articles 4 — 3 participants

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Kernelbug Holger Schauer <Holger.Schauer@gmx.de> - 2022-01-26 11:22 +0100
    Re: Kernelbug Tim Ritberg <tim@server.invalid> - 2022-01-26 11:45 +0100
      Re: Kernelbug Holger Schauer <Holger.Schauer@gmx.de> - 2022-01-26 18:00 +0100
    Re: Kernelbug Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-01-27 08:19 +0100

#121023 — Kernelbug

FromHolger Schauer <Holger.Schauer@gmx.de>
Date2022-01-26 11:22 +0100
SubjectKernelbug
Message-ID<87zgniu78v.fsf@pixie.holgi.priv>
Moin Moin,

gestern hat sich meine Workstation weggehängt; erst wurde sie langsamer,
dann ging nichts mehr. Magic SysRequest ging aber noch. 

In den kern.log sehe ich dann folgendes:

Jan 24 08:32:56 pixie kernel: [418679.943353] list_del corruption. next->prev should be ffff97f080169940, but was 0000000000000000
Jan 24 08:32:56 pixie kernel: [418679.943362] ------------[ cut here ]------------
Jan 24 08:32:56 pixie kernel: [418679.943363] kernel BUG at lib/list_debug.c:54!
Jan 24 08:32:56 pixie kernel: [418679.943368] invalid opcode: 0000 [#1] SMP NOPTI
Jan 24 08:32:56 pixie kernel: [418679.943371] CPU: 7 PID: 230 Comm: kswapd0 Tainted: P           OE     5.10.0-10-amd64 #1 Debian 5.10.84-1
Jan 24 08:32:56 pixie kernel: [418679.943372] Hardware name: Micro-Star International Co., Ltd. MS-7B09/X399 GAMING PRO CARBON AC (MS-7B09), BIOS 1.B0 08/09/2018
Jan 24 08:32:56 pixie kernel: [418679.943376] RIP: 0010:__list_del_entry_valid.cold+0x1d/0x47
Jan 24 08:32:56 pixie kernel: [418679.943378] Code: c7 c7 70 00 d2 9b e8 fd 13 ff ff 0f 0b 48 89 fe 48 c7 c7 00 01 d2 9b e8 ec 13 ff ff 0f 0b 48 c7 c7 b0 01 d2 9b e8 de 13 ff ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 70 01 d2 9b e8 ca 13 ff ff 0f 0b
Jan 24 08:32:56 pixie kernel: [418679.943379] RSP: 0018:ffffb9b5c0b33ad8 EFLAGS: 00010246
Jan 24 08:32:56 pixie kernel: [418679.943381] RAX: 0000000000000054 RBX: ffff97f080169940 RCX: 0000000000000000
Jan 24 08:32:56 pixie kernel: [418679.943382] RDX: 0000000000000000 RSI: ffff97f45d7dca00 RDI: ffff97f45d7dca00
Jan 24 08:32:56 pixie kernel: [418679.943383] RBP: ffffb9b5c0b33bb8 R08: 0000000000000000 R09: ffffb9b5c0b33900
Jan 24 08:32:56 pixie kernel: [418679.943383] R10: ffffb9b5c0b338f8 R11: ffff97f45d0fffe8 R12: ffff97ed1126a900
Jan 24 08:32:56 pixie kernel: [418679.943384] R13: 0000000000000000 R14: ffffb9b5c0b33bb8 R15: ffff97ed1126a900
Jan 24 08:32:56 pixie kernel: [418679.943385] FS:  0000000000000000(0000) GS:ffff97f45d7c0000(0000) knlGS:0000000000000000
Jan 24 08:32:56 pixie kernel: [418679.943386] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 24 08:32:56 pixie kernel: [418679.943386] CR2: 0000207708650000 CR3: 000000034ccda000 CR4: 00000000003506e0
Jan 24 08:32:56 pixie kernel: [418679.943387] Call Trace:
Jan 24 08:32:56 pixie kernel: [418679.943391]  list_lru_isolate_move+0x1c/0x60
Jan 24 08:32:56 pixie kernel: [418679.943395]  dentry_lru_isolate+0x4f/0xf0
[...]

Danach finde ich dann wiederholt über alle CPUs und für diverse Prozesse
Einträge wie 

Jan 24 08:33:24 pixie kernel: [418707.656159] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [nextcloud:17646]

Und verschiedene Stacktraces, davon recht viele Einträge mit einer der
folgenden RIP Nachrichten:

Jan 24 08:34:04 pixie kernel: [418747.744602] RIP: 0010:multi_cpu_stop+0x96/0x110
Jan 24 08:34:08 pixie kernel: [418751.696709] RIP: 0010:rcu_momentary_dyntick_idle+0x24/0x30
Jan 24 08:34:09 pixie kernel: [418752.661580] RIP: 0010:native_queued_spin_lock_slowpath+0x1a4/0x1d0

Der Kernel hier ist ein Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux;
Hardware ist ein Threadripper 2950 mit 32GB. 

Aktuell scheint das System wieder stabil zu laufen, aber dennoch: Kann
hier jemand damit irgendwas anfangen, insbesondere in Hinblick auf
defekte Hardware?

Holger

-- 
---          http://blog.find-method.de/            ---
"Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
 die anderen sind einfach von sich aus unlogisch."
                  -- Anselm Lingnau in de.comp.os.unix.linux.misc

[toc] | [next] | [standalone]

#121024

FromTim Ritberg <tim@server.invalid>
Date2022-01-26 11:45 +0100
Message-ID<ssr8os$70d8$1@tota-refugium.de>
In reply to#121023
Am 26.01.22 um 11:22 schrieb Holger Schauer:
> 
> Der Kernel hier ist ein Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux;
> Hardware ist ein Threadripper 2950 mit 32GB.
> 
> Aktuell scheint das System wieder stabil zu laufen, aber dennoch: Kann
> hier jemand damit irgendwas anfangen, insbesondere in Hinblick auf
> defekte Hardware?
> 
Illegal opcode: entweder das Binary war falsch gebaut oder du brauchst 
ein Microcode-Update.

Tim

[toc] | [prev] | [next] | [standalone]

#121027

FromHolger Schauer <Holger.Schauer@gmx.de>
Date2022-01-26 18:00 +0100
Message-ID<87v8y6tot4.fsf@pixie.holgi.priv>
In reply to#121024
On 10374 September 1993, Tim Ritberg wrote:
> Am 26.01.22 um 11:22 schrieb Holger Schauer:
[Kernelcrash]
> Illegal opcode: entweder das Binary war falsch gebaut oder du brauchst
> ein Microcode-Update.

Hmm. Illegal opcode gab es nur einmal in den Traces. Wenn ich mir den
zugehörigen Call Trace ansehe, dann sieht der in seiner Gänze so aus:

Jan 24 08:32:56 pixie kernel: [418679.943387] Call Trace:
Jan 24 08:32:56 pixie kernel: [418679.943391]  list_lru_isolate_move+0x1c/0x60
Jan 24 08:32:56 pixie kernel: [418679.943395]  dentry_lru_isolate+0x4f/0xf0
Jan 24 08:32:56 pixie kernel: [418679.943396]  __list_lru_walk_one+0x77/0x150
Jan 24 08:32:56 pixie kernel: [418679.943397]  ? __dentry_kill+0x180/0x180
Jan 24 08:32:56 pixie kernel: [418679.943398]  ? __dentry_kill+0x180/0x180
Jan 24 08:32:56 pixie kernel: [418679.943399]  list_lru_walk_one+0x47/0x70
Jan 24 08:32:56 pixie kernel: [418679.943401]  prune_dcache_sb+0x49/0x80
Jan 24 08:32:56 pixie kernel: [418679.943403]  super_cache_scan+0x12c/0x1e0
Jan 24 08:32:56 pixie kernel: [418679.943405]  do_shrink_slab+0x145/0x240
Jan 24 08:32:56 pixie kernel: [418679.943406]  shrink_slab+0x188/0x2a0
Jan 24 08:32:56 pixie kernel: [418679.943408]  shrink_node+0x2c0/0x6e0
Jan 24 08:32:56 pixie kernel: [418679.943410]  balance_pgdat+0x2e5/0x600
Jan 24 08:32:56 pixie kernel: [418679.943411]  kswapd+0x1f6/0x380
Jan 24 08:32:56 pixie kernel: [418679.943414]  ? add_wait_queue_exclusive+0x70/0x70
Jan 24 08:32:56 pixie kernel: [418679.943415]  ? balance_pgdat+0x600/0x600
Jan 24 08:32:56 pixie kernel: [418679.943417]  kthread+0x11b/0x140
Jan 24 08:32:56 pixie kernel: [418679.943419]  ? __kthread_bind_mask+0x60/0x60
Jan 24 08:32:56 pixie kernel: [418679.943421]  ret_from_fork+0x22/0x30

Das hilft jetzt nicht wirklich einen spezifischen Prozess/Binary zu
identifizieren und macht es zumindest sehr unwahrscheinlich, dass es ein
falsch gebautes Binary war.

Evtl. auch ein Bitkipper beim Aufwachen aus dem Hibernate?

Holger

-- 
---          http://blog.find-method.de/            ---
"Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
 die anderen sind einfach von sich aus unlogisch."
                  -- Anselm Lingnau in de.comp.os.unix.linux.misc

[toc] | [prev] | [next] | [standalone]

#121036

FromMarcel Mueller <news.5.maazl@spamgourmet.org>
Date2022-01-27 08:19 +0100
Message-ID<ssth2k$1b98n$1@gwaiyur.mb-net.net>
In reply to#121023
Am 26.01.22 um 11:22 schrieb Holger Schauer:
> gestern hat sich meine Workstation weggehängt; erst wurde sie langsamer,
> dann ging nichts mehr. Magic SysRequest ging aber noch.
> 
> In den kern.log sehe ich dann folgendes:
> 
> Jan 24 08:32:56 pixie kernel: [418679.943353] list_del corruption. next->prev should be ffff97f080169940, but was 0000000000000000
> Jan 24 08:32:56 pixie kernel: [418679.943362] ------------[ cut here ]------------
> Jan 24 08:32:56 pixie kernel: [418679.943363] kernel BUG at lib/list_debug.c:54!
> Jan 24 08:32:56 pixie kernel: [418679.943368] invalid opcode: 0000 [#1] SMP NOPTI

Da wird man nicht mehr viel herausfinden können, solange es nicht gerade 
reproduzierbar wird.

Wahrscheinlichster Auslöser, würde ich sagen, ist, dass irgendein 
anderer Programmteil direkt oder indirekt (z.B. über SGDMA) 
"Datenbomben" gelegt hat und Speicherinhalte willkürlich geändert. Das 
kann natürlich ein kaputter Treiber sein. Aber das muss immer noch nicht 
der Ursprung des Problems sein.

Da kommen als nächstes Hardwareprobleme in Betracht. Kaputter Speicher 
(falls nicht ECC) wäre ein heißer Kandidat. Kaputte Cache-RAMs 
ebenfalls. ie könne  quasi überall sein, z.B. in der HDD oder SSD.

Naja, und natürlich der Klassiker: instabile Stromversorgung, meist 
wegen Elkoinsuffizienz, z.B. im Netzteil oder auf dem MoBo.

SATA-Kabel sollte man auch mal checken. Die zicken öfter mal rum. Die 
haben zwar auch Prüfsummen, aber die hässlichen Timeouts, die dabei 
entstehen können, werden auch nicht immer in allen Ecken korrekt behandelt.

Du kannst auf jeden Fall auch mal versuchen, eine Kerner-Update-Version 
zurück zu gehen und zu testen, ob es deine Probleme löst.

> Danach finde ich dann wiederholt über alle CPUs und für diverse Prozesse
> Einträge wie
> 
> Jan 24 08:33:24 pixie kernel: [418707.656159] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [nextcloud:17646]

So sachen sind zumindest komisch.

> Und verschiedene Stacktraces, davon recht viele Einträge mit einer der
> folgenden RIP Nachrichten:
> 
> Jan 24 08:34:04 pixie kernel: [418747.744602] RIP: 0010:multi_cpu_stop+0x96/0x110
> Jan 24 08:34:08 pixie kernel: [418751.696709] RIP: 0010:rcu_momentary_dyntick_idle+0x24/0x30
> Jan 24 08:34:09 pixie kernel: [418752.661580] RIP: 0010:native_queued_spin_lock_slowpath+0x1a4/0x1d0

Das kann auch ein Programmierfehler sein. Da hat jemand versucht 
lock-free zu programmieren, und hat unterschätzt, wie Cacheline-Hopping 
den Prozess ausbremsen kann. Das kann manchmal zu Quasi-Endlosschleifen 
führen, wenn der Algorithmus nicht forward progress garantiert. Auf 
jeden Fall reduziert es den Befehlsdurchsatz (IPC) um Zehnerpotenzen und 
skaliert oft negativ mit der Anzahl der Kerne, und davon hast Du ja genug.

So Späßchen hatte ich auch schon. User-Level Lock-Free Code, der auf der 
einen x86 CPU 100% zuverlässig läuft, auf diversen anderen noch gut, 
aber dann auf einem 10 Jahre alten Xeon komplett abkackt, weil der 
statisttisch gesehen an ganz anderen Stellen hängen bleibt, als man 
erwartet.

Falls Nextcloud der Fehler öfters triggert, kannst Du mal versuchen, die 
Anzahl der CPU-Kerne für diesen Prozess zu begrenzen - das braucht ja 
nicht viel. Notfalls geht das auch, indem man es in eine VM mit weniger 
Kernen verbannt. Dann reißt es auch nicht mehr so leicht den Host mit 
ins Grab.


> Der Kernel hier ist ein Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux;
> Hardware ist ein Threadripper 2950 mit 32GB.
> 
> Aktuell scheint das System wieder stabil zu laufen, aber dennoch: Kann
> hier jemand damit irgendwas anfangen, insbesondere in Hinblick auf
> defekte Hardware?

Hardwaredefekte wären möglich. Aber das ist nicht die einzige Option.

Da hilft nur beobachten. Hardwaredefekte werden mit der Zeit selten 
besser, meist schlechter. Bei Software ist es eher anders herum.


Marcel

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web