Określanie przyczyny paniki jądra Linux

Używam pochodnej Ubuntu 12.04 (amd64) i ostatnio mam naprawdę dziwne problemy. Niespodziewanie X najwyraźniej zawiesi się na chwilę (1-3 minuty?), A następnie system uruchomi się ponownie. Ten system jest podkręcony, ale bardzo stabilny, co potwierdzono w systemie Windows, co prowadzi mnie do wniosku, że mam panikę jądra lub problem z jednym z moich modułów. Nawet w Linuksie mogę uruchomić LINPACK i nie zobaczę awarii, mimo że włożyłem w procesor absurdalne obciążenie. Wydaje się, że awarie zdarzają się w przypadkowych momentach, nawet gdy maszyna nie pracuje.

Jak mogę debugować, co powoduje awarię systemu?

Na przeczucie, że może to być prawnie zastrzeżony sterownik NVIDIA, wróciłem do stabilnej wersji sterownika, wersji 304 i nadal mam awarię.

Czy ktoś może przeprowadzić mnie przez dobrą procedurę debugowania po awarii? Z chęcią uruchomię pamięć USB i opublikuję wszystkie moje pliki konfiguracyjne po awarii, po prostu nie jestem pewien, jakie by to były. Jak mogę dowiedzieć się, co powoduje awarię mojego systemu?

Oto kilka dzienników, zwykłych sprawców.

.xsession-error : http://pastebin.com/EEDtVkVm

/var/log/Xorg.0.log : http://pastebin.com/ftsG5VAn

/var/log/kern.log : http://pastebin.com/Hsy7jcHZ

/ var / log / syslog : http://pastebin.com/9Fkp3FMz

Wydaje mi się, że w ogóle nie mogę znaleźć zapisu katastrofy.

Wywołanie awarii nie jest tak proste, wydaje się, że dzieje się tak, gdy GPU próbuje narysować wiele rzeczy naraz. Jeśli włączę film na YouTube na pełnym ekranie i pozwolę mu się powtórzyć przez chwilę lub przewinie mnóstwo plików GIF, a pojawi się powiadomienie Skype, czasem się zawiesi. Całkowicie podrapałem się po głowie.

Procesor jest podkręcony do 4,8 GHz, ale jest całkowicie stabilny i przetrwał wczoraj ogromne przebiegi LINPACK i 9 godzin Prime95 bez jednego awarii.

Aktualizacja

Mam zainstalowane kdump, crashoraz linux-crashdump, a także symbole debugowania jądra dla mojego jądra wersji 3.2.0-35. Kiedy uruchomić apport-unpackna rozbił plik jądra, a następnie crashna VmCorezrzutu awaryjnego, oto co widzę:

      KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-35-generic
    DUMPFILE: Downloads/crash/VmCore
        CPUS: 8
        DATE: Thu Jan 10 16:05:55 2013
      UPTIME: 00:26:04
LOAD AVERAGE: 2.20, 0.84, 0.49
       TASKS: 614
    NODENAME: mightymoose
     RELEASE: 3.2.0-35-generic
     VERSION: #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012
     MACHINE: x86_64  (3499 Mhz)
      MEMORY: 8 GB
       PANIC: "[ 1561.519960] Kernel panic - not syncing: Fatal Machine check"
         PID: 0
     COMMAND: "swapper/5"
        TASK: ffff880211251700  (1 of 8)  [THREAD_INFO: ffff880211260000]
         CPU: 5
       STATE: TASK_RUNNING (PANIC)

Kiedy uruchamiam logz crashnarzędzia, widzę to na dole dziennika:

[ 1561.519943] [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000800400
[ 1561.519946] [Hardware Error]: RIP !INEXACT! 33:<00007fe99ae93e54> 
[ 1561.519948] [Hardware Error]: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 
[ 1561.519950] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28
[ 1561.519951] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519953] [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 3: be00000000800400
[ 1561.519955] [Hardware Error]: TSC 539b174de9d ADDR 3fe98d264ebd MISC 1 
[ 1561.519957] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 0 microcode 28
[ 1561.519958] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519959] [Hardware Error]: Machine check: Processor context corrupt
[ 1561.519960] Kernel panic - not syncing: Fatal Machine check
[ 1561.519962] Pid: 0, comm: swapper/5 Tainted: P   M     C O 3.2.0-35-generic #55-Ubuntu
[ 1561.519963] Call Trace:
[ 1561.519964]  <#MC>  [<ffffffff81644340>] panic+0x91/0x1a4
[ 1561.519971]  [<ffffffff8102abeb>] mce_panic.part.14+0x18b/0x1c0
[ 1561.519973]  [<ffffffff8102ac80>] mce_panic+0x60/0xb0
[ 1561.519975]  [<ffffffff8102aec4>] mce_reign+0x1f4/0x200
[ 1561.519977]  [<ffffffff8102b175>] mce_end+0xf5/0x100
[ 1561.519979]  [<ffffffff8102b92c>] do_machine_check+0x3fc/0x600
[ 1561.519982]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519984]  [<ffffffff8165d78c>] machine_check+0x1c/0x30
[ 1561.519986]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519987]  <<EOE>>  [<ffffffff81509697>] ? menu_select+0xe7/0x2c0
[ 1561.519991]  [<ffffffff815082d1>] cpuidle_idle_call+0xc1/0x280
[ 1561.519994]  [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 1561.519996]  [<ffffffff8163aa9a>] start_secondary+0xd9/0xdb

