Linux çekirdek paniğinin nedenini belirleme

Bir Ubuntu 12.04 türevi (amd64) kullanıyorum ve son zamanlarda çok garip sorunlar yaşıyorum. Görünüşe göre, mavi dışında, X bir süre boyunca tamamen donacak (1-3 dakika?) Ve sonra sistem yeniden başlatılacaktır. Bu sistem overclocklu, ancak Windows'ta doğrulandığı gibi çok kararlı, bu da benim modüllerimden biriyle ilgili bir çekirdek panik veya sorun yaşadığına inanmamı sağlıyor. Linux'ta bile LINPACK'i çalıştırabilirim ve CPU'ya saçma yük getirmesine rağmen bir çökme görmeyeceğim. Makine boşta otururken bile çarpışmalar rastgele zamanlarda meydana gelir.

Sistemi çökerten şeyi nasıl ayıklayabilirim?

Özel NVIDIA sürücüsü olabileceğine dair bir ipucu olarak, sürücünün kararlı sürümüne, sürüm 304'e kadar geri döndüm ve hala çarpışmayı deneyimliyorum.

Biri bir kazadan sonra iyi bir hata ayıklama prosedüründen geçebilir mi? Başparmak sürücüde önyükleme yapmak ve tüm çarpışma sonrası yapılandırma dosyalarımı göndermek için çok mutlu olurum, ne olacağından emin değilim. Sistemimi neyin çökertdiğini nasıl öğrenebilirim?

Her zamanki suçluların bir sürü günlükleri.

.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

Kazanın bir kaydını bile bulamıyorum.

Kazayı tetiklemek o kadar kolay değil, GPU bir kerede birden fazla şey çizmeye çalışırken ortaya çıkıyor. Bir YouTube videosunu tam ekrana yerleştirip bir süre tekrar etmeme izin verirsem veya bir ton GIF'de gezinirken bir Skype bildirimi açılırsa, bazen çökecektir. Bu konuda kafamı tamamen tırmalamak.

İşlemci 4.8GHz'e overclock edildi, ancak tamamen kararlı ve büyük bir LINPACK çalışması ve dün 9 saat Prime95'te tek bir çarpışma olmadan hayatta kaldı.

Güncelleştirme

Ben yükledim kdump, crashve linux-crashdumpyanı sıra benim çekirdek sürümü 3.2.0-35 için çekirdek ayıklama sembolleri. Ben çalıştırdığınızda apport-unpacküzerinde çekirdek dosyasını çöktü ve sonra crashüzerine VmCoreçökme dökümü, burada gördüğüm budur:

      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)

Ben çalıştırdığınızda loggelen crashfayda, ben günlüğüne altındaki bu bkz:

[ 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 backtrace çıktılar:

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

Herhangi bir fikir?

Başlamak için iki önerim var.

İlk sevmeyeceksin. Overclock sisteminizin ne kadar istikrarlı olduğunu düşünüyorsan, ilk şüphelim olur. Ve sorunu bildirdiğiniz herhangi bir geliştirici de aynı şeyi söyleyecektir. Kararlı test iş yükünüz mutlaka aynı talimatları kullanmaz, bellek alt sistemini ne kadar zorlarsa o kadar zorlamaz. Hızaşırtmayı durdur. İnsanların sorunun overclock yapmadığına inanmalarını istiyorsanız, o zaman overclock yapmadığınızda bunu yapın, böylece temiz bir hata raporu alabilirsiniz. Bu, diğer insanların bu problemi çözmek için ne kadar çaba harcayacağı konusunda büyük bir fark yaratacaktır. Hatasız yazılıma sahip olmak gurur vericidir, ancak özellikle şüpheli donanım kurulumlarına sahip kişilerin raporları, muhtemelen gerçek bir hata içermeyen sinir bozucu zaman alıcılardır.

İkincisi, fark ettiğiniz gibi bahsettiğiniz yerlerden hiçbirine gitmeyen oops verilerini almaktır. Kilitlenme yalnızca X11 çalışırken gerçekleşirse, yerel konsolun hemen hemen dışarıda kaldığını düşünüyorum (yine de bir acıdır), bu yüzden bunu seri bir konsol üzerinden, ağ üzerinden veya yerel diske kaydederek yapmanız gerekir (ki bu daha zordur. kulağa hoş gelmeyebilir, çünkü güvenilmez bir çekirdeğin dosya sisteminizi bozmasını istemezsiniz). Bunu yapmanın bazı yolları:

• kullanmak NetDump ağ üzerinden bir sunucuya kaydetmek için. Bunu yıllardır yapmadım, bu yüzden hala bu yazılımın modern çekirdeklerle çalıştığından ve çalıştığından emin değilim, ancak bir çekim yapmaya değecek kadar kolay.
• seri konsol kullanarak önyükleme ; Her iki makinede (eski okulda veya USB seri adaptörde) ücretsiz bir seri bağlantı noktasına ve boş bir modem kablosuna ihtiyacınız olacak; çıktıyı kaydetmek için diğer makineyi yapılandırırsınız.
• kdump , bugünlerde havalı çocukların kullandığı şey gibi görünüyor ve oldukça esnek gözüküyor, ancak benim tercihim olmasa da, kurulumu karmaşık görünüyor. Kısacası, her şeyi yapabilen ve önceki çekirdeğin bellek içeriğini inceleyen farklı bir çekirdeğin önyüklenmesini içerir, ancak esasen tüm süreci oluşturmalısınız ve orada çok fazla konserve seçeneği göremiyorum. Güncelleme: Aslında bazı güzel dağıtım şeyleri var; Ubuntu'da, linux-crashdump

Hata ayıklama bilgisini aldıktan sonra , adresleri sembol adlarına dönüştürmek ve çekirdeğinizin nasıl düştüğü hakkında bir fikir edinmek için kullanabileceğiniz ksymoops adlı bir araç var . Ve sembolize edilen çöplük sizin için bir şey ifade etmiyorsa, en azından bu, burada veya belki de Linux dağıtımınızın posta listesi / hata takipçisinde bildirmek için yararlı bir şeydir.

Gönderen crashsenin crashdump üzerine, yazmaya deneyebilirsiniz logve btbiraz daha fazla bilgi (işler panik ve yığın dökümü sırasında günlüğe) alır. Sizin Fatal Machine checkden geliyor gibi görünüyor burada olsa. Kodu gözden geçirmeden, işlemciniz bir Makine Kontrolü İstisnası - donanım sorunu bildirdi . Yine, ilk bahsim hız aşırtma yüzünden olacaktı. logÇıktıda size daha fazla bilgi verebilecek daha spesifik bir mesaj olabilir gibi görünüyor .

Ayrıca, bu koddan, mce=3çekirdek parametresiyle önyükleme yaparsanız , çökmesini durduracak gibi görünüyor ... ancak tanılama aşaması dışında bunu gerçekten tavsiye etmem. Eğer Linux çekirdeği bu hatanın çökmeye değer olduğunu düşünüyorsa, muhtemelen doğrudur.

a) Çekirdek mesajlarının bir dosyaya rsyslog daemon tarafından kaydedilip kaydedilmediğini kontrol edin.

