如何解决“错误：软锁定-CPU＃0卡住了17163091968s”的问题？

14

更新：我更新了邮件的标题，因为在此精确时间范围内，我最近看到了更多这些问题17163091968s。这应该可以帮助调查症状的人们找到此页面。请参阅下面我的（自我）接受的答案。

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

我已经看到几次VM挂起，并在syslog中出现以下错误。从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 Client对虚拟机不显示任何警报或迁移任务。

— Tuomassalo
source

也许错误的计时？你可以玩clocksource。CPU的C状态也是一个很好的猜测。

— SaveTheRbtz 2011年

12

感谢所有评论者。我想我找到了答案。至少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 的错误报告。

— Tuomassalo
source

很好的发现-不知道它是否会滴入Debian

— Thinice 2011年

出于好奇：您是使用NTP还是通过vmware进行时间同步？这听起来像是恒定的时移之类的。..syslog中应该记录有时移的条目。

— pauska 2011年

我刚刚看到了一些与debian 2.6.32-5-amd64内核相关的东西，其中显示了两个软锁定，它们的执行表现“奇怪”

— James

5

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

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

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

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

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

在清醒更新中升级到最新内核应该可以永久解决此问题。

高温超导

— 路易
source

2

虚拟主机是否具有启用的某些节能功能（“绿色IT”），可以将未使用的内核发送到低功耗/睡眠模式，从而导致使用该内核的VM发生有趣的中断？我听说这曾经是主要在HyperV环境中出现的问题，但可能需要研究。

— 达夫
source

1

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

我有Ubuntu 14.04.2内核版本3.16.0-30，然后执行“ apt -y升级”使我最终进入了内核3.16.0-49，这解决了问题。

— Locane
source