लिनक्स कर्नेल घबराहट का कारण निर्धारित करना


25

मैं एक Ubuntu 12.04 व्युत्पन्न (amd64) चला रहा हूँ और मैं हाल ही में वास्तव में अजीब मुद्दे रहा हूँ। नीले रंग से, प्रतीत होता है, एक्स थोड़ी देर (1-3 मिनट?) के लिए पूरी तरह से फ्रीज करेगा और फिर सिस्टम रिबूट होगा। यह सिस्टम ओवरक्लॉक किया गया है, लेकिन विंडोज में सत्यापित के रूप में बहुत स्थिर है, जो मुझे विश्वास दिलाता है कि मुझे कर्नेल घबराहट हो रही है या मेरे किसी मॉड्यूल के साथ कोई समस्या है। लिनक्स में भी, मैं लिनपैक चला सकता हूं और सीपीयू पर हास्यास्पद भार डालने के बावजूद दुर्घटना नहीं देखूंगा। जब मशीन बेकार बैठी होती है, तो यादृच्छिक समय पर दुर्घटनाएँ होने लगती हैं।

मैं कैसे डिबग कर सकता हूं जो सिस्टम को क्रैश कर रहा है?

एक कूबड़ पर कि यह मालिकाना NVIDIA ड्राइवर हो सकता है, मैंने सभी तरह के ड्राइवर के स्थिर संस्करण के नीचे संस्करण 304 को वापस कर दिया और मुझे अभी भी दुर्घटना का अनुभव है।

क्या कोई दुर्घटना के बाद किसी अच्छी डिबगिंग प्रक्रिया के माध्यम से मुझसे चल सकता है? मैं एक अंगूठे ड्राइव में बूट करने और अपनी सभी पोस्ट-क्रैश कॉन्फ़िगरेशन फ़ाइलों को पोस्ट करने में अधिक खुश हूं, मुझे यकीन नहीं है कि वे क्या होंगे। मैं कैसे पता लगा सकता हूं कि मेरी प्रणाली क्या दुर्घटनाग्रस्त कर रही है?

यहां लॉग का एक गुच्छा है, सामान्य अपराधी।

.xsession- त्रुटियाँ : 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

मैं भी दुर्घटना का एक रिकॉर्ड खोजने के लिए प्रतीत नहीं कर सकते।

दुर्घटना को ट्रिगर करना इतना आसान नहीं है, ऐसा तब लगता है जब GPU एक ही बार में कई चीजें खींचने की कोशिश कर रहा हो। अगर मैंने पूरी स्क्रीन में YouTube वीडियो डाला और इसे कुछ समय के लिए दोहरा दिया या एक टन GIFs और स्काइप अधिसूचना के माध्यम से स्क्रॉल किया, तो कभी-कभी यह दुर्घटनाग्रस्त हो जाएगा। पूरी तरह से इस पर मेरे सिर खरोंच।

सीपीयू को 4.8GHz पर ओवरक्लॉक किया गया है, लेकिन यह पूरी तरह से स्थिर है और एक ही दुर्घटना के बिना कल के विशाल लिनपैक रन और 9 घंटे प्राइम 95 बच गया है।

अद्यतन करें

मैं स्थापित किया है kdump, crashऔर linux-crashdump, साथ ही मेरी कर्नेल संस्करण 3.2.0-35 के लिए कर्नेल डिबग प्रतीकों। जब मैं apport-unpackदुर्घटनाग्रस्त कर्नेल फ़ाइल पर चलता हूं और फिर क्रैश डंप crashपर होता है, तो VmCoreमैं यहां देखता हूं:

      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)

जब मैं उपयोगिता logसे चलाता हूं crash, तो मैं इसे लॉग के नीचे देखता हूं:

