¿Cómo arreglar "ERROR: bloqueo suave - CPU # 0 atascado durante 17163091968s"?

ACTUALIZACIÓN: Actualicé el título del mensaje, porque recientemente he visto más de estos problemas con este tiempo exacto 17163091968s. Esto debería ayudar a las personas que investigan los síntomas a encontrar esta página. Vea mi (auto-) respuesta aceptada a continuación.

Tengo un montón de máquinas virtuales Ubuntu 10.04 LTS de 64 bits en un centro de datos VMware vSphere. Las herramientas de VMware están instaladas (vSphere Client dice "OK").

He visto algunas de las máquinas virtuales bloquearse varias veces con el siguiente error en syslog. Al verificar la situación desde vSphere, la consola estaba en negro, y el comando "Reiniciar invitado" no hizo nada, así que tuve que apagar y encender la máquina virtual.

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:

(No hay rastro, esa es la última línea).

Parece que ya no tengo los otros errores, pero estoy bastante seguro de que el proceso mencionado anteriormente ( jed) fue diferente en los otros volcados.

• ¿Qué podría causar este problema?

• ¿Cómo evitar que esto suceda?

Alguna información extra:

• El valor 17163091988es un poco sospechoso: está 1111111111000000000000000000010100en binario. ¿Quizás el error estaba tratando de decir 20 segundos ( 10100en binario)?

• No estoy seguro de si el problema persiste con el último kernel 10.04 (2.6.32-35).

• También he visto task ... blocked for more than 120 secondsproblemas, ¿tal vez podrían estar relacionados?

• El cliente vSphere no muestra alertas ni tareas de migración para la VM.

Gracias a todos los comentaristas. Creo que encontré la respuesta. Parece que hay un error de cronometraje en al menos el kernel de Ubuntu versión 2.6.32-30-server. El error a veces (?) Mata las máquinas cuando alcanzan un tiempo de actividad de aproximadamente 200..210 días. En realidad, la detención no ocurre inmediatamente después de que se alcanza el límite, sino que se desencadena por alguna operación (en mi caso:) apt-get install ....

NB: 200 días es aproximadamente 2 ^ 32 veces 1/250 segundo, y 250 es el valor predeterminado para CONFIG_HZ.

Por ahora, no he encontrado datos sobre si el problema se ha solucionado en los núcleos más recientes. Sé que no parece afectar a un kernel anterior (2.6.32-26-server). De toda esta información, supongo que si aún no se ha solucionado, se puede evitar:

• arranque las máquinas cada 190 días (de todos modos, una buena idea para las actualizaciones del kernel)
• ajustar CONFIG_HZ a 100 y así hacerlo cada 497 días. Sin embargo, esto podría tener efectos secundarios bastante inesperados, especialmente en entornos virtuales. Y no resuelve el problema.

Aquí hay un informe de error para Ubuntu.

Esto es en realidad un error del kernel que se solucionó mediante la siguiente confirmación del kernel:

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

Puede buscar en LKML el siguiente título (no puede publicar más de 2 enlaces): [estable] 2.6.32.21 - ¿fallas relacionadas con el tiempo de actividad?

Y este es el error LP # que trae la corrección del kernel:

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

La actualización al último kernel en lucid-updates debería solucionar este problema para siempre.

HTH

¿Podría ser que el host de virtualización tenga algunas funciones de ahorro de energía ("Green IT") habilitadas que podrían enviar núcleos no utilizados a un modo de bajo consumo / reposo, causando interrupciones interesantes en las máquinas virtuales que usan ese núcleo? He oído que esto solía ser un problema principalmente en entornos HyperV, pero puede ser algo a tener en cuenta.

En caso de que alguien más encuentre esto, una actualización del núcleo solucionó un problema similar para mí. Tenía un JBOD que estaba conectado al sistema a través de un controlador SAS3 que arrojaba estos errores de CPU Softlock en el arranque.

Tenía Ubuntu 14.04.2 kernel versión 3.16.0-30, y hacer una "actualización apta y" me terminó en el kernel 3.16.0-49, y eso resolvió el problema.