BUG：软锁定-CPU＃卡住了x秒

33

我已经看到了一些有关reports的错误报告和问题（在stackexchange和其他地方）"BUG: soft lockup - CPU#<n> stuck for <dt>s!"。到目前为止，我还没有找到有关做什么或尝试的任何线索（相反，我找到并遵循的线索并未阻止这种情况的发生）。我对此进一步担心，因为：

这些事件的频率最近似乎一直在缓慢上升（每月超过700个），
yum update 重新启动使它变慢了一段时间，但是我看到一些锁定开始再次发生，
几个进程（如果不是整个主机，很难说），当然包括我所有的交互式shell发生时都会冻结一段时间。
我不确定是否相关，但是我看到许多与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 (mockbuild@builder10.centos.org) (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）软锁定的累计计数。

下面显示了持续时间的柱状图（主机多长时间卡住）持续时间直方图。

centos xen amazon-ec2

— 皮埃尔·D
source

1

大量的可能原因。我在KVM实例中有一次。原因是主机网络驱动程序（realtek），它将在虚拟化无法预期的高网络负载上执行某些操作，并且会导致CPU卡在VM中。因此，基本上，网络驱动程序中的错误会触发其他错误。解决方案是切换到其他内核版本（在主机上），该版本不会触发该特定行为。

— 弗罗斯特斯

1

我们收到此错误消息，因为某些VM配置的vcpus比新服务器中的物理CPU多，所以我们将Xen主机移到了。

— 约尔格路德维希

11

在Xen 4.2、3.6和3.8内核（AlpineLinux）上，我也有此问题。

我用谷歌搜索，通过在我的内核中添加clocksource = jiffies来修复它。除了轻松，您也可以尝试“进站”。

也有在BIOS中禁用C状态的报告。

— 弗朗兹·贝塔格（Franz Bettag）
source

4

这些内核参数有什么作用？

— Burhan Ali

2

Clocksource对我来说似乎很明显，而c状态是CPU的电源状态。

— Franz Bettag

+1。禁用c状态对我有用。

— 安德鲁·恩斯利

2

我的Thinkpad T520遇到相同的问题。但是，我没有做些麻烦，而是做了一些更简单的事情。首先，我使用Centos7，我安装的基本系统运行正常。然后，我在稍后开始遇到上述问题时添加了GNOME GUI。我注意到许多制造商都为Windows安装进行了设置。显卡通常是针对Win7（NVIDIA OPTIMUS）设置的，我将其重置为集成显卡模式，没有其他挂起/错误。怎么做？重新启动Thinkpad，按F1或蓝色thinkvantage按钮进入BIOS。转到图形，选择集成图形，然后按F10保存并退出。该卡有3种设置：Integrated，Discrete和NVIDIA OPTIMUS（仅Win7？）希望这可以节省一些时间吗？

— 竿
source

像大多数其他东西一样，叹气是分开的。返回到带有Office和其他废话的the肿的桌面版本：(

— killjoy