[ 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 बैकट्रीम आउटपुट:

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

कोई विचार?


3
क्या आप बाइनरी ब्लॉब ग्राफिक्स ड्राइवर का उपयोग कर रहे हैं?
जोर्डनम j

हाँ, NVIDIA। वहाँ कहीं मैं उस के लिए लॉग मिल सकता है?
Naftuli Kay

क्या रिबूट के बाद / घबराने वाले संदेश / invar/log/kern.log या syslog में हैं? आप दूसरे पीसी से लॉग इन कर सकते हैं और एक tail -f /var/log/kern.logरनिंग कर सकते हैं और इसे इस तरह से पकड़ने की कोशिश कर सकते हैं।
ott--

कुछ भी नहीं दिखा /var/log/kern.log, लेकिन अब देख रहा है syslog
Naftuli Kay

मैंने अपने NVIDIA ड्राइवर को 304 स्थिर पर डाउनग्रेड किया है जो एक बहुत पुराना ड्राइवर है और मैं अभी भी दुर्घटना देख रहा हूं। विवरण के साथ ओपी अपडेट करें।
नातुल्ली काय

जवाबों:


35

मेरे पास शुरू करने के लिए दो सुझाव हैं।

पहला जिसे आप पसंद नहीं करने जा रहे हैं। कोई फर्क नहीं पड़ता कि आप अपने ओवरक्लॉक सिस्टम को कितना स्थिर समझते हैं, यह मेरा पहला संदेह होगा। और कोई भी डेवलपर जिस समस्या की रिपोर्ट करता है आप वही बात कहेंगे। आपका स्थिर परीक्षण कार्यभार जरूरी नहीं कि एक ही निर्देशों का उपयोग कर रहा हो, मेमोरी सबसिस्टम को जितना अधिक हो, उतना ही जोर देना। ओवरक्लॉकिंग बंद करो। यदि आप चाहते हैं कि लोग इस समस्या पर विश्वास करें कि ओवरक्लॉकिंग नहीं है, तो ऐसा तब करें जब ओवरक्लॉकिंग न करें ताकि आप एक साफ बग रिपोर्ट प्राप्त कर सकें। इससे बहुत फर्क पड़ेगा कि दूसरे लोग इस समस्या को हल करने में कितना प्रयास करेंगे। बग-मुक्त सॉफ्टवेयर होना गर्व की बात है, लेकिन विशेष रूप से संदिग्ध हार्डवेयर सेटअप वाले लोगों की रिपोर्ट समय-सिंक को निराश कर रही है जो संभवत: एक वास्तविक बग को शामिल नहीं करते हैं।

दूसरा है ऊप्स डेटा प्राप्त करना, जो आपने देखा है कि आपके द्वारा बताए गए स्थानों में से किसी पर नहीं जाता है। यदि दुर्घटना केवल X11 चलाते समय होती है, तो मुझे लगता है कि स्थानीय कंसोल बहुत अधिक बाहर है (यह वैसे भी एक दर्द है), इसलिए आपको इसे सीरियल कंसोल पर, नेटवर्क पर, या स्थानीय डिस्क पर सहेजने की आवश्यकता है (जो की तुलना में मुश्किल है) यह ध्वनि हो सकता है क्योंकि आप अपने फाइल सिस्टम को भ्रष्ट करने के लिए एक अविश्वसनीय कर्नेल नहीं चाहते हैं)। यह करने के कुछ तरीके इस प्रकार हैं:

  • नेटवर्क पर सर्वर पर सहेजने के लिए netdump का उपयोग करें । मैंने वर्षों में ऐसा नहीं किया है, इसलिए मुझे यकीन नहीं है कि यह सॉफ़्टवेयर अभी भी आसपास है और आधुनिक गुठली के साथ काम कर रहा है, लेकिन यह काफी आसान है कि यह एक शॉट के लायक है।
  • एक सीरियल कंसोल का उपयोग करके बूट ; आपको दोनों मशीनों (चाहे एक पुराना स्कूल एक या एक यूएसबी सीरियल एडाप्टर) और एक शून्य मॉडेम केबल पर एक सीरियल पोर्ट की आवश्यकता होगी; आप आउटपुट को बचाने के लिए दूसरी मशीन को कॉन्फ़िगर करेंगे।
  • kdump लगता है कि आजकल शांत बच्चे क्या उपयोग करते हैं, और यह काफी लचीला लगता है, हालांकि यह मेरी प्राथमिकता नहीं होगी क्योंकि यह स्थापित करने के लिए जटिल लगता है। संक्षेप में, इसमें एक अलग कर्नेल को बूट करना शामिल है जो कुछ भी कर सकता है और पूर्व कर्नेल की मेमोरी सामग्री का निरीक्षण कर सकता है, लेकिन आपको अनिवार्य रूप से पूरी प्रक्रिया का निर्माण करना होगा और मुझे वहाँ बहुत सारे डिब्बाबंद विकल्प दिखाई नहीं देंगे। अपडेट: वास्तव में कुछ अच्छी डिस्ट्रो चीजें हैं; Ubuntu पर, linux-crashdump

