☰

什么可能导致系统日志中出现单个“rcu_sched 检测到 CPU 停顿”警告？

tag-icon • tag-icon linux-kernel
什么可能导致系统日志中出现单个“rcu_sched 检测到 CPU 停顿”警告？

环境：Linux [主机名] 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux 硬件：AMD Opteron(tm) 处理器 6344、6x2MiB L2、2x8MiB L3、6 核 ht（12 个逻辑核心） ）

今天我在系统日志中收到警告：

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:

接下来是 CPU 状态转储。日志中似乎没有什么“坏”导致这种情况。

服务器仍在运行，没有（明显）停滞的进程等，并且警告在发生后的一个小时左右没有重复出现。

我浏览过一些有关 RCU 失速检测器的信息（对我来说太技术性了真的明白），我可以看到：

  1. 我的 CPU 停滞了t=0 jiffies
  2. CPU没有“检测到”

该文件中有一条注释向我表明这可能是误报：

[“状态转储开始前失速结束”]很少见，但在现实生活中确实时有发生。也是可能会标记零快速失速在这种情况下，取决于停顿警告和宽限期初始化如何相互作用。请注意，如果不求助于 stop_machine() 之类的方法，就不可能完全消除这种误报，这对于此类问题来说是多余的。

（强调我的）

我没有收到“状态转储开始前停止”消息，但除了上面显示的两条日志行之后出现的大量 CPU 转储之外，我似乎在诊断方面也没有得到太多其他信息。

如果有帮助的话，我可以发布来自 CPU 转储的更多信息。尽管我不是专家，但我并没有发现什么。

什么可能导致这种情况？是否可能仅基于数据点而误报t=0 jiffies，并且没有打印到日志中的其他诊断信息？

（请注意，这个问题不同于rcu_sched 检测到 CPU 停顿，这似乎表明了一个“真正的问题”。）

答案1

这很可能是由以下三种原因之一引起的：

  1. 一个很难触发的内核错误。但我认为这不太可能，因为 RCU 内容对于内核来说是如此核心，以至于几乎每个人都可能会遇到其中的任何错误。
  2. 内存不好。由坏内存模块引起的内存损坏很容易导致类似这样奇怪的事情发生。
  3. 由内存本身以外的原因引起的暂时性内存错误。与上面类似，但不太可能再次出现。这是 ECC 内存试图防止的类型（但不能完全防止，因为 ECC 逻辑中完全有可能出现问题）。

除非它再次发生，否则您可能会假设这是情况 3，然后继续前进。如果再次发生这种情况，请在周围的内核消息中查找相似之处和/或检查您的 RAM。

答案2

我在 NVidia Jetson 板上遇到了这种错误（CPU 停顿）。

在与 NVidia 交谈并研究我们的 Jetsons 后，我发现我们的一些卡仅通过蓝牙设备每秒就会收到 80,000 个中断。禁用该设备对应的模块可以防止 CPU 停止运行。

要了解您收到了多少个中断，您可以查看/proc/interrupts.请注意，我的停顿会发生，因为 RJ45 也被使用，并且有如此多的中断，我会遇到 Linux 内核死锁（请注意，这可能不是内核本身，而是处理蓝牙和 RJ45 的驱动程序）。

这是一个示例，我们看到几个函数引用“net”或“ip”。我们还看到它el1_irq告诉我们正在处理 IRQ。

因此，根据 Austin 的列表，我遇到了 (1) 中定义的问题。

Feb  1 08:53:16 ve5 kernel: [ 1459.074481] INFO: rcu_preempt self-detected stall on CPU
Feb  1 08:53:16 ve5 kernel: [ 1459.074646]      0-...: (8 GPs behind) idle=ea9/140000000000001/0 softirq=32059/32059 fqs=2112 
Feb  1 08:53:16 ve5 kernel: [ 1459.074794]       (t=5250 jiffies g=10249 c=10248 q=48)
Feb  1 08:53:16 ve5 kernel: [ 1459.074906] Task dump for CPU 0:
Feb  1 08:53:16 ve5 kernel: [ 1459.074926] ksoftirqd/0     R  running task        0     3      2 0x00000002
Feb  1 08:53:16 ve5 kernel: [ 1459.074943] Call trace:
Feb  1 08:53:16 ve5 kernel: [ 1459.074963] [<ffffff800808bdb8>] dump_backtrace+0x0/0x198
Feb  1 08:53:16 ve5 kernel: [ 1459.074972] [<ffffff800808c37c>] show_stack+0x24/0x30
Feb  1 08:53:16 ve5 kernel: [ 1459.074983] [<ffffff80080ecf70>] sched_show_task+0xf8/0x148
Feb  1 08:53:16 ve5 kernel: [ 1459.074991] [<ffffff80080efc70>] dump_cpu_task+0x48/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075001] [<ffffff80081c1acc>] rcu_dump_cpu_stacks+0xb8/0xec
Feb  1 08:53:16 ve5 kernel: [ 1459.075012] [<ffffff8008132450>] rcu_check_callbacks+0x728/0xa48
Feb  1 08:53:16 ve5 kernel: [ 1459.075020] [<ffffff8008138cac>] update_process_times+0x34/0x60
Feb  1 08:53:16 ve5 kernel: [ 1459.075030] [<ffffff800814a218>] tick_sched_handle.isra.5+0x38/0x70
Feb  1 08:53:16 ve5 kernel: [ 1459.075037] [<ffffff800814a29c>] tick_sched_timer+0x4c/0x90
Feb  1 08:53:16 ve5 kernel: [ 1459.075044] [<ffffff80081399e0>] __hrtimer_run_queues+0xd8/0x360
Feb  1 08:53:16 ve5 kernel: [ 1459.075051] [<ffffff800813a330>] hrtimer_interrupt+0xa8/0x1e0
Feb  1 08:53:16 ve5 kernel: [ 1459.075061] [<ffffff8008bffe98>] arch_timer_handler_phys+0x38/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075071] [<ffffff8008126f10>] handle_percpu_devid_irq+0x90/0x2b0
Feb  1 08:53:16 ve5 kernel: [ 1459.075078] [<ffffff80081214f4>] generic_handle_irq+0x34/0x50
Feb  1 08:53:16 ve5 kernel: [ 1459.075085] [<ffffff8008121bd8>] __handle_domain_irq+0x68/0xc0
Feb  1 08:53:16 ve5 kernel: [ 1459.075092] [<ffffff8008080d44>] gic_handle_irq+0x5c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075099] [<ffffff8008082c28>] el1_irq+0xe8/0x194
Feb  1 08:53:16 ve5 kernel: [ 1459.075108] [<ffffff8008231de4>] kmem_cache_alloc+0x114/0x2c0
Feb  1 08:53:16 ve5 kernel: [ 1459.075118] [<ffffff8008db94a4>] dst_alloc+0x6c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075127] [<ffffff8008df6a2c>] rt_dst_alloc+0x74/0xe8
Feb  1 08:53:16 ve5 kernel: [ 1459.075134] [<ffffff8008df7ca0>] ip_route_input_noref+0x3c0/0x8f8
Feb  1 08:53:16 ve5 kernel: [ 1459.075144] [<ffffff8008e34a00>] arp_process+0x3e8/0x708
Feb  1 08:53:16 ve5 kernel: [ 1459.075152] [<ffffff8008e34e70>] arp_rcv+0x118/0x1a8
Feb  1 08:53:16 ve5 kernel: [ 1459.075161] [<ffffff8008da9c20>] __netif_receive_skb_core+0x3b8/0xad8
Feb  1 08:53:16 ve5 kernel: [ 1459.075169] [<ffffff8008dad010>] __netif_receive_skb+0x28/0x78
Feb  1 08:53:16 ve5 kernel: [ 1459.075175] [<ffffff8008dad08c>] netif_receive_skb_internal+0x2c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075182] [<ffffff8008dadcb4>] napi_gro_receive+0x15c/0x188
Feb  1 08:53:16 ve5 kernel: [ 1459.075192] [<ffffff800894dd90>] eqos_napi_poll_rx+0x358/0x430
Feb  1 08:53:16 ve5 kernel: [ 1459.075199] [<ffffff8008daf2e4>] net_rx_action+0xf4/0x358
Feb  1 08:53:16 ve5 kernel: [ 1459.075206] [<ffffff8008081054>] __do_softirq+0x13c/0x3b0
Feb  1 08:53:16 ve5 kernel: [ 1459.075215] [<ffffff80080baf38>] run_ksoftirqd+0x48/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075225] [<ffffff80080e07c8>] smpboot_thread_fn+0x160/0x248
Feb  1 08:53:16 ve5 kernel: [ 1459.075232] [<ffffff80080dbe64>] kthread+0xec/0xf0
Feb  1 08:53:16 ve5 kernel: [ 1459.075239] [<ffffff80080838a0>] ret_from_fork+0x10/0x30

相关内容