☰

如何修复“BUG：软锁定 - CPU#0 卡住 17163091968 秒”？

tag-icon • tag-icon ubuntu central-processing-unit vmware-vsphere kernel
如何修复“BUG：软锁定 - CPU#0 卡住 17163091968 秒”？

更新：我更新了消息的标题，因为我最近看到了更多这样的问题，这些问题的时间恰好是这个数额17163091968s。这应该有助于调查症状的人找到此页面。请参阅下面我（自我）接受的答案。

我在 VMware vSphere 数据中心有一堆 64 位 Ubuntu 10.04 LTS VM。VMware 工具已安装（vSphere Client 显示“OK”）。

我曾多次看到一些虚拟机挂起，并在系统日志中显示以下错误。从 vSphere 检查情况时，控制台一片漆黑，并且“重新启动客户机”命令没有任何作用，因此我不得不关闭虚拟机并重新开机。

Dec  1 11:44:15 s0 kernel: [18446744060.007150] BUG: soft lockup - CPU#0 stuck for 17163091988s! [jed:26674]
Dec  1 11:44:15 s0 kernel: [18446744060.026854] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026899] CPU 0:
Dec  1 11:44:15 s0 kernel: [18446744060.026900] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026920] Pid: 26674, comm: jed Not tainted 2.6.32-30-server #59-Ubuntu VMware Virtual Platform
Dec  1 11:44:15 s0 kernel: [18446744060.026922] RIP: 0033:[<00007f92e03d2ce6>]  [<00007f92e03d2ce6>] 0x7f92e03d2ce6
Dec  1 11:44:15 s0 kernel: [18446744060.026930] RSP: 002b:00007fff6069b770  EFLAGS: 00000202
Dec  1 11:44:15 s0 kernel: [18446744060.026932] RAX: 00007f92e27e7e10 RBX: 00007f92e06d5e40 RCX: 0000000000020000
Dec  1 11:44:15 s0 kernel: [18446744060.026933] RDX: 00007f92e27e7e10 RSI: 0000000000020209 RDI: 0000000000000002
Dec  1 11:44:15 s0 kernel: [18446744060.026934] RBP: ffffffff81013cae R08: 0000000000000001 R09: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026935] R10: 00007f92e06d6398 R11: 0000000000000870 R12: 00000000000000c0
Dec  1 11:44:15 s0 kernel: [18446744060.026937] R13: 00007f92e299dca0 R14: 0000000000000020 R15: 00007f92e06d5e40
Dec  1 11:44:15 s0 kernel: [18446744060.026939] FS:  00007f92e105b700(0000) GS:ffff880009c00000(0000) knlGS:0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec  1 11:44:15 s0 kernel: [18446744060.026941] CR2: 00007ff12ea15000 CR3: 0000000267067000 CR4: 00000000000006f0
Dec  1 11:44:15 s0 kernel: [18446744060.026968] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026989] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec  1 11:44:15 s0 kernel: [18446744060.026991] Call Trace:

（没有任何痕迹——这是最后一句。）

我似乎不再有其他错误，但我很确定上面提到的过程（jed）在其他转储中是不同的。

  • 什么可能导致这个问题？

  • 如何防止这种情况发生？

一些额外的信息：

  • 这个值17163091988有点（双关语）可疑——它是1111111111000000000000000000010100二进制的。也许错误是想说20秒（10100二进制）？

  • 我不确定最新的 10.04 内核（2.6.32-35）是否存在该问题。

  • 我也看到了task ... blocked for more than 120 seconds一些问题——也许它们有关联？

  • vSphere 客户端未显示该虚拟机的警报或迁移任务。

答案1

感谢所有评论者。我想我找到了答案。至少在 Ubuntu 的内核版本 2.6.32-30-server 中似乎有一个计时错误。这个错误有时 (?) 会在机器达到大约 200..210 天的正常运行时间时杀死它们。实际上，停止并不是在达到限制后立即发生的，而是由某些操作触发的（在我的情况下：）apt-get install ...。

注意：200 天约为 2^32 乘以 1/250 秒，250 是 CONFIG_HZ 的默认值。

目前，我还没有找到有关该问题是否已在较新的内核中得到修复的数据。但我知道它似乎不会影响较旧的内核（2.6.32-26-server）。根据所有这些信息，我推测如果尚未修复，可以通过以下方式避免：

  • 每 190 天启动一次机器（对于内核升级来说，这是一个好主意）
  • 将 CONFIG_HZ 调整为 100，这样每 497 天就会发生一次。然而，这可能会产生意想不到的副作用，尤其是在虚拟环境中。而且它不会解决问题。

以下是错误报告适用于 Ubuntu。

答案2

这实际上是一个内核错误，已通过以下内核提交修复：

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9

您可以在 LKML 中搜索以下标题（不能发布超过 2 个链接）：[稳定] 2.6.32.21 - 与正常运行时间相关的崩溃？

这是带来内核修复的 LP# 错误：

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317

升级到 lucid-updates 中的最新内核应该可以彻底解决这个问题。

高血压

答案3

虚拟化主机是否启用了一些节能功能（“绿色 IT”），这些功能可能会使未使用的内核进入低功耗/睡眠模式，从而导致使用该内核的虚拟机出现有趣的中断？我听说这曾经主要是 HyperV 环境中的一个问题，但这可能是值得研究的问题。

答案4

万一其他人也发现了这个问题，内核升级为我解决了类似的问题。我有一个 JBOD，它通过 SAS3 控制器连接到系统，在启动时抛出了这些 CPU Softlock 错误。

我的 Ubuntu 14.04.2 内核版本是 3.16.0-30，执行“apt -y upgrade”后我得到了内核 3.16.0-49，这就解决了问题。

相关内容