डिबग जानकारी प्राप्त करने के बाद, ksymoops नामक एक उपकरण होता है जिसका उपयोग आप पते को नामों में बदलने के लिए कर सकते हैं और यह जानना शुरू कर सकते हैं कि आपका कर्नेल दुर्घटनाग्रस्त कैसे हुआ। और अगर प्रतीकात्मक डंप का आपके लिए कोई मतलब नहीं है, तो कम से कम यह आपके लिनक्स वितरण की मेलिंग सूची / बग ट्रैकर पर रिपोर्ट करने में मददगार है।


से crashअपने क्रैशडंप पर, इससे आप लिखना कोशिश कर सकते हैं logऔर btकुछ और जानकारी (बातें आतंक और एक आईएसपी नामों के दौरान लॉग इन) प्राप्त करने के लिए। आपका यहाँFatal Machine check से आ रहा है , यद्यपि लगता है। कोड को स्किम करने से, आपके प्रोसेसर ने मशीन चेक एक्सेप्शन - एक हार्डवेयर समस्या की सूचना दी है। फिर से, ओवरक्लॉकिंग के कारण मेरी पहली शर्त होगी। ऐसा लगता है कि logआउटपुट में एक अधिक विशिष्ट संदेश हो सकता है जो आपको अधिक बता सकता है।

उस कोड से भी, ऐसा लगता है कि यदि आप mce=3कर्नेल पैरामीटर के साथ बूट करते हैं , तो यह क्रैश होना बंद हो जाएगा ... लेकिन मैं वास्तव में नैदानिक ​​चरण के अलावा इसे सुझा नहीं सकता। अगर लिनक्स कर्नेल को लगता है कि यह त्रुटि खत्म होने के लायक है, तो यह शायद सही है।


यदि ओवरक्लॉक समस्या है, तो मैं क्रैश लॉग में एक घड़ी चक्र को याद कर पाऊंगा, इसलिए दिन के अंत में, मुझे पता चल जाएगा कि समस्या क्या है। यह मेरा लक्ष्य है: यह पता लगाना कि क्या गलत है। अगर यह मेरा ओवरक्लॉक है, तो ठीक है, मैं सिर्फ यह जानना चाहूंगा कि समस्या क्या है
नातुल्ली काय

1
मुझे नहीं लगता कि ओवरक्लॉकिंग विफलताओं के रूप में स्पष्ट है कि लॉग में हाजिर करने के लिए; मैं एक प्रोसेसर विशेषज्ञ नहीं हूं, लेकिन यह ऐसा नहीं है कि पूरे प्रोसेसर घड़ी चक्र को सही ढंग से संभालता है या ओएस को किसी तरह इंगित करता है कि यह चूक गया। मुझे बताएं कि क्या आपको लॉग्स प्राप्त करने में परेशानी है, लेकिन आईएमएचओ को यह जानने का सबसे आसान तरीका है कि क्या यह ओवरक्लॉकिंग समस्या है, यह देखना है कि क्या ओवरक्लॉकिंग नहीं होने पर ऐसा होता है।
स्कॉट लैंब

