BUG: Soft Lockup - CPU # steckt für x Sekunden fest

Ich habe ein paar Fehlerberichte und Fragen (zum Austausch von Stapeln und anderswo) bezüglich einer Nörgelei gesehen "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Bisher habe ich keine Hinweise gefunden, was zu tun oder zu versuchen ist (die Hinweise, die ich gefunden habe und denen ich gefolgt bin, haben dies jedoch nicht verhindert). Ich bin darüber weiter besorgt, weil:

1. Die Häufigkeit dieser Ereignisse scheint in letzter Zeit langsam zugenommen zu haben (über 700 pro Monat).
2. yum update und Neustart verlangsamte es ein bisschen für eine Weile, aber ich habe gesehen, einige Abstürze wieder zu passieren beginnen,
3. Mehrere Prozesse (wenn nicht der gesamte Host, ist es schwer zu sagen), einschließlich aller meiner interaktiven Shells, werden für eine gewisse Zeit eingefroren, wenn dies geschieht.
4. Ich bin nicht sicher, ob es damit zusammenhängt, aber ich sehe viele Logs / Meldungen, die damit zusammenhängen, dass ntpd die Uhr nicht aktualisieren kann.

Das Folgende ist ein Auszug aus $(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]

Dies geschieht durch zufällige Prozesse und scheint ziemlich gut auf die 16 "Kerne" dieses virtuellen Hosts verteilt zu sein.

Der Host ist eine AWS EC2 "cc1.4xlarge" -Instanz mit einer AMI mit dem Namen "EC2 CentOS 5.5 GPU HVM AMI (Treiber 260.19.29) (ami-42a2532b)". Es scheint mit Xen virtualisiert zu sein.

cat /etc/redhat-releaseAusbeuten CentOS release 5.9 (Final). 'free'meldet 21G RAM.

Der Leiter dmesgist:

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)

Die folgende zeigt eine kumulative Zählung dieses „weichen Hänger“ während der letzten Zeit (die Redline ist , wenn ich die letzte tat yum updategefolgt von reboot): .

Das folgende zeigt das Histogramm der Dauer (wie lange wird der Host fest): .

Ich habe auch dieses Problem auf Xen 4.2 mit 3.6 und 3.8 Kernel (AlpineLinux).

Ich habe herumgegoogelt und durch Hinzufügen von clocksource = jiffies zu meinem Kernel das Problem behoben. Anstelle von Glücksfällen können Sie auch "pit" probieren.

Es gibt auch Berichte über das Deaktivieren von C-Status im BIOS .

Ich hatte das gleiche Problem mit meinem Thinkpad T520. Aber anstatt mich in den Kernel zu hacken, habe ich etwas einfacheres gemacht. Als erstes benutze ich Centos7. Ich habe das Basissystem installiert und alles hat gut funktioniert. Ich habe GNOME GUI später hinzugefügt, als ich anfing, die oben genannten Probleme zu bekommen. Ich stelle fest, dass viele Hersteller Windows-Installationen eingerichtet haben. Die Grafikkarte ist in der Regel für Win7 eingerichtet (NVIDIA OPTIMUS). Ich habe sie auf den integrierten Grafikmodus zurückgesetzt und keine Probleme mehr. Wie es geht? Starten Sie Ihr Thinkpad neu und drücken Sie F1 oder die blaue ThinkVantage-Taste, um in das BIOS zu gelangen. Gehe zu Grafik, wähle integrierte Grafik und dann F10, um zu speichern und zu beenden. Für diese Karte gibt es 3 Einstellungen: Integriert, Diskret und NVIDIA OPTIMUS (nur Win7?) Hoffen Sie, dass dies jemandem Zeit spart?