BUG: soft lockup - CPU # stuck selama x detik

33

Saya telah melihat beberapa laporan bug dan pertanyaan (di stackexchange dan di tempat lain) tentang gangguan "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Sejauh ini, saya belum menemukan petunjuk apa yang harus saya lakukan atau coba (lebih tepatnya, petunjuk yang saya temukan dan ikuti belum menghentikan hal ini terjadi). Saya lebih lanjut khawatir tentang ini karena:

  1. frekuensi peristiwa ini tampaknya perlahan meningkat akhir-akhir ini (lebih dari 700 per bulan),
  2. yum update dan reboot sedikit memperlambatnya untuk sementara waktu tetapi saya telah melihat beberapa penguncian mulai terjadi lagi,
  3. beberapa proses (jika bukan seluruh host, sulit untuk mengatakan), tentu termasuk semua shell interaktif saya dibekukan untuk beberapa waktu ketika itu terjadi,
  4. Saya tidak yakin apakah itu terkait, tetapi saya melihat banyak log / pesan yang terkait dengan ntpd tidak dapat memperbarui jam.

Berikut ini adalah kutipan dari $(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]

Ini terjadi pada proses acak, dan tampaknya didistribusikan dengan cukup baik pada 16 "core" host virtual itu.

Tuan rumah adalah turunan AWS EC2 "cc1.4xlarge", dengan AMI bernama "EC2 CentOS 5.5 GPU HVM AMI (Driver 260.19.29) (ami-42a2532b)". Tampaknya tervirtualisasi dengan Xen.

cat /etc/redhat-releasehasil panen CentOS release 5.9 (Final). 'free'melaporkan 21G RAM.

Kepala dmesgadalah:

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)

Berikut ini menunjukkan jumlah kumulatif dari "kemacetan lunak" dari waktu ke waktu baru-baru ini (redline adalah ketika saya melakukan yang terakhir yum updatediikuti dengan reboot): kumul jumlah penguncian lunak.

Menunjukkan mengikuti histogram durasi (berapa lama host terjebak): durasi histogram.

Pierre D
sumber
1
Banyak kemungkinan alasan. Saya pernah memilikinya dalam contoh KVM. Penyebabnya adalah driver jaringan host (realtek), yang akan melakukan sesuatu pada beban jaringan tinggi yang tidak diharapkan virtualisasi, dan voila Anda terjebak CPU di VMs. Jadi pada dasarnya bug di driver jaringan yang memicu bug lain di jalan. Solusi adalah beralih ke versi kernel yang berbeda (pada host) yang tidak memicu perilaku tertentu itu.
frostschutz
1
Kami mendapat pesan kesalahan ini, karena beberapa VM memiliki lebih banyak vcpus yang dikonfigurasi daripada CPU fisik di server baru, kami memindahkan host Xen kami ke.
Jörg Ludwig

Jawaban:

11

Saya juga memiliki masalah ini pada Xen 4.2 dengan 3.6 dan 3.8 Kernel (AlpineLinux).

Saya googled sekitar dan dengan menambahkan clocksource = jiffies ke kernel saya memperbaikinya. Alih-alih jiffies Anda juga bisa mencoba "lubang".

Ada juga laporan tentang menonaktifkan status-C di BIOS .

Franz Bettag
sumber
4
Apa yang dilakukan parameter kernel tersebut?
Burhan Ali
2
Clocksource tampaknya cukup jelas bagi saya dan c-state adalah power state dari CPU.
Franz Bettag
+1. Menonaktifkan status-c berfungsi untuk saya.
Andrew Ensley
2

Saya memiliki masalah yang sama dengan Thinkpad T520 saya. Tetapi alih-alih meretas kernel saya melakukan sesuatu yang lebih sederhana. Pertama saya menggunakan Centos7 saya menginstal sistem dasar semua bekerja dengan baik. Saya kemudian menambahkan GUI GNOME kemudian saat itulah saya mulai mendapatkan masalah yang disebutkan di atas. Saya perhatikan bahwa banyak produsen mengatur untuk menginstal Windows. Kartu grafis diatur biasanya untuk Win7 (NVIDIA OPTIMUS) saya meresetnya ke mode grafis terintegrasi dan tidak ada lagi menggantung / kesalahan. Bagaimana cara melakukannya? Reboot Thinkpad Anda, tekan tombol F1 atau tombol thinkvantage biru untuk masuk ke BIOS. Pergi ke grafik pilih grafik terintegrasi lalu F10 untuk menyimpan dan keluar. Ada 3 pengaturan untuk kartu ini: Integrated, Discrete dan NVIDIA OPTIMUS (hanya Win7?) Semoga ini menghemat waktu seseorang?

tongkat
sumber
Sigh, seperti kebanyakan hal lain, menginstal barang secara terpisah adalah tidak boleh. Kembali ke versi desktop yang membengkak dengan Office dan omong kosong lainnya :(
killjoy