ठीक है, मैं अपनी सेटिंग्स का बैकअप लेने के बाद ऐसा करूंगा। मैं सबसे पहले यह देख सकता हूं कि क्या मैं विंडोज में दुर्घटना को पुन: उत्पन्न कर सकता हूं।
नातुल्ली काय

जब मैं लिनक्स में कभी बीएसओडी का सामना नहीं करने के लिए आभारी हूं, तो मुझे यह अजीब लगेगा कि जब विंडोज लॉग इन करेगा और एक समस्या प्रदर्शित करेगा, तो लिनक्स नहीं कर पाएगा।
नातुलि काय

1
मैंने प्रश्न को अपडेट कर दिया है, क्योंकि मैं मशीन को चलाते समय दुर्घटनाग्रस्त होने linux-crashdumpऔर क्रैश डंप फ़ाइल प्राप्त करने में सक्षम था, जो उम्मीद है कि कारण निर्धारित करने के लिए पर्याप्त जानकारी है।
नातुल्ली केय

5

a) rsyslog डेमन द्वारा कर्नेल संदेशों को फ़ाइल में लॉग इन किया जा रहा है या नहीं इसकी जाँच करें

vi /etc/rsyslog.conf

और निम्नलिखित जोड़ें

kern.*                 /var/log/kernel.log

rsyslogसेवा को पुनरारंभ करें ।

/etc/initd.d/rsyslog restart

बी) लोड किए गए मॉड्यूल का ध्यान रखें

`lsmod >/your/home/dir`

ग) चूंकि घबराहट प्रजनन योग्य नहीं है, इसलिए इसके होने की प्रतीक्षा करें

घ) एक बार घबराहट होने के बाद, सिस्टम को लाइव या आपातकालीन सीडी का उपयोग करके बूट करें

ई) प्रभावित प्रणाली के फाइल सिस्टम (आमतौर पर / पर्याप्त होगा यदि / var और घर अलग फाइल सिस्टम नहीं हैं) माउंट करें ( pvs, यदि आपको LV लाने के लिए प्रभावित सिस्टम पर LVM का उपयोग कर रहे हैं vgs, तो lvsकमांड चलाने की जरूरत है) mount -t ext4 /dev/sdXN /mnt

च) /mnt/var/log/निर्देशिका में जाएँ और kernel.logफ़ाइल की जाँच करें । यह आपको यह पता लगाने के लिए पर्याप्त जानकारी देनी चाहिए कि क्या किसी विशेष मॉड्यूल या कुछ और के लिए आतंक हो रहा है।


उस से लॉग परिणाम बहुत अनिर्णायक हैं: pastebin.com/VdYAHgiH
Naftuli Kay

2
मेरे अनुभव के अनुसार, कर्नेल क्रैश शायद ही कभी होता है kernel.log, क्योंकि लॉग जानकारी में syslog, filesystem ड्राइवर, डिस्क कैश और डिस्क ड्राइवर के माध्यम से बहुत लंबा रास्ता तय करना पड़ता है। सबसे सरल और सुंदर तरीका netconsoleकर्नेल मॉड्यूल का उपयोग करना है ।
dma_k

2

क्या आपका प्रोसेसर ओवरक्लॉक किया गया है? आज मेरे पास यही मुद्दा था जब मैं अपने BIOS में ओवर-क्लॉकिंग मेनू में गुणक के साथ खेल रहा था; 20x के आसपास विभिन्न गुणक ऐसा होने का कारण बनेंगे। मैंने इसे घटाकर 18.5x (3.7GHz) कर दिया और समस्या दूर हो गई; मुझे लगता है कि यह एक मदरबोर्ड / पावर इश्यू था।


