Come risolvere "BUG: soft lockup - CPU # 0 bloccato per 17163091968s"?

AGGIORNAMENTO: ho aggiornato il titolo del messaggio, perché di recente ho visto più di questi problemi con questo tempo esatto di 17163091968s. Questo dovrebbe aiutare le persone a studiare i sintomi per trovare questa pagina. Vedi la mia (auto-) risposta accettata di seguito.

Ho un sacco di macchine virtuali Ubuntu 10.04 LTS a 64 bit in un datacenter VMware vSphere. Gli strumenti VMware sono installati (vSphere Client dice "OK").

Ho visto alcune macchine virtuali bloccarsi alcune volte con il seguente errore in syslog. Durante il controllo della situazione da vSphere, la console era nera e il comando "Riavvia guest" non ha fatto nulla, quindi ho dovuto spegnere e riaccendere la 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:

(Non c'è traccia - questa è l'ultima riga.)

Non sembro più avere altri errori, ma sono abbastanza sicuro che il processo sopra menzionato ( jed) fosse diverso nelle altre discariche.

• Cosa potrebbe causare questo problema?

• Come impedire che ciò accada?

Alcune informazioni extra:

• Il valore 17163091988è un po 'sospetto (gioco di parole): è 1111111111000000000000000000010100in binario. Forse l'errore stava cercando di dire 20 secondi ( 10100in binario)?

• Non sono sicuro che il problema persista con l'ultimo kernel 10.04 (2.6.32-35).

• Ho visto anche task ... blocked for more than 120 secondsproblemi - forse potrebbero essere correlati?

• il client vSphere non mostra avvisi o attività di migrazione per la VM.

Grazie a tutti i commentatori. Penso di aver trovato la risposta. Sembra esserci un bug di cronometraggio almeno nel server della versione 2.6.32-30 del kernel di Ubuntu. Il bug a volte (?) Uccide le macchine quando raggiungono un tempo di attività di circa 200..210 giorni. In realtà l'arresto non si verifica immediatamente dopo il raggiungimento del limite, ma viene attivato da alcune operazioni (nel mio caso:) apt-get install ....

NB: 200 giorni sono circa 2 ^ 32 volte 1/250 secondi e 250 è il valore predefinito per CONFIG_HZ.

Per ora, non ho trovato dati sul fatto che il problema sia stato risolto in kernel più recenti. So che non sembra influenzare un kernel più vecchio (2.6.32-26-server). Da tutte queste informazioni presumo che se non è stato ancora risolto, può essere evitato da:

• avviare le macchine ogni 190 giorni (una buona idea per gli aggiornamenti del kernel comunque)
• regolare CONFIG_HZ su 100 e quindi farlo ogni 497 giorni. Tuttavia, questo potrebbe avere effetti collaterali abbastanza inaspettati, specialmente negli ambienti virtuali. E non risolve il problema.

Ecco una segnalazione di bug per Ubuntu.

Questo è in realtà un bug del kernel che è stato corretto dal seguente commit del kernel:

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

È possibile cercare LKML per il seguente titolo (non è possibile pubblicare più di 2 collegamenti): [stabile] 2.6.32.21 - arresti anomali relativi all'uptime?

E questo è il bug LP # che porta la correzione del kernel:

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

L'aggiornamento all'ultimo kernel negli aggiornamenti lucido dovrebbe risolvere questo problema per sempre.

HTH

Potrebbe essere che l'host di virtualizzazione abbia abilitato alcune funzionalità di risparmio energetico ("Green IT") che potrebbero inviare core non utilizzati in modalità a basso consumo / sospensione, causando interruzioni interessanti nelle VM che utilizzano quel core? Ho sentito che questo era un problema principalmente negli ambienti HyperV, ma potrebbe essere qualcosa da esaminare.

Se qualcun altro lo trova, un aggiornamento del kernel ha risolto un problema simile per me. Ho avuto un JBOD che era collegato al sistema tramite un controller SAS3 che lanciava questi errori di softlock della CPU all'avvio.

Ho avuto Ubuntu 14.04.2 versione del kernel 3.16.0-30, e fare un "apt -y upgrade" mi ha portato al kernel 3.16.0-49, e questo ha risolto il problema.