bt wyświetla ślad śledzenia:

PID: 0      TASK: ffff880211251700  CPU: 5   COMMAND: "swapper/5"
 #0 [ffff88021ed4aba0] machine_kexec at ffffffff8103947a
 #1 [ffff88021ed4ac10] crash_kexec at ffffffff810b52c8
 #2 [ffff88021ed4ace0] panic at ffffffff81644347
 #3 [ffff88021ed4ad60] mce_panic.part.14 at ffffffff8102abeb
 #4 [ffff88021ed4adb0] mce_panic at ffffffff8102ac80
 #5 [ffff88021ed4ade0] mce_reign at ffffffff8102aec4
 #6 [ffff88021ed4ae40] mce_end at ffffffff8102b175
 #7 [ffff88021ed4ae70] do_machine_check at ffffffff8102b92c
 #8 [ffff88021ed4af50] machine_check at ffffffff8165d78c
    [exception RIP: intel_idle+191]
    RIP: ffffffff8136d48f  RSP: ffff880211261e38  RFLAGS: 00000046
    RAX: 0000000000000020  RBX: 0000000000000008  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: ffff880211261fd8  RDI: ffffffff81c12f00
    RBP: ffff880211261e98   R8: 00000000fffffffc   R9: 0000000000000f9f
    R10: 0000000000001e95  R11: 0000000000000000  R12: 0000000000000003
    R13: ffff88021ed5ac70  R14: 0000000000000020  R15: 12d818fb42cfe42b
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <MCE exception stack> ---
 #9 [ffff880211261e38] intel_idle at ffffffff8136d48f
#10 [ffff880211261ea0] cpuidle_idle_call at ffffffff815082d1
#11 [ffff880211261f00] cpu_idle at ffffffff8101322a

Jakieś pomysły?

Mam dwie sugestie na początek.

Pierwszy, którego nie polubisz. Bez względu na to, jak stabilny jest twój podkręcony system, byłby to mój pierwszy podejrzany. I każdy programista, któremu zgłaszasz problem, powie to samo. Twoje stabilne obciążenie testowe niekoniecznie korzysta z tych samych instrukcji, obciążając jednocześnie podsystem pamięci. Przestań podkręcać. Jeśli chcesz, aby ludzie wierzyli, że problem nie jest przetaktowywany, zrób to, gdy nie zostanie przetaktowany, aby otrzymać czysty raport o błędzie. Będzie to miało ogromną różnicę w nakładzie pracy innych ludzi na rozwiązanie tego problemu. Posiadanie oprogramowania wolnego od błędów jest powodem do dumy, ale raporty od osób ze szczególnie wątpliwymi konfiguracjami sprzętowymi frustrują ograniczenia czasowe, które prawdopodobnie nie wiążą się z żadnym prawdziwym błędem.

Drugim jest uzyskanie danych oops, które, jak zauważyłeś, nie trafiają do żadnego z wymienionych przez ciebie miejsc. Jeśli awaria zdarza się tylko podczas uruchamiania X11, myślę, że konsola lokalna jest prawie całkowicie wyłączona (i tak jest to problem), więc musisz to zrobić na konsoli szeregowej, w sieci lub zapisując na dysku lokalnym (co jest trudniejsze niż może zabrzmieć, ponieważ nie chcesz, aby niewiarygodne jądro uszkodziło system plików). Oto kilka sposobów, aby to zrobić:

• użyj netdump, aby zapisać na serwerze przez sieć. Nie robiłem tego od lat, więc nie jestem pewien, czy to oprogramowanie jest nadal dostępne i działa z nowoczesnymi jądrami, ale jest to dość łatwe, że warto spróbować.
• uruchom przy użyciu konsoli szeregowej ; będziesz potrzebować wolnego portu szeregowego na obu komputerach (czy to oldschoolowy, czy szeregowy adapter USB) i kabla zerowego modemu; skonfigurujesz inny komputer, aby zapisać dane wyjściowe.
• kdump wydaje się być tym, czego używają obecnie fajne dzieci i wydaje się dość elastyczny, chociaż nie byłoby to moim wyborem, ponieważ jego konfiguracja wygląda na skomplikowaną. Krótko mówiąc, wymaga to uruchomienia innego jądra, które może zrobić wszystko i sprawdzić zawartość pamięci poprzedniego jądra, ale musisz zasadniczo zbudować cały proces i nie widzę tam wielu opcji w puszce. Aktualizacja: Właściwie jest kilka fajnych rzeczy do dystrybucji; na Ubuntu, Linux-crashdump

