Як виправити “BUG: soft lockup - процесор № 0 застряг за 17163091968”?

ОНОВЛЕННЯ: Я оновив заголовок повідомлення, тому що останнім часом я бачив більше таких проблем із такою точною кількістю часу 17163091968s. Це має допомогти людям, що досліджують симптоми, знайти цю сторінку. Дивіться мою (само-) прийняту відповідь нижче.

У мене є група 64-розрядних VM Ubuntu 10.04 LTS у центрі даних VMware vSphere. Встановлено інструменти VMware (клієнт vSphere каже "ОК").

Я кілька разів бачив висіння VM із наступною помилкою в syslog. Перевіряючи ситуацію з vSphere, консоль була чорною, а команда "Перезавантажити гостя" нічого не зробила, тому мені довелося перемикати живлення 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:

(Нема сліду - це останній рядок.)

Інших помилок я, схоже, більше не маю, але я впевнений, що процес, зазначений вище ( jed), відрізнявся від інших смітників.

• Що може спричинити цю проблему?

• Як не допустити цього?

Деякі додаткові відомості:

• Значення 17163091988трохи (каламбур призначене) підозріле - воно є 1111111111000000000000000000010100у двійковому. Може помилка намагалася сказати 20 секунд ( 10100у двійковій)?

• Я не впевнений, чи існує проблема з найновішим ядром 10.04 (2.6.32-35).

• Я також бачив task ... blocked for more than 120 secondsпроблеми - можливо, вони можуть бути пов’язані?

• клієнт vSphere не показує попередження або завдання міграції для VM.

Дякую всім коментаторам. Я думаю, що знайшов відповідь. Здається, є помилка хронометражу в принаймні сервері ядра Ubuntu версії 2.6.32-30-сервера. Клоп іноді (?) Вбиває машини, коли досягає тривалості роботи приблизно 200..210 днів. Насправді зупинка відбувається не відразу після досягнення межі, а викликається деякою операцією (у моєму випадку apt-get install ...:).

Примітка: 200 днів - це приблизно 2 ^ 32 рази 1/250 секунди, а 250 - значення за замовчуванням для CONFIG_HZ.

Наразі я не знайшов даних про те, чи була усунена проблема в останніх ядрах. Я знаю, що це, здається, не впливає на старе ядро ​​(2.6.32-26-сервер). З усієї цієї інформації я припускаю, що якщо вона ще не виправлена, її можна уникнути:

• завантажуйте машини кожні 190 днів (хороша ідея для оновлення ядра все одно)
• відрегулюйте CONFIG_HZ на 100 та зробіть це кожні 497 днів. Однак це може мати досить несподівані побічні ефекти, особливо у віртуальному середовищі. І це не вирішує проблему.

Ось звіт про помилки для Ubuntu.

Це насправді помилка ядра, яку виправили за допомогою наступного виконання ядра:

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

Ви можете шукати LKML за наступним заголовком (не може розмістити більше 2 посилань): [стабільний] 2.6.32.21 - збої, пов’язані з оновленням часу?

І ось помилка LP #, яка приносить виправлення ядра:

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

Оновлення до останнього ядра в lucid-update має усунути цю проблему назавжди.

HTH

Чи може бути, що у хості віртуалізації є деякі функції енергозбереження ("Зелений ІТ"), які можуть пересилати невикористані ядра в режим низької потужності / сну, викликаючи цікаві перебої в машинах управління, використовуючи це ядро? Я чув, що це було проблемою, головним чином, в середовищах HyperV, але це може щось вивчити.

У випадку, якщо хтось інший виявить це, оновлення ядра вирішило подібну проблему і для мене. У мене був JBOD, який був приєднаний до системи за допомогою контролера SAS3, який передав ці помилки Softlock процесора під час завантаження.

У мене було ядро ​​Ubuntu 14.04.2 версії 3.16.0-30, і проходження "apt -y upgrade" закінчило мене на ядрі 3.16.0-49, і це вирішило проблему.