O que pode causar um único aviso "rcu_sched detected stall on CPU" no syslog?

Question

Ambiente: Linux [hostname] 3.2.0-4-amd64 # 1 SMP Debian 3.2.96-2 x86_64 GNU / Linux Hardware: Processador AMD Opteron (tm) 6344, 6x2MiB L2, 2x8MiB L3, 6 núcleos ht (12 núcleos lógicos)

Hoje recebi um aviso no syslog:

Feb 28 09:58:53 amalthea kernel: [4367033.060016] INFO: rcu_bh detected stall on CPU 10 (t=0 jiffies)
Feb 28 09:58:53 amalthea kernel: [4367033.060018] sending NMI to all CPUs:

Seguido por um despejo do estado da CPU. Parece não haver nada "ruim" que leve a essa situação no log.

O servidor ainda está em execução, não há processos (aparentes) paralisados, etc., e o aviso não se repetiu em uma hora ou mais desde que aconteceu.

Eu examinei algumas informações sobre o detector de estocagem da RCU (é muito técnico para me para realmente entender), e eu posso ver isso:

1. Minha CPU foi interrompida por t=0 jiffies
2. Não há CPU "detectada por"

Há uma observação nesse documento que sugere que isso pode ser um falso positivo:

["Stall ended before state dump start"] is rare, but does happen from time to time in real life. It is also possible for a zero-jiffy stall to be flagged in this case, depending on how the stall warning and the grace-period initialization happen to interact. Please note that it is not possible to entirely eliminate this sort of false positive without resorting to things like stop_machine(), which is overkill for this sort of problem.

(ênfase minha)

Eu não recebi uma mensagem "Stall ended before state dump start", mas também não consegui obter muito mais em termos de diagnósticos além da quantidade de despejos de CPU que vieram após as duas linhas de log mostradas acima.

Eu posso postar mais informações do CPU-dump se isso for útil. Nada saltou para mim, embora eu não seja especialista.

O que poderia ter causado essa situação? É provável que seja um falso-positivo baseado apenas no ponto de dados t=0 jiffies , além de nenhuma outra informação de diagnóstico impressa no registro?

(Observe que essa questão é diferente de rcu_sched detectou paralisação na CPU , o que parece ter indicado um "problema real".)

    

Answer 1

Provavelmente, isso é causado por uma das três coisas:

1. É muito difícil acionar o bug do kernel. Eu não acho que isso seja provável, já que as coisas de RCU são tão essenciais para o kernel que quaisquer erros provavelmente serão atingidos por quase todos.
2. RAM ruim. Corrupção de memória causada por um módulo de memória ruim pode facilmente causar coisas bizarras como essa.
3. Um erro de memória temporária causado por algo diferente da própria memória. Semelhante ao anterior, mas não é provável que apareça novamente. Esse é o tipo de coisa que a memória ECC tenta proteger (mas não pode ser completamente porque é totalmente possível que algo dê errado na lógica do ECC).

A menos que isso aconteça novamente, você provavelmente pode assumir que é o caso 3 e seguir em frente. Se isso acontecer novamente, procure semelhanças nas mensagens do kernel ao redor e / ou verifique sua RAM.