Как исправить “BUG: мягкая блокировка – CPU#0 заблокирован на 17163091968s”?

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

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

Я видел, что некоторые из виртуальных машин несколько раз зависали с следующей ошибкой в syslog. Проверяя ситуацию из 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 ... заблокирована более чем на 120 секунд – возможно, они могут быть связаны?

• Клиент vSphere не показывает никаких предупреждений или задач миграции для виртуальной машины.

Спасибо всем комментаторам. Я думаю, я нашел ответ. Похоже, что в ядре Ubuntu версии 2.6.32-30-server есть ошибка синхронизации времени. Эта ошибка иногда (?) останавливает машины, когда они достигают времени работы около 200..210 дней. На самом деле, остановка не происходит сразу после достижения лимита, но запускается какой-то операцией (в моем случае: apt-get install ...).

Замечание: 200 дней – это примерно 2^32 раз 1/250 секунды, и 250 – это значение по умолчанию для CONFIG_HZ.

Пока что я не нашел данных о том, была ли проблема исправлена в более поздних ядрах. Я знаю, что это, похоже, не влияет на более старое ядро (2.6.32-26-server). Исходя из всей этой информации, я предполагаю, что, если проблема еще не исправлена, ее можно избежать следующим образом:

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

Вот отчет об ошибке для Ubuntu.

Это, на самом деле, ошибка ядра, которая была исправлена следующей коммитом ядра:

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

Вы можете поискать на LKML по следующему заголовку (нельзя разместить более 2 ссылок): [stable] 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, и это решило проблему.

Я столкнулся с этой ошибкой при установке новой версии Ubuntu на Virtual Box, уменьшив количество ядер процессора для виртуальной машины с 8 до 4, что решило мою ошибку.