Como corrigir “BUG: bloqueio suave - CPU # 0 preso por 17163091968s”?

Question

UPDATE: atualizei o título da mensagem, porque vi recentemente mais desses problemas com a quantidade exata de tempo de 17163091968s . Isso deve ajudar as pessoas a investigar os sintomas para encontrar essa página. Veja a minha (auto) resposta abaixo.

Tenho um monte de VMs LTS Ubuntu 10.04 de 64 bits em um datacenter do VMware vSphere. As ferramentas do VMware estão instaladas (o vSphere Client diz "OK").

Eu vi algumas das VMs serem interrompidas algumas vezes com o seguinte erro no syslog. Ao verificar a situação do vSphere, o console era preto e o comando "Reboot guest" não fazia nada, então tive que ligar e desligar a 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:

(Não há nenhum traço - essa é a última linha.)

Eu não pareço ter mais os outros erros, mas tenho certeza que o processo mencionado acima ( jed ) foi diferente nos outros dumps.

• O que poderia causar esse problema?

• Como evitar que isso aconteça?

Algumas informações adicionais:

• O valor 17163091988 é um pouco suspeito - é 1111111111000000000000000000010100 em binário. Talvez o erro estivesse tentando dizer 20 segundos ( 10100 no binário)?

• Não tenho certeza se o problema persiste com o kernel 10.04 mais recente (2.6.32-35).

• Eu também vi task ... blocked for more than 120 seconds problemas - talvez eles possam estar relacionados?

• o cliente vSphere não mostra alertas ou tarefas de migração para a VM.

Answer 1

Obrigado a todos os comentadores. Eu acho que encontrei a resposta. Parece haver um erro de cronometragem em pelo menos a versão 2.6.32-30-server do kernel do Ubuntu. O bug às vezes (?) Mata as máquinas quando elas atingem um tempo de atividade de cerca de 200..210 dias. Na verdade, a parada não acontece imediatamente após o limite ser atingido, mas é acionada por alguma operação (no meu caso: apt-get install ... ).

NB: 200 dias é cerca de 2 ^ 32 vezes 1/250 segundo e 250 é o valor padrão para CONFIG_HZ.

Por enquanto, não encontrei dados sobre se o problema foi corrigido em kernels mais recentes. Eu sei que isso não parece afetar um kernel antigo (2.6.32-26-server). De todas essas informações, presumo que, se não for corrigido ainda, pode ser evitado por:

• inicialize as máquinas a cada 190 dias (uma boa idéia para atualizações do kernel de qualquer maneira)
• ajuste CONFIG_HZ para 100 e aumente a cada 497 dias. No entanto, isso pode ter efeitos colaterais inesperados, especialmente em ambientes virtuais. E isso não resolve o problema.

Aqui está um relatório de erros para o Ubuntu.

    

Answer 2

Este é realmente um bug do kernel que foi corrigido pelo seguinte commit do kernel:

link

Você pode pesquisar LKML pelo seguinte título (não pode postar mais de 2 links): [estável] 2.6.32.21 - falhas relacionadas a uptime?

E este é o bug do LP # que traz a correção do kernel:

link

Atualizar para o kernel mais recente em atualizações lúcidas deve corrigir esse problema definitivamente.

HTH

    

Answer 3

Será que o host de virtualização possui alguns recursos de economia de energia ("TI Verde") habilitados que podem enviar núcleos não utilizados para um modo de baixo consumo de energia / suspensão, causando interrupções interessantes nas VMs usando esse núcleo? Ouvi dizer que isso costumava ser um problema principalmente em ambientes HyperV, mas pode ser algo para se investigar.

    

Answer 4

No caso de alguém achar isso, uma atualização do kernel corrigiu um problema semelhante para mim. Eu tive um JBOD que foi anexado ao sistema através de um controlador SAS3 jogando esses erros de CPU Softlock na inicialização.

Eu tinha a versão do kernel do Ubuntu 14.04.2 3.16.0-30, e fazendo uma "atualização do apt -y", terminei no kernel 3.16.0-49, e isso resolveu o problema.