Erro: bloqueio suave - CPU # travado por x segundos

Eu já vi alguns relatórios de bugs e perguntas (na stackexchange e em outros lugares) sobre um incômodo "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Até agora, não encontrei nenhuma pista sobre o que fazer ou tentar (em vez disso, as pistas que encontrei e segui não impediram que isso acontecesse). Estou mais preocupado com isso porque:

1. a frequência desses eventos parece ter aumentado lentamente ultimamente (mais de 700 por mês),
2. yum update e a reinicialização diminuiu a velocidade um pouco, mas vi alguns bloqueios começando a acontecer novamente,
3. vários processos (se não o host inteiro, é difícil dizer), certamente incluindo todos os meus shells interativos ficam congelados por um certo período de tempo quando isso acontece,
4. Não tenho certeza se isso está relacionado, mas vejo muitos logs / mensagens relacionados ao ntpd que não conseguem atualizar o relógio.

A seguir, um trecho de $(grep 'soft lockup' /var/log/messages*):

Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]

Isso acontece com processos aleatórios e parece razoavelmente bem distribuído pelos 16 "núcleos" desse host virtual.

O host é uma instância do AWS EC2 "cc1.4xlarge", com uma AMI denominada "EC2 CentOS 5.5 GPU HVM AMI (Driver 260.19.29) (ami-42a2532b)". Parece ser virtualizado com o Xen.

cat /etc/redhat-releaserendimentos CentOS release 5.9 (Final). 'free'relata 21G de RAM.

A cabeça de dmesgé:

Linux version 2.6.18-348.3.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)

Os seguintes mostra uma contagem cumulativa desses "travamentos soft" ao longo do tempo recente (o redline é quando eu fiz o último yum updateseguido por reboot): .

O seguinte mostra o histograma de duração (quanto tempo é o anfitrião preso): .

Também tenho esse problema no Xen 4.2 com o Kernel 3.6 e 3.8 (AlpineLinux).

Eu pesquisei e adicionando clocksource = jiffies ao meu kernel, eu o consertei. Em vez de jiffies, você também pode tentar "pit".

Há também relatórios de desativação de estados C no BIOS .

Eu tive o mesmo problema com o meu Thinkpad T520. Mas, em vez de cortar o kernel, fiz algo mais simples. Primeiro, estou usando o Centos7. Instalei o sistema básico, tudo funcionou bem. Depois, adicionei a GUI do GNOME mais tarde, quando comecei a obter os problemas mencionados acima. Percebo que muitos fabricantes configurados para instalações do Windows. A placa de vídeo é configurada geralmente para Win7 (NVIDIA OPTIMUS). Eu a redefino para o modo de gráfico integrado e não há mais interrupções / erros. Como fazer isso? Reinicie seu Thinkpad, pressione F1 ou o botão thinkvantage azul para entrar no BIOS. Vá para gráficos, selecione gráficos integrados e, em seguida, F10 para salvar e sair. Existem três configurações para esta placa: Integrada, Discreta e NVIDIA OPTIMUS (somente Win7?) Espero que isso economize algum tempo para alguém?