私はこれに関するいくつかの迷惑なバグレポートと問題（Stackexchangeなど）を見ました"BUG: soft lockup - CPU#<n> stuck for <dt>s!"。今まで何の手がかりも見つかりませんでした。試してみてください。（逆に、私が見つけた手がかりは、このようなことが起こるのを止めませんでした。）私がもっと心配する理由は次のとおりです。
- 最近では、こうした事件の発生頻度が徐々に増加しているように見え（月700件以上）、
yum update再起動するとしばらくは遅くなりますが、いくつかのロックが再び発生し始めることがわかります。- これが発生すると、すべての対話型シェルを含む複数のプロセス（ホスト全体ではなくてもわかりにくい）がしばらく停止します。
- 関係があるかどうかはわかりませんが、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個の「コア」にかなり均等に分散しているようです。
ホストは、AMI名が「EC2 CentOS 5.5 GPU HVM AMI（ドライバ260.19.29）（ami-42a2532b）」のAWS EC2「cc1.4xlarge」インスタンスです。 Xenを使って仮想化したようです。
cat /etc/redhat-releaseCentOS release 5.9 (Final)報告されたメモリは21G'free'です。
ヘッダーは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）
。
以下は、期間（ホストが停滞した期間）のヒストグラムを示しています
。
答え1
また、3.6および3.8カーネルがインストールされているXen 4.2（AlpineLinux）でもこの問題が発生しました。
私はそれを検索し、私のカーネルにclocksource = jiffiesを追加して問題を解決しました。 jiffiesに加えて、「pits」を試してみることもできます。
という報告もある。BIOSでC状態を無効にする。
答え2
Thinkpad T520にも同じ問題があります。しかし、カーネルをハッキングするのではなく、より簡単なことをしました。まずCentos7を使用していますが、私がインストールした基本システムではすべてがうまくいきます。後でGNOME GUIを追加しましたが、それから上記の問題が発生し始めました。多くのメーカーは、Windowsをインストールするための設定を持っていることがわかりました。グラフィックカードは通常Win7（NVIDIA OPTIMUS）に設定されており、統合グラフィックモードにリセットされたため、停止/エラーは発生しません。どうすればいいですか？ Thinkpadを再起動し、F1または青のThinkvantageボタンを押してBIOSに入ります。グラフィックに移動して統合グラフィックを選択し、F10を押して保存して終了します。カードは、統合型、個別型、NVIDIA OPTIMUS（Win7のみ？）の3つの設定で提供されます。時間を節約したいですか？