2
हाँ, यह सब कुछ ओवरक्लॉकिंग के साथ करना था। जाहिर है, विंडोज कुछ प्रोसेसर दोषों के साथ थोड़ा अधिक दोष-सहिष्णु लगता है, अगर सीपीयू जा सकता है। मैं mce=3दुर्घटनाग्रस्त होने से बचाने के लिए बूट करना शुरू कर सकता हूं , लेकिन अतीत में, मैंने हर बार दुर्घटनाग्रस्त होने पर (जो अक्सर ऐसा नहीं होता) वोल्टेज बढ़ाया है। नोट करने के लिए कुछ है कि मैं एक ऑफसेट वोल्टेज का उपयोग कर रहा हूं, जो आमतौर पर अधिक अस्थिर बोल रहा है।
नातुल्ली काय

1

सबसे निश्चित रूप से एक प्रोसेसर मुद्दा, लाइनों को नोटिस करें जो कहते हैं: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [हार्डवेयर त्रुटि]: PROCESSOR 0: 20677 TIME 1357862746 SOCKET 0 APIC 1 माइक्रोकोड 28। प्रोसेसर 0 वह है जो कर्नेल को संसाधित करने के लिए प्रयोग किया जाता है। (मल्टी-सीपीयू सिस्टम में मामले) और सॉकेट 0 आपत्तिजनक प्रोसेसर है (हालांकि मुझे लगता है कि आपके पास केवल 1 है)। या तो यह खराब है या जैसा कि आपने उल्लेख किया है कि दोषों के लिए ओवरक्लॉक किया गया है। मुझे पता है कि आपने कहा था कि आपने इसे प्राइम 95 के माध्यम से लिया है, लेकिन चूंकि मुझे इस बात की अधिक जानकारी नहीं है कि मैं कितने पुराने सिस्टम में हूँ, मैं कुछ तिनकों को पकड़ रहा हूँ, आपका थर्मल पेस्ट कैसा दिखता है, और क्या आपने अपने एलजीए के तहत यह सुनिश्चित करने के लिए जाँच की है सीपीयू) ठीक लग रहा है? मैं सोच रहा हूँ शायद LGA के तहत पिन या कुछ पेस्ट को झुका दिया जाए। फिर से बस यहाँ कारण।

यदि यह समस्या को ठीक करने में विफल रहता है, तो थोड़ी सी चाल है जो आप अपने SMBIOS का उपयोग करने के लिए कर सकते हैं, जहां यह पता लगाने के लिए कि आतंक वास्तव में कैसे हिट होता है, एक और लाइन (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1 मूल रूप से SMBIOS डेटा है जो दिखा सकता है कि दुर्घटना कहां हुई है। जब आपकी मशीन चालू होती है, कमांड लाइन रन में, "टीएससी 539b174de9d ADDR 3fe98d264ebd MISC 1" प्रतिध्वनि करें। sudo mcelog --ascii --dmi आउटपुट प्राप्त करने के लिए, यह आपको बताएगा कि यह एक हार्डवेयर त्रुटि है और यहां तक ​​कि DIMM जिस पर यह प्रोसेस कर रहा था, यह एक दोषपूर्ण DIMM या बस पथ को इंगित कर सकता है, यदि DIMMM हर जगह से कूदता है हालाँकि, यह सीपीयू को इंगित करता है।


0

हमारे पास एक पुरानी रिग पर मिक्रोटिक राउटर स्थापित था। प्रशंसक ने घूमना बंद कर दिया और जिससे प्रोसेसर गर्म हो गया। राउटर तब कर्नेल पैनिक के लिए शुरू होता है। सीपीयू फैन बदलने के बाद सबकुछ ठीक हो गया।

चूँकि आप अपनी मशीन को ओवरक्लॉक कर रहे हैं, यह एक संभावित कारण हो सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.