Menentukan penyebab panik kernel Linux

Saya menjalankan turunan Ubuntu 12.04 (amd64) dan saya mengalami masalah yang sangat aneh baru-baru ini. Tiba-tiba, sepertinya, X akan membeku sepenuhnya untuk sementara waktu (1-3 menit?) Dan kemudian sistem akan reboot. Sistem ini di-overclock, tetapi sangat stabil seperti yang diverifikasi di Windows, yang membuat saya percaya saya mengalami kepanikan kernel atau masalah dengan salah satu modul saya. Bahkan di Linux, saya bisa menjalankan LINPACK dan tidak akan melihat crash walaupun memuat CPU yang konyol. Kecelakaan tampaknya terjadi pada waktu yang acak, bahkan ketika mesin tidak digunakan.

Bagaimana saya bisa men-debug apa yang menabrak sistem?

Pada firasat bahwa itu mungkin driver NVIDIA berpemilik, saya kembali sepenuhnya ke versi stabil driver, versi 304 dan saya masih mengalami kecelakaan.

Adakah yang bisa menuntun saya melalui prosedur debugging yang baik untuk setelah crash? Saya akan sangat senang untuk boot ke thumb drive dan memposting semua file konfigurasi post-crash saya, saya tidak yakin akan seperti apa mereka nantinya. Bagaimana saya bisa mengetahui apa yang menabrak sistem saya?

Berikut adalah sekelompok log, biang keladinya.

.xsession-errors : 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

Aku bahkan tidak bisa menemukan catatan kecelakaan sama sekali.

Memicu crash tidak sesederhana itu, tampaknya terjadi ketika GPU mencoba untuk menggambar banyak hal sekaligus. Jika saya memasang video YouTube dalam layar penuh dan membiarkannya diulang untuk sementara waktu atau menggulir banyak ton GIF dan pemberitahuan Skype muncul, terkadang itu akan macet. Benar-benar menggaruk kepalaku yang satu ini.

CPU-nya di-overclock ke 4,8GHz, tetapi benar-benar stabil dan telah bertahan menjalankan LINPACK yang sangat besar dan 9 jam dari Prime95 kemarin tanpa crash.

Memperbarui

Saya telah menginstal kdump,, crashdan linux-crashdump, juga simbol debug kernel untuk versi kernel 3.2.0-35. Ketika saya menjalankan apport-unpackfile kernel yang crash dan kemudian crashpada VmCorecrash crash, inilah yang saya lihat:

      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)

Ketika saya menjalankan logdari crashutilitas, saya melihat ini di bagian bawah log:

[ 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 menampilkan backtrace:

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

Ada ide?

Saya punya dua saran untuk memulai.

Yang pertama Anda tidak akan suka. Tidak peduli seberapa stabil Anda berpikir sistem overclock Anda, itu akan menjadi tersangka pertama saya. Dan setiap pengembang yang Anda laporkan masalah akan mengatakan hal yang sama. Beban kerja pengujian Anda yang stabil tidak harus menggunakan instruksi yang sama, menekankan subsistem memori sebanyak apa pun. Hentikan overclocking. Jika Anda ingin orang-orang percaya bahwa masalahnya bukan overclocking, maka wujudkan ketika tidak overclocking sehingga Anda bisa mendapatkan laporan bug yang bersih. Ini akan membuat perbedaan besar dalam berapa banyak upaya orang lain akan berinvestasi dalam menyelesaikan masalah ini. Memiliki perangkat lunak bebas bug adalah hal yang membanggakan, tetapi laporan dari orang-orang dengan pengaturan perangkat keras yang dipertanyakan membuat frustrasi time-sinks yang mungkin tidak melibatkan bug nyata sama sekali.

Yang kedua adalah untuk mendapatkan data oops, yang karena Anda perhatikan tidak pergi ke salah satu tempat yang Anda sebutkan. Jika crash hanya terjadi saat menjalankan X11, saya pikir konsol lokal cukup banyak (itu menyakitkan), jadi Anda perlu melakukan ini melalui konsol serial, melalui jaringan, atau dengan menyimpan ke disk lokal (yang lebih sulit daripada mungkin terdengar karena Anda tidak ingin kernel yang tidak dapat dipercaya merusak sistem file Anda). Berikut ini beberapa cara untuk melakukan ini:

• gunakan netdump untuk menyimpan ke server melalui jaringan. Saya belum melakukan ini selama bertahun-tahun, jadi saya tidak yakin perangkat lunak ini masih ada dan bekerja dengan kernel modern, tetapi cukup mudah sehingga layak dicoba.
• boot menggunakan konsol serial ; Anda memerlukan porta serial gratis di kedua mesin (baik yang lama atau adaptor serial USB) dan kabel modem null; Anda akan mengkonfigurasi mesin lain untuk menyimpan output.
• kdump tampaknya menjadi apa yang digunakan anak-anak keren saat ini, dan tampaknya cukup fleksibel, meskipun itu bukan pilihan saya karena kelihatannya rumit untuk diatur. Singkatnya, ini melibatkan mem-boot kernel yang berbeda yang dapat melakukan apa saja dan memeriksa isi memori kernel lama, tetapi Anda pada dasarnya harus membangun seluruh proses dan saya tidak melihat banyak opsi kalengan di luar sana. Pembaruan: Sebenarnya ada beberapa hal yang menarik; di Ubuntu, linux-crashdump

Setelah Anda mendapatkan info debug, ada alat bernama ksymoops yang dapat Anda gunakan untuk mengubah alamat menjadi nama simbol dan mulai mendapatkan ide bagaimana kernel Anda mengalami crash. Dan jika dump yang disimbolkan tidak berarti apa-apa bagi Anda, setidaknya ini adalah sesuatu yang bermanfaat untuk dilaporkan di sini atau mungkin di milis / pelacak bug distribusi Linux Anda.

Dari crashpada crashdump Anda, Anda dapat mencoba mengetik logdan btuntuk mendapatkan informasi lebih banyak (hal-hal yang dicatat selama panik dan stack backtrace). Kamu Fatal Machine checksepertinya datang dari sini . Dari membaca kode, prosesor Anda telah melaporkan Pengecualian Pemeriksaan Mesin - masalah perangkat keras. Sekali lagi, taruhan pertama saya adalah karena overclocking. Sepertinya mungkin ada pesan yang lebih spesifik di logoutput yang bisa memberi tahu Anda lebih banyak.

Juga dari kode itu, sepertinya jika Anda boot dengan mce=3parameter kernel, itu akan berhenti macet ... tapi saya tidak akan benar-benar merekomendasikan ini kecuali sebagai langkah diagnostik. Jika kernel Linux berpikir kesalahan ini layak untuk dihancurkan, itu mungkin benar.

a) Periksa apakah pesan kernel sedang di-log ke file oleh rsyslog daemon

