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

Question

更新：我更新了消息的标题，因为我最近在17163091968s. 这应该可以帮助人们调查症状以找到此页面。请参阅下面我（自我）接受的答案。

---

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

我已经看到一些 VM 挂起几次，并在 syslog 中出现以下错误。从 vSphere 检查情况时，控制台是黑色的，并且“Reboot guest”命令没有执行任何操作，因此我不得不重新启动 VM。

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 客户端不显示 VM 的警报或迁移任务。

Answer 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的错误报告。

Answer 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 中的最新内核应该可以彻底解决这个问题。

HTH