Auf einem Kundengerät sind mehrere rcu_sched-Stallmeldungen aufgetreten und es stürzt ab bzw. bleibt hängen. Unter diesen Umständen ist das Gerät nicht über SSH oder 3G erreichbar. Die Kernelversion ist 3.2.54. „rcu_sched hat einen Stall auf CPU 0 erkannt“ wird viele Male wiederholt. Was bedeutet das? Dieses Gerät stürzt während eines Power-Cycling-Tests ab. acpower_isr()/poe_isr() wird verwendet, um den AC-Stromstatus/PoE-Status bei jedem Umschalten zu aktualisieren. Verursacht dies das Problem? (Die Sperre kann nicht aufgehoben werden?)
Backtrace:
[<c4011504>] (dump_backtrace+0x0/0x110) from [<c43924bc>] (dump_stack+0x18/0x1c)
r6:c962e080 r5:c96462e0 r4:c9ec4674 r3:c96429bc
[<c43924a4>] (dump_stack+0x0/0x1c) from [<c4082188>] (__rcu_pending+0x88/0x38c)
[<c4082100>] (__rcu_pending+0x0/0x38c) from [<c4083218>] (rcu_check_callbacks+0xe8/0x17c)
[<c4083130>] (rcu_check_callbacks+0x0/0x17c) from [<c4043ac4>] (update_process_times+0x40/0x64)
r8:23339c9a r7:00000000 r6:c6f06ae0 r5:00000000 r4:c8ac8000
r3:00010000
[<c4043a84>] (update_process_times+0x0/0x64) from [<c406513c>] (tick_sched_timer+0x9c/0xdc)
r7:c9ec44a0 r6:c8ac9dd8 r5:c8ac8000 r4:c9ec4598
[<c40650a0>] (tick_sched_timer+0x0/0xdc) from [<c405805c>] (__run_hrtimer+0xf4/0x1c8)
r9:c8ac9d20 r8:23339580 r6:c9ec44d8 r5:c9ec44a0 r4:c9ec4598
[<c4057f68>] (__run_hrtimer+0x0/0x1c8) from [<c4058db4>] (hrtimer_interrupt+0x124/0x288)
[<c4058c90>] (hrtimer_interrupt+0x0/0x288) from [<c40139e0>] (twd_handler+0x28/0x30)
[<c40139b8>] (twd_handler+0x0/0x30) from [<c407f880>] (handle_percpu_devid_irq+0xd0/0x150)
r4:0000001d r3:c40139b8
[<c407f7b0>] (handle_percpu_devid_irq+0x0/0x150) from [<c407be30>] (generic_handle_irq+0x34/0x48)
[<c407bdfc>] (generic_handle_irq+0x0/0x48) from [<c400e5e0>] (handle_IRQ+0x80/0xc0)
[<c400e560>] (handle_IRQ+0x0/0xc0) from [<c40081d0>] (asm_do_IRQ+0x10/0x14)
r5:20000013 r4:c4395234
[<c40081c0>] (asm_do_IRQ+0x0/0x14) from [<c400d738>] (__irq_svc+0x38/0x120)
Exception stack(0xc8ac9dd8 to 0xc8ac9e20)
9dc0: c96ae534 00000013
9de0: 00000001 00000001 c96ae52c c82385a0 00000001 00000001 00006000 d0800000
9e00: d0800000 c8ac9e2c c8ac9e30 c8ac9e20 c40d2f4c c4395234 20000013 ffffffff
[<c4395218>] (_raw_spin_lock+0x0/0x30) from [<c40d2f4c>] (alloc_vmap_area.clone.18+0xa8/0x2f8)
[<c40d2ea4>] (alloc_vmap_area.clone.18+0x0/0x2f8) from [<c40d3268>] (__get_vm_area_node.clone.19+0xcc/0x164)
[<c40d319c>] (__get_vm_area_node.clone.19+0x0/0x164) from [<c40d3bec>] (__vmalloc_node_range+0x5c/0x1d0)
[<c40d3b90>] (__vmalloc_node_range+0x0/0x1d0) from [<c40d3da0>] (__vmalloc_node+0x40/0x4c)
r8:c400de84 r7:00000080 r6:00b7a080 r5:0000465c r4:0000465c
[<c40d3d60>] (__vmalloc_node+0x0/0x4c) from [<c40d3ee4>] (vmalloc+0x30/0x3c)
[<c40d3eb4>] (vmalloc+0x0/0x3c) from [<c406de40>] (sys_init_module+0x5c/0x1878)
[<c406dde4>] (sys_init_module+0x0/0x1878) from [<c400dd00>] (ret_fast_syscall+0x0/0x30)
acpower_isr() [105]
poe_isr() [136]
INFO: rcu_sched detected stall on CPU 0 (t=204330 jiffies)
Antwort1
Aus dem Stapel können wir erkennen, dass diese CPU in einem Spinlock feststeckt, während sie versucht, Speicher zuzuweisen ( _raw_spin_lockinnerhalb von alloc_vmap_area). Interessanter ist, dass dies anscheinend beim Versuch passiert, ein neues Modul zu laden ( sys_init_module), das lediglich den Initialisierungscode des Moduls aufruft (durch einen Zeigersprung, weshalb Sie es nicht im Stapelüberwachungsprotokoll sehen).
Dies bedeutet, dass es sich höchstwahrscheinlich entweder um einen Kernelfehler handelt, der beim Laden dieses Moduls auftritt, oder um einen Fehler im Modul selbst (wahrscheinlich letzteres, da es mit vmallocziemlicher Sicherheit vom zugrunde liegenden Modul aufgerufen wird).
Sie müssen das Modul finden, das für diesen Fehler verantwortlich ist. Sehen Sie sich die Prozesse an, die im Zustand D hängen bleiben, wenn dies geschieht, oder verwenden Sie etwas wie eBPF, um neue Aufrufe der Modulinitialisierung zu verfolgen.