如何修復“BUG：軟鎖定 - CPU#0 卡住 17163091968s”？

**更新：**我更新了消息的標題，因為我最近看到了更多關於這個確切時間量的問題17163091968s。這應該有助於調查症狀的人找到此頁面。請參閱下面我的（自我）接受的答案。

---

我在 VMware vSphere 數據中心有一堆 64 位 Ubuntu 10.04 LTS 虛擬機。VMware 工具已安裝（vSphere 客戶端顯示“OK”）。

我已經看到一些 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 客戶端未顯示虛擬機的警報或遷移任務。

感謝所有評論者。我想我找到了答案。至少在 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的錯誤報告。

引用自：https://serverfault.com/questions/336591