vi /etc/rsyslog.conf

Ve aşağıdakileri ekleyin

kern.*                 /var/log/kernel.log

rsyslogHizmeti yeniden başlatın .

/etc/initd.d/rsyslog restart

b) Yüklenen modülleri not alın

`lsmod >/your/home/dir`

c) Panik tekrarlanabilir olmadığından, gerçekleşmesini bekleyin

d) Panik gerçekleştiğinde, sistemi canlı veya acil durum CD'si kullanarak önyükleyin

ve / home ayrı dosya sistemleri değilse / var e) dosya sistemlerini monte (genellikle / etkilenen sistemin) yeterli olacaktır ( pvs, vgs, lvskomutlar LV getirmek için etkilenen sistemde LVM kullanıyorsanız çalıştırılması gerekir) mount -t ext4 /dev/sdXN /mnt

f) /mnt/var/log/Dizine gidin ve kernel.logdosyayı kontrol edin . Bu, panikin belirli bir modül veya başka bir şey için olup olmadığını anlamak için yeterli bilgiyi sağlamalıdır.

İşlemciniz overclock edildi mi? Bugün aynı sorunu, BIOS'umun over-clocking menüsünde çarpan ile oynarken; 20x civarında çeşitli çarpanlar bunun olmasına neden olur. Onu 18.5x'e (3.7GHz) düşürdüm ve sorun çözüldü; Bir anakart / güç sorunu olduğunu düşünüyorum.

Kesinlikle bir işlemci sorunu, şunu söyleyen satırlara dikkat edin: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Donanım Hatası]: İŞLEMCİ 0: 206a7 ZAMAN 1357862746 SOCKET 0 APIC 1 mikro kod 28 (çok cpu sistemlerinde önemlidir) ve soket 0 rahatsız edici işlemcidir (yalnızca 1'iniz olduğunu varsayalım). Ya kötüdür ya da overclock edildiğini not ettiğiniz gibi hatalara neden olabilir. Bunu çoktan geçirdiğini söylediğini biliyorum95 ama sistemin kaç yaşında olduğu hakkında daha fazla bilgim olmadığından, birkaç pipete kapılıyorum, termal macun nasıl görünüyor ve LGA'nızdan emin olmak için kontrol ettiniz mi? CPU) iyi görünüyor? LGA'nın altına iğne ya da biraz bükülmüş olabilir. Yine sadece burada neden kök.

Bu sorunu çözmezse, panik tam olarak nerede isabet edeceğini bulmak için SMBIOS'unuzu kullanmak için yapabileceğiniz küçük bir hile varsa, başka bir satır (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) temel olarak çökmenin nerede olduğunu gösterebilecek SMBIOS verisidir. Makineniz çalışırken komut satırında "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi çıktı almak için, bu bir donanım hatası olduğunu ve ne DIMM üzerinde çalıştığını bile söyleyecektir, bu, DIMM hatası her ile birlikte atlarsa, hatalı bir DIMM veya veri yolu yolunu gösterebilir Ancak çöküyor, bu CPU'yu gösteriyor.

Eski bir teçhizata monte edilmiş bir mikrotik yönlendiricimiz vardı. Fan dönmeyi durdurdu ve işlemcinin ısınmasına neden oldu. Yönlendirici daha sonra her zaman Kernel Panik'e başlar ve sonra. CPU fanını değiştirdikten sonra her şey yolunda gitti.

Makinenizi overclock yaptığınız için olası bir sebep olabilir.