AKTUALIZACJA: Zaktualizowałem tytuł wiadomości, ponieważ ostatnio widziałem więcej tych problemów z tym dokładnym czasem 17163091968s. To powinno pomóc osobom badającym objawy znaleźć tę stronę. Zobacz moją (samodzielnie) zaakceptowaną odpowiedź poniżej.
Mam kilka 64-bitowych maszyn wirtualnych LTS Ubuntu 10.04 w centrum danych VMware vSphere. Narzędzia VMware są zainstalowane (klient vSphere mówi „OK”).
Widziałem kilka maszyn wirtualnych zawieszających się kilka razy z następującym błędem w syslog. Podczas sprawdzania sytuacji z vSphere konsola była czarna, a polecenie „Uruchom ponownie gościa” nic nie zrobiło, więc musiałem ponownie włączyć maszynę wirtualną.
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:
(Nie ma śladu - to ostatni wiersz.)
Wydaje mi się, że nie mam już innych błędów, ale jestem całkiem pewien, że proces wspomniany powyżej ( jed) był inny na innych zrzutach.
Co może powodować ten problem?
Jak temu zapobiec?
Kilka dodatkowych informacji:
Wartość
17163091988jest nieco podejrzana (gra słów) - jest1111111111000000000000000000010100binarna. Może błąd próbował powiedzieć 20 sekund (10100dwójkowo)?Nie jestem pewien, czy problem występuje nadal w najnowszym jądrze 10.04 (2.6.32-35).
Widziałem także
task ... blocked for more than 120 secondsproblemy - może mogą być powiązane?klient vSphere nie wyświetla alertów ani zadań migracji dla maszyny wirtualnej.
źródło
clocksource. Również stany C procesorów są dobrym przypuszczeniem.Odpowiedzi:
Dzięki wszystkim komentującym. Myślę, że znalazłem odpowiedź. Wygląda na to, że w jądrze Ubuntu w wersji 2.6.32-30-server występuje błąd pomiaru czasu. Błąd czasami (?) Zabija maszyny, gdy osiągają czas pracy wynoszący około 200..210 dni. W rzeczywistości zatrzymanie nie następuje natychmiast po osiągnięciu limitu, ale jest uruchamiane przez jakąś operację (w moim przypadku
apt-get install ...:).Uwaga: 200 dni to około 2 ^ 32 razy 1/250 sekundy, a 250 to wartość domyślna dla CONFIG_HZ.
Na razie nie znalazłem danych, czy problem został naprawiony w nowszych jądrach. Wiem, że nie wpływa to na starsze jądro (2.6.32-26-serwer). Na podstawie wszystkich tych informacji zakładam, że jeśli nie jest to jeszcze naprawione, można tego uniknąć poprzez:
Oto raport o błędzie dla Ubuntu.
źródło
W rzeczywistości jest to błąd jądra, który został naprawiony przez następujące zatwierdzenie jądra:
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9
Możesz wyszukać LKML pod kątem następującego tytułu (nie możesz opublikować więcej niż 2 linków): [stabilny] 2.6.32.21 - awarie związane z czasem pracy?
A to jest błąd LP #, który wprowadza poprawkę jądra:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317
Aktualizacja do najnowszego jądra w przejrzystych aktualizacjach powinna rozwiązać ten problem na dobre.
HTH
źródło
Czy to możliwe, że host wirtualizacji ma włączone niektóre funkcje oszczędzania energii („Green IT”), które mogą wysyłać nieużywane rdzenie do trybu niskiego poboru mocy / uśpienia, powodując ciekawe zakłócenia w maszynach wirtualnych korzystających z tego rdzenia? Słyszałem, że był to problem głównie w środowiskach HyperV, ale może być coś, na co warto zwrócić uwagę.
źródło
Na wypadek, gdyby ktoś to znalazł, aktualizacja jądra naprawiła dla mnie podobny problem. Miałem JBOD, który został podłączony do systemu za pomocą kontrolera SAS3, który wyrzucał te błędy Softlock CPU podczas uruchamiania.
Miałem jądro Ubuntu 14.04.2 w wersji 3.16.0-30, a wykonanie aktualizacji „apt -y” zakończyło mnie w jądrze 3.16.0-49, co rozwiązało problem.
źródło