[Eisfair] Absturz, L?==?utf-8?Q?og-Datei vor dem Absturz

[Christoph Schulz]

Hallo!

Marcus Roeckrath schrieb am Sa, 13 Februar 2016 12:31
> Google mit "detected stall on cpu" gefüttert liefert viele Treffer
> mit oft
> gänzlich verschiedenen Ursachen - auch im Zusammenhang mit
> Virtualisierung.
> [...]
> Da wurde das dann abgeschaltet, obs das die Ursache behebt?
> 
> echo 1 > /sys/module/rcutree/parameters/rcu_cpu_stall_suppress


Don't shoot the messenger ;-)

Ein "RCU Stall" ist eine Situation, in der irgendein Teil vom Kernel
länger in einer bestimmten Art von kritischem Abschnitt "hängt" als
dem Kernel lieb ist. Laut Meldung sind 15000 Jiffies vergangen; ich
kenne die eisfair-Kernel-Konfiguration nicht, aber ich tippe auf einen
"HZ=250"-Kernel, so dass dies einer Minute (60 Sekunden = 15000 Jiffies
/ 250 HZ) entspricht. Irgendein Kernel-Treiber bzw. Subsystem hing also
über eine Minute im Kernel-Modus.

Mit

echo 1 > /sys/module/rcutree/parameters/rcu_cpu_stall_suppress

deaktivierst du lediglich die Erkennung dieser (und Benachrichtigung
über diese) Situation. Es hilft nicht im Geringsten, das zugrunde
liegende Problem zu lösen. Da ich den Rest des Stacktraces nach

Feb 12 13:27:36 myeis kernel: INFO: rcu_sched detected stall on CPU 1
(t=15000 jiffies)
[...]
Feb 12 13:27:36 myeis kernel: [__rcu_pending+0x64/0x28f]
__rcu_pending+0x64/0x28f

nicht in dem Beitrag sehen kann, kann ich auch nicht sehen, welcher
Treiber oder welches Subsystem diese RCU-Stall-Situation ausgelöst hat.
Sprich: Solange ich den Rest nicht sehe, kann zumindest ich dir auch
nicht helfen. Da im Linux-Kernel aus Performance-Gründen immer mehr
Code auf die Nutzung des RCU-Mechanismus umgestellt wird, kann das
Problem praktisch überall sein (Netzwerk-Treiber, VFS, ...).


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]