vi /etc/rsyslog.conf

Dan tambahkan yang berikut ini

kern.*                 /var/log/kernel.log

Mulai ulang rsysloglayanan.

/etc/initd.d/rsyslog restart

b) Catat modul yang dimuat

`lsmod >/your/home/dir`

c) Karena kepanikan tidak dapat direproduksi, tunggu sampai itu terjadi

d) Setelah kepanikan terjadi, boot sistem menggunakan CD langsung atau darurat

e) Pasang filesystem (biasanya / akan cukup jika / var dan / home tidak sistem file terpisah) dari sistem yang terkena dampak ( pvs, vgs, lvsperintah harus dijalankan jika Anda menggunakan LVM pada sistem terpengaruh untuk membuka LV) mount -t ext4 /dev/sdXN /mnt

f) Pergi ke /mnt/var/log/direktori dan periksa kernel.logfile. Ini akan memberi Anda informasi yang cukup untuk mencari tahu apakah panik terjadi untuk modul tertentu atau sesuatu yang lain.

Apakah prosesor Anda di-overclock? Saya memiliki masalah yang sama hari ini ketika saya bermain dengan pengali dalam menu over-clocking di BIOS saya; berbagai pengganda sekitar 20x akan menyebabkan ini terjadi. Saya menguranginya menjadi 18,5x (3,7GHz) dan masalahnya hilang; Saya pikir itu adalah masalah motherboard / daya.

Paling jelas masalah prosesor, perhatikan baris yang mengatakan: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Kesalahan Perangkat Keras]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 APIC 1 mikrokode 28. Prosesor 0 adalah apa yang digunakan kernel untuk memproses crash. (Masalah dalam sistem multi-CPU) dan soket 0 adalah prosesor yang menyinggung (meskipun saya menganggap Anda hanya memiliki 1). Entah itu buruk atau seperti yang Anda catat karena overclock karena kesalahan. Saya tahu Anda mengatakan Anda membawanya melalui prime95 tetapi karena saya tidak memiliki informasi lebih lanjut tentang berapa umur sistem ini saya meraih beberapa sedotan, bagaimana tampilan pasta termal Anda, dan Anda telah memeriksa untuk memastikan LGA Anda (di bawah CPU) terlihat baik-baik saja? Saya berpikir mungkin pin tertekuk atau pasta di bawah LGA. Sekali lagi hanya root yang menyebabkan di sini.

Jika itu gagal untuk memperbaiki masalah, ada sedikit trik yang dapat Anda lakukan untuk menggunakan SMBIOS Anda untuk menemukan di mana kepanikan tepat, garis lain (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) pada dasarnya adalah data SMBIOS yang dapat menunjukkan di mana kecelakaan itu terjadi. Saat mesin Anda dinyalakan, dalam menjalankan baris perintah, gema "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi untuk mendapatkan output, ini akan memberitahu Anda itu adalah kesalahan perangkat keras dan bahkan apa DIMM yang sedang diproses, ini dapat menunjuk ke DIMM atau jalur bus yang rusak, jika kegagalan DIMM melompat-lompat dengan setiap crash, ini menunjuk ke CPU.

Kami memiliki router mikrotik yang diinstal pada rig lama. Kipas berhenti berputar dan menyebabkan prosesor memanas. Router kemudian mulai dengan Panic Kernel setiap sekarang dan kemudian. Setelah mengganti kipas CPU, semuanya berjalan dengan baik.

Karena Anda overclocking mesin Anda, itu bisa menjadi penyebab yang mungkin.