Po uzyskaniu informacji o debugowaniu istnieje narzędzie o nazwie ksymoops , którego można użyć do przekształcenia adresów w nazwy symboli i uzyskania wyobrażenia o awarii jądra. A jeśli symboliczny zrzut nic dla ciebie nie znaczy, przynajmniej jest to coś przydatnego do zgłoszenia tutaj lub być może na liście mailingowej / trackerze błędów twojej dystrybucji Linuksa.

Z crashpoziomu zrzutu awaryjnego możesz spróbować pisać logi btuzyskać nieco więcej informacji (rzeczy zarejestrowane w trakcie paniki i śledzenie stosu). Twój Fatal Machine checkwydaje się pochodzić z tutaj , choć. Po przejrzeniu kodu procesor zgłosił wyjątek sprawdzania maszyny - problem sprzętowy. Ponownie mój pierwszy zakład byłby spowodowany przetaktowaniem. Wygląda na to, że w danych logwyjściowych może znajdować się bardziej konkretny komunikat, który mógłby powiedzieć więcej.

Również z tego kodu wygląda na to, że jeśli uruchomisz z mce=3parametrem jądra, przestanie się zawieszać ... ale tak naprawdę nie poleciłbym tego inaczej niż jako krok diagnostyczny. Jeśli jądro Linuksa uważa, że ​​ten błąd jest wart awarii, prawdopodobnie ma rację.

a) Sprawdź, czy komunikaty jądra są logowane do pliku przez demona rsyslog

vi /etc/rsyslog.conf

I dodaj następujące

kern.*                 /var/log/kernel.log

Uruchom ponownie rsyslogusługę.

/etc/initd.d/rsyslog restart

b) Zanotuj załadowane moduły

`lsmod >/your/home/dir`

c) Ponieważ panika nie jest powtarzalna, poczekaj na jej wystąpienie

d) Po wystąpieniu paniki uruchom system z płyty CD na żywo lub awaryjnej

e) Zamontuj systemy plików (zwykle / wystarczą jeśli / var i / home nie są oddzielne systemy plików) systemu dotkniętego ( pvs, vgs, lvskomendy muszą być uruchamiane, jeśli używasz LVM na zaatakowanym systemem aby przywołać LV) mount -t ext4 /dev/sdXN /mnt

f) Przejdź do /mnt/var/log/katalogu i sprawdź kernel.logplik. To powinno dać ci wystarczającą ilość informacji, aby dowiedzieć się, czy panika występuje w przypadku konkretnego modułu lub czegoś innego.

Czy twój procesor jest podkręcony? Ten sam problem miałem dzisiaj, kiedy grałem z mnożnikiem w menu przetaktowywania w moim BIOSie; spowodowałyby to różne mnożniki około 20x. Zmniejszyłem go do 18,5x (3,7 GHz) i problem zniknął; Myślę, że to był problem z płytą główną / zasilaniem.

Zdecydowanie problem z procesorem, zwróć uwagę na wiersze, które mówią: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Błąd sprzętowy]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 APIC 1 mikrokod 28. Procesor 0 to jądro użyte do przetworzenia awarii. (ma znaczenie w systemach z wieloma procesorami), a gniazdo 0 jest szkodliwym procesorem (choć zakładam, że masz tylko 1). Albo jest zły, albo, jak zauważyłeś, podkręconą przyczyną błędów. Wiem, że powiedziałeś, że przeszedłeś przez prime95, ale ponieważ nie mam więcej informacji na temat tego, ile lat ma system, chwytam kilka słomek, jak wygląda twoja pasta termiczna i czy sprawdziłeś, czy twój LGA (pod CPU) wygląda dobrze? Mam na myśli wygięte szpilki lub pastę pod LGA. Ponownie po prostu root tutaj powoduje.

Jeśli to nie rozwiąże problemu, możesz użyć sztuczki SMBIOS, aby znaleźć miejsce, w którym panika trafia dokładnie, inna linia (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) to w zasadzie dane SMBIOS, które mogą pokazać, gdzie nastąpiła awaria. Gdy komputer jest uruchomiony, w wierszu poleceń uruchom echo „TSC 539b174de9d ADDR 3fe98d264ebd MISC 1” | sudo mcelog --ascii --dmi, aby uzyskać wyjście, to powie ci, że jest to błąd sprzętowy, a nawet na jakim DIMM przetwarzał, może to wskazywać na wadliwy DIMM lub ścieżkę magistrali, jeśli awaria DIMM przeskakuje z każdym awaria wskazuje jednak na procesor.

Mieliśmy router mikrotik zainstalowany na starym urządzeniu. Wentylator przestał się obracać i spowodował nagrzanie procesora. Router następnie co jakiś czas uruchamia Kernel Panic. Po zmianie wentylatora procesora wszystko poszło dobrze.

Ponieważ przetaktowujesz swój komputer, może to być możliwa przyczyna.