Bagaimana cara memperbaiki "BUG: soft lockup - CPU # 0 macet untuk 17163091968s"?


14

UPDATE: Saya memperbarui judul pesan, karena saya baru-baru ini melihat lebih banyak masalah dengan jumlah waktu yang tepat ini 17163091968s. Ini akan membantu orang menyelidiki gejala untuk menemukan halaman ini. Lihat jawaban saya yang diterima sendiri di bawah ini.


Saya memiliki banyak 64-bit Ubuntu 10,04 LTS VM di pusat data VMware vSphere. Alat VMware diinstal (vSphere Client mengatakan "OK").

Saya telah melihat beberapa VM hang beberapa kali dengan kesalahan berikut di syslog. Ketika memeriksa situasi dari vSphere, konsolnya berwarna hitam, dan perintah "Reboot guest" tidak melakukan apa-apa, jadi saya harus menghidupkan VM.

Dec  1 11:44:15 s0 kernel: [18446744060.007150] BUG: soft lockup - CPU#0 stuck for 17163091988s! [jed:26674]
Dec  1 11:44:15 s0 kernel: [18446744060.026854] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026899] CPU 0:
Dec  1 11:44:15 s0 kernel: [18446744060.026900] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs xt_tcpudp iptable_filter ip_tables x_tables acpiphp fbcon tileblit font bitblit softcursor ppdev vga16fb psmouse parport_pc shpchp vgastate i2c_piix4 lp parport serio_raw intel_agp floppy mptspi mptscsih vmw_pvscsi e1000 mptbase
Dec  1 11:44:15 s0 kernel: [18446744060.026920] Pid: 26674, comm: jed Not tainted 2.6.32-30-server #59-Ubuntu VMware Virtual Platform
Dec  1 11:44:15 s0 kernel: [18446744060.026922] RIP: 0033:[<00007f92e03d2ce6>]  [<00007f92e03d2ce6>] 0x7f92e03d2ce6
Dec  1 11:44:15 s0 kernel: [18446744060.026930] RSP: 002b:00007fff6069b770  EFLAGS: 00000202
Dec  1 11:44:15 s0 kernel: [18446744060.026932] RAX: 00007f92e27e7e10 RBX: 00007f92e06d5e40 RCX: 0000000000020000
Dec  1 11:44:15 s0 kernel: [18446744060.026933] RDX: 00007f92e27e7e10 RSI: 0000000000020209 RDI: 0000000000000002
Dec  1 11:44:15 s0 kernel: [18446744060.026934] RBP: ffffffff81013cae R08: 0000000000000001 R09: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026935] R10: 00007f92e06d6398 R11: 0000000000000870 R12: 00000000000000c0
Dec  1 11:44:15 s0 kernel: [18446744060.026937] R13: 00007f92e299dca0 R14: 0000000000000020 R15: 00007f92e06d5e40
Dec  1 11:44:15 s0 kernel: [18446744060.026939] FS:  00007f92e105b700(0000) GS:ffff880009c00000(0000) knlGS:0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec  1 11:44:15 s0 kernel: [18446744060.026941] CR2: 00007ff12ea15000 CR3: 0000000267067000 CR4: 00000000000006f0
Dec  1 11:44:15 s0 kernel: [18446744060.026968] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec  1 11:44:15 s0 kernel: [18446744060.026989] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec  1 11:44:15 s0 kernel: [18446744060.026991] Call Trace:

(Tidak ada jejak - itulah baris terakhir.)

Saya sepertinya tidak memiliki kesalahan lain lagi, tapi saya cukup yakin proses yang disebutkan di atas ( jed) berbeda di kesedihan lain.

  • Apa yang bisa menyebabkan masalah ini?

  • Bagaimana mencegah hal ini terjadi?

Beberapa info tambahan:

  • Nilai 17163091988agak mencurigakan - 1111111111000000000000000000010100dalam bentuk biner. Mungkin kesalahannya mencoba mengatakan 20 detik ( 10100dalam biner)?

  • Saya tidak yakin apakah masalah berlanjut dengan kernel 10,04 terbaru (2.6.32-35).

  • Saya juga melihat task ... blocked for more than 120 secondsmasalah - mungkin mereka terkait?

  • klien vSphere tidak menunjukkan peringatan atau tugas migrasi untuk VM.


mungkin ada yang salah waktu? Anda bisa bermain dengan clocksource. Kondisi-C CPU juga merupakan dugaan yang baik.
SaveTheRbtz

Jawaban:


12

Terima kasih untuk semua komentator. Saya pikir saya menemukan jawabannya. Tampaknya ada bug ketepatan waktu di setidaknya kernel Ubuntu versi 2.6.32-30-server. Bug kadang-kadang (?) Membunuh mesin ketika mereka mencapai uptime sekitar 200..210 hari. Sebenarnya penghentian tidak terjadi segera setelah batas tercapai, tetapi dipicu oleh beberapa operasi (dalam kasus saya:) apt-get install ....

NB: 200 hari adalah sekitar 2 ^ 32 kali 1/250 detik, dan 250 adalah nilai default untuk CONFIG_HZ.

Untuk saat ini, saya belum menemukan data apakah masalah telah diperbaiki di kernel yang lebih baru. Saya tahu bahwa itu tampaknya tidak mempengaruhi kernel yang lebih lama (2.6.32-26-server). Dari semua informasi ini saya berasumsi bahwa jika belum diperbaiki, dapat dihindari dengan:

  • boot mesin itu setiap 190 hari (toh ide bagus untuk upgrade kernel)
  • sesuaikan CONFIG_HZ menjadi 100 dan karenanya membuatnya setiap 497 hari. Namun, ini mungkin memiliki efek samping yang tidak terduga, terutama di lingkungan virtual. Dan itu tidak menyelesaikan masalah.

Berikut laporan bug untuk Ubuntu.


Bagus temukan - bertanya-tanya apakah itu menetes ke debian
thinice

Karena penasaran: Apakah Anda menggunakan NTP atau sinkronisasi waktu melalui vmware? Kedengarannya seperti pergeseran waktu yang konstan atau sesuatu seperti itu .. harus ada entri login dari pergeseran waktu di syslog.
pauska

Saya baru saja melihat sesuatu yang tampak terkait di debian, kernel 2.6.32-5-amd64 yang menampilkan dua soft lock up yang berkinerja "aneh"
James

5

Ini sebenarnya adalah bug kernel yang diperbaiki oleh komit kernel berikut:

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9

Anda dapat mencari LKML untuk judul berikut (tidak dapat memposting lebih dari 2 tautan): [stable] 2.6.32.21 - crash terkait waktu aktif?

Dan ini adalah bug # LP yang membawa perbaikan kernel:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317

Memutakhirkan ke kernel terbaru di pembaruan jernih harus memperbaiki masalah ini untuk selamanya.

HTH


2

Mungkinkah host virtualisasi memiliki beberapa fitur hemat daya ("Green IT") yang diaktifkan yang dapat mengirim core yang tidak digunakan ke mode low-power / sleep, menyebabkan gangguan menarik pada VM menggunakan core itu? Saya pernah mendengar ini dulunya masalah terutama di lingkungan HyperV tetapi mungkin sesuatu untuk dilihat.


1

Jika ada orang lain yang menemukan ini, upgrade kernel memperbaiki masalah yang sama untuk saya. Saya punya JBOD yang terpasang pada sistem melalui pengontrol SAS3 yang melempar kesalahan Softlock CPU ini saat boot.

Saya memiliki Ubuntu 14.04.2 versi kernel 3.16.0-30, dan melakukan "apt -y upgrade" mengakhiri saya di kernel 3.16.0-49, dan itu memecahkan masalah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.