「バグ：ソフトロックアップ-17163091968でCPU＃0がスタックする」の修正方法

更新：メッセージのタイトルを更新しました17163091968s。これは、この正確な時間量でこれらの問題を最近見たためです。これは、このページを見つけるために症状を調査する人々に役立つはずです。以下の（自己）受け入れられた答えを参照してください。

VMware vSphereデータセンターに多数の64ビットUbuntu 10.04 LTS VMがあります。VMwareツールがインストールされています（vSphere Clientで「OK」と表示されます）。

いくつかのVMが数回ハングし、syslogに次のエラーが表示されることがあります。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のアラートや移行タスクは表示されません。

すべてのコメント者に感謝します。答えを見つけたと思う。少なくとも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のバグレポートを次に示します。

これは実際には、次のカーネルコミットによって修正されたカーネルバグです。

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

次のタイトルでLKMLを検索できます（3つ以上のリンクを投稿できません）：[安定版] 2.6.32.21-稼働時間に関連するクラッシュ？

そして、これはカーネルの修正をもたらすLP＃のバグです。

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

lucid-updatesで最新のカーネルにアップグレードすると、この問題は永久に修正されるはずです。

HTH

仮想化ホストでいくつかの省電力機能（「グリーンIT」）が有効になっており、未使用のコアを低電力/スリープモードにすると、そのコアを使用するVMに興味深い混乱が生じる可能性がありますか？これは主にHyperV環境で問題になると聞いたことがありますが、調べる必要があるかもしれません。

他の誰かがこれを見つけた場合、カーネルのアップグレードで同様の問題が修正されました。起動時にこれらのCPUソフトロックエラーをスローするSAS3コントローラーを介してシステムに接続されたJBODがありました。

Ubuntu 14.04.2カーネルバージョン3.16.0-30があり、「apt -y upgrade」を実行するとカーネル3.16.0-49になり、問題は解決しました。