Как исправить «BUG: мягкая блокировка - CPU № 0 застрял на 17163091968s»?

ОБНОВЛЕНИЕ: я обновил заголовок сообщения, потому что я недавно видел больше этих проблем с этим точным количеством времени 17163091968s. Это должно помочь людям, исследующим симптомы, найти эту страницу. Смотрите мой (самостоятельно) принятый ответ ниже.

У меня есть несколько 64-битных виртуальных машин Ubuntu 10.04 LTS в центре обработки данных VMware vSphere. Установлены инструменты VMware (vSphere Client говорит «ОК»).

Я видел несколько зависаний виртуальной машины несколько раз со следующей ошибкой в ​​системном журнале. При проверке ситуации из vSphere консоль была черной, а команда «Перезагрузить гостя» ничего не сделала, поэтому мне пришлось выключить и включить виртуальную машину.

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 не показывает предупреждений или задач миграции для виртуальной машины.

Спасибо всем комментаторам. Я думаю, что нашел ответ. Кажется, есть ошибка хронометража по крайней мере в ядре Ubuntu версии 2.6.32-30-server. Ошибка иногда (?) Убивает машины, когда они достигают времени безотказной работы около 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-updates должно исправить эту проблему навсегда.

НТН

Может ли быть так, что хост виртуализации имеет некоторые функции энергосбережения («Зеленые ИТ»), которые могут отправлять неиспользуемые ядра в режим низкого энергопотребления / спящего режима, вызывая интересные сбои в работе виртуальных машин, использующих это ядро? Я слышал, что раньше это было проблемой в основном в среде HyperV, но это может быть чем-то, на что стоит обратить внимание.

В случае, если кто-то еще обнаружит это, обновление ядра исправило подобную проблему для меня. У меня был JBOD, который был подключен к системе через контроллер SAS3, выдавая эти ошибки CPU Softlock при загрузке.

У меня было ядро ​​Ubuntu 14.04.2 версии 3.16.0-30, и выполнение «apt -y upgrade» привело меня к ядру 3.16.0-49, и это решило проблему.