web-dev-qa-db-ja.com

バグ：ソフトロックアップ-CPU番号がx秒間スタック

しつこい_"BUG: soft lockup - CPU#<n> stuck for <dt>s!"_に関するバグ報告と質問（stackexchangeなど）をいくつか見ました。これまでのところ、何をするか試すかについての手がかりを見つけていません（むしろ、私が見つけて追跡した手がかりは止まりませんでしたこれが起こることから）。私はこれについてさらに心配しています：

  1. これらのイベントの頻度は最近ゆっくりと増加しているようです（月あたり700以上）。
  2. _yum update_と再起動でしばらく遅くなりましたが、いくつかのロックアップが再び発生し始めました。
  3. いくつかのプロセス（ホスト全体ではないにしても、それを伝えるのは難しい）。確かに、すべてのインタラクティブシェルを含め、それが発生した場合、しばらくの間フリーズします。
  4. それが関連しているかどうかはわかりませんが、ntpdに関連する多くのログ/メッセージが時計を更新できないことに気づきます。

以下は、$(grep 'soft lockup' /var/log/messages*)の抜粋です。

_Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [Java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]
_

これはランダムなプロセスで発生し、その仮想ホストの16個の「コア」にかなりうまく分散されているようです。

ホストはAWS EC2「cc1.4xlarge」インスタンスであり、AMIは「EC2 CentOS 5.5 GPU HVM AMI（ドライバー260.19.29）（AMI-42a2532b）」という名前です。 Xenで仮想化されているようです。

_cat /etc/redhat-release_はCentOS release 5.9 (Final)を生成します。 _'free'_は21GのRAMを報告します。

dmesgの頭は：

_Linux version 2.6.18-348.3.1.el5 ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)
_

以下は、最近のこれらの「ソフトロックアップ」の累積数を示しています（レッドラインは、最後の_yum update_の後にrebootを実行したときです）： cumul count of soft lockups。

以下は、期間のヒストグラムを示しています（ホストがスタックしている時間）。 duration histogram。

centosxenamazon-ec2
34
Pierre D

Xen 4.2と3.6および3.8カーネル（AlpineLinux）でもこの問題が発生します。

私はググってみて、clocksource = jiffiesをカーネルに追加して修正しました。 jiffiesの代わりに "pit"を試すこともできます。

BIOSでC状態を無効にする のレポートもあります。

11
Franz Bettag

Thinkpad T520でも同じ問題が発生しました。しかし、カーネルをハックする代わりに、もっと簡単なことをしました。まず、Centos7を使用していますが、インストールしたベースシステムはすべて正常に動作しました。その後、GNOME GUIを後で追加しました。このとき、上記の問題が発生し始めました。多くのメーカーがWindowsインストールをセットアップしていることに気づきました。グラフィックカードは通常Win7（NVIDIA OPTIMUS）用に設定されています。統合グラフィックモードにリセットすると、ハング/エラーは発生しなくなります。どうやってするの？ Thinkpadを再起動し、F1または青いthinkvantageボタンを押してBIOSに入ります。グラフィックスに移動して、統合グラフィックスを選択し、F10を押して保存して終了します。このカードには3つの設定があります：統合、ディスクリート、NVIDIA OPTIMUS（Win7のみ？）これが誰かの時間を節約することを願っていますか？

2
Rod