BOGUE: blocage logiciel - CPU # bloqué pendant x secondes

J'ai vu quelques rapports de bugs et questions (sur stackexchange et ailleurs) concernant un problème persistant "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Jusqu'à présent, je n'ai trouvé aucun indice sur ce qu'il faut faire ou essayer (les indices que j'ai trouvés et suivis n'ont pas empêché que cela se produise). Je suis également préoccupé par cela parce que:

1. la fréquence de ces événements semble avoir augmenté lentement (plus de 700 par mois),
2. yum update et le redémarrage a ralenti un peu pendant un moment, mais j'ai vu des blocages commencer à se reproduire,
3. plusieurs processus (si ce n’est pas tout l’hôte, c’est difficile à dire), notamment tous mes shells interactifs sont gelés pendant un certain temps,
4. Je ne sais pas si c'est lié, mais je vois beaucoup de journaux / messages liés au fait que Ntpd ne puisse pas mettre à jour l'horloge.

Ce qui suit est un extrait 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]

Cela arrive à des processus aléatoires, et semble assez bien réparti sur les 16 "cœurs" de cet hôte virtuel.

L'hôte est une instance AWS EC2 "cc1.4xlarge", avec une AMI nommée "AMI HVM du processeur graphique Centos 5.5 EC2 (pilote 260.19.29) (ami-42a2532b)". Il semble être virtualisé avec Xen.

cat /etc/redhat-releaseles rendements CentOS release 5.9 (Final). 'free'rapporte 21G de RAM.

La tête de dmesgest:

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)

L'exemple suivant montre un cumulatif de comptage de ces « Blocages douces » au fil du temps récent (redline est quand je l'ai fait la dernière yum updatesuivie reboot): .

L'exemple suivant montre l'histogramme de la durée (combien de temps est l'hôte bloqué): .

J'ai également ce problème sur Xen 4.2 avec les noyaux 3.6 et 3.8 (AlpineLinux).

J'ai cherché sur Google et en ajoutant clocksource = jiffies à mon noyau, je l'ai corrigé. Au lieu de jiffies, vous pouvez également essayer "pit".

Il existe également des rapports sur la désactivation des états C dans le BIOS .

J'ai eu le même problème avec mon Thinkpad T520. Mais au lieu d’attaquer le noyau, j’ai fait quelque chose de plus simple. Tout d’abord, j’utilise Centos7, j’ai installé le système de base, tout fonctionnait bien. J'ai ensuite ajouté l'interface graphique GNOME plus tard, c'est à ce moment-là que j'ai commencé à résoudre les problèmes mentionnés ci-dessus. Je remarque que beaucoup de fabricants installent des installations pour Windows. La carte graphique est généralement configurée pour Win7 (NVIDIA OPTIMUS). Je la réinitialise en mode graphique intégré et ne bloque plus les erreurs. Comment faire? Redémarrez votre Thinkpad en appuyant sur F1 ou sur le bouton bleu thinkvantage pour accéder au BIOS. Allez dans graphiques, sélectionnez graphiques intégrés puis F10 pour enregistrer et quitter. Il y a 3 réglages pour cette carte: intégré, discret et NVIDIA OPTIMUS (Win7 seulement?) Vous espérez que cela sauve du temps?