如何修复"BUG:软锁- CPU#0卡住17163091968 s“？

Question

UPDATE:我更新了消息的标题，因为我最近看到了更多这样的问题，这正是17163091968s的确切时间。这应该有助于人们调查症状，找到这一页。见下面我(自我)接受的答案。

我有一堆64位Ubuntu10.04LTSVM在一个VMware vSphere数据中心。安装了VMware工具(vSphere客户端说"OK")。

我在syslog中见过一些VM的挂起，其中有以下错误。当从vSphere检查情况时，控制台是黑色的，而“重新引导来宾”命令没有做任何事情，所以我不得不为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服务器中似乎存在一个计时错误。窃听器有时(?)当机器的正常运行时间达到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# bug，它带来了内核修复：

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

在透明更新中升级到最新内核应该可以永久解决这个问题。

HTH

Answer 3

虚拟化主机是否具有一些节能特性(“绿色IT")，可以将未使用的内核发送到低功耗/休眠模式，从而导致使用该核心的VM出现有趣的中断？我听说这以前主要是HyperV环境中的一个问题，但它可能是值得研究的问题。