ubuntu – 如何修复“BUG：软锁定 – CPU#0卡在17163091968s”？

更新：我更新了消息的标题,因为我最近看到更多这些问题的确切时间量为17163091968.这应该有助于调查症状的人找到这个页面.请参阅下面的(自我)接受的答案.

我在VMware vSphere数据中心有一堆64位Ubuntu 10.04 LTS VM.已安装VMware工具(vSphere Client显示“正常”).

我已经看到一些VM在syslog中出现以下错误而挂了几次.从vSphere检查情况时,控制台是黑色的,并且“重新启动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).
>我也看到任务……被阻止超过120秒的问题 – 也许他们可能有关系？
> vSphere客户端不显示VM的警报或迁移任务.

感谢所有评论者.我想我找到了答案.至少在Ubuntu的内核版本2.6.32-30-server中似乎存在计时错误.有时(？)的bug会在达到200 … 210天的正常运行时间时杀死机器.实际上,在达到限制后不会立即停止,但是由某些操作触发(在我的情况下：apt-get install …).

注意：200天约为2 ^ 32倍1/250秒,250是CONfig_HZ的默认值.

目前,我还没有找到有关问题是否已在更新的内核中修复的数据.我知道它似乎不会影响旧内核(2.6.32-26-server).根据所有这些信息,我认为如果它还没有修复,可以通过以下方式避免：

>每隔190天启动机器(无论如何都是内核升级的好主意)
>将CONfig_HZ调整为100,因此每497天调整一次.但是,这可能会产生非常意外的副作用,尤其是在虚拟环境中.它并没有解决问题.

这是Ubuntu的a bug report.