“बग: सॉफ्ट लॉकअप - सीपीयू # 0 को 17163091968 के लिए कैसे ठीक करें”?

14

अद्यतन: मैंने संदेश का शीर्षक अपडेट किया है, क्योंकि मैंने हाल ही में इस सटीक समय राशि के साथ इनमें से अधिक समस्याएं देखी हैं 17163091968s। इस पृष्ठ को खोजने के लिए लोगों को लक्षणों की जांच करने में मदद करनी चाहिए। नीचे मेरा (स्व-) स्वीकृत उत्तर देखें।

मेरे पास VMware vSphere datacenter में 64-बिट Ubuntu 10.04 LTS VM का एक गुच्छा है। VMware उपकरण स्थापित किए गए हैं (vSphere क्लाइंट "ओके" कहता है)।

मैंने कुछ बार VM के हैंग होने के बाद कुछ समय के बाद syslog में निम्नलिखित त्रुटि देखी है। VSphere से स्थिति की जांच करते समय, कंसोल काला था, और "रिबूट गेस्ट" कमांड ने कुछ भी नहीं किया, इसलिए मुझे वीएम को साइकिल चलाना पड़ा।

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:

(कोई निशान नहीं है - यह अंतिम पंक्ति है।)

मुझे अब अन्य त्रुटियां नहीं लगती हैं, लेकिन मुझे यकीन है कि ऊपर बताई गई प्रक्रिया ( jed) अन्य डंपों में अलग थी।

  • इस समस्या का क्या कारण हो सकता है?

  • इसे होने से कैसे रोका जाए?

कुछ अतिरिक्त जानकारी:

  • मान 17163091988थोड़ा संदिग्ध है (सज़ा का उद्देश्य) - यह 1111111111000000000000000000010100द्विआधारी में है। शायद त्रुटि 20 सेकंड ( 10100बाइनरी में) कहने की कोशिश कर रही थी ?

  • मुझे यकीन नहीं है कि क्या समस्या नवीनतम 10.04 कर्नेल (2.6.32-35) के साथ बनी रहती है।

  • मैंने भी task ... blocked for more than 120 secondsसमस्याओं को देखा है - शायद वे संबंधित हो सकते हैं?

  • vSphere क्लाइंट VM के लिए कोई अलर्ट या माइग्रेशन कार्य नहीं दिखाता है।

ubuntu  central-processing-unit  vmware-vsphere  kernel 
— tuomassalo
स्रोत
शायद कुछ गलत टाइमकीपिंग? आप साथ खेल सकते हैं clocksource। साथ ही सीपीयू की सी-स्टेट्स एक अच्छा अनुमान है।
— SaveTheRbtz

जवाबों:

12

सभी टिप्पणीकारों को धन्यवाद। मुझे लगता है कि मुझे जवाब मिल गया। कम से कम उबंटू के कर्नेल संस्करण 2.6.32-30-सर्वर में टाइमकीपिंग बग प्रतीत होता है। बग कभी-कभी (?) मशीनों को मारता है जब वे लगभग 200..210 दिनों के ऊपर पहुंच जाते हैं। वास्तव में हॉल्ट सीमा समाप्त होने के तुरंत बाद नहीं होता है, लेकिन कुछ ऑपरेशन (मेरे मामले में apt-get install ...) से शुरू होता है।

NB: 200 दिन 2 ^ 32 गुना 1/250 सेकंड के बारे में है, और 250 CONFIG_HZ के लिए डिफ़ॉल्ट मान है।

अभी के लिए, मुझे इस बात का डेटा नहीं मिला है कि क्या समस्या को हाल ही की गुठली में ठीक किया गया है। मुझे पता है कि यह एक पुराने कर्नेल (2.6.32-26-सर्वर) को प्रभावित नहीं करता है। इस सारी जानकारी से मैं यह मान लेता हूं कि यदि यह अभी तक तय नहीं किया गया है, तो इससे बचा जा सकता है:

  • हर 190 दिन मशीनों को बूट करें (कर्नेल उन्नयन के लिए एक अच्छा विचार है)
  • CONFIG_HZ को 100 पर समायोजित करें और इस प्रकार इसे हर 497 दिनों में बनाएं। हालाँकि, इसके काफी अप्रत्याशित दुष्प्रभाव हो सकते हैं, खासकर आभासी वातावरण में। और यह समस्या को हल नहीं करता है।

यहाँ Ubuntu के लिए एक बग रिपोर्ट है।

— tuomassalo
स्रोत
अच्छा लगता है - आश्चर्य है कि अगर यह debian
— thinice
जिज्ञासा से बाहर: क्या आप vmware के माध्यम से NTP या समय तुल्यकालन का उपयोग कर रहे हैं? ऐसा लगता है कि लगातार समय की शिफ्ट या ऐसा कुछ हो सकता है .. वहाँ syslog में समय बदलने की प्रविष्टियों को लॉग किया जाना चाहिए।
— पोटका
मैंने अभी-अभी कुछ देखा जो डेबियन से संबंधित है, 2.6.32-5-amd64 कर्नेल दो नरम लॉक अप दिखा रहा है जो "अजीब" प्रदर्शन कर रहा है
— जेम्स
5

यह वास्तव में एक कर्नेल बग है जिसे निम्नलिखित कर्नेल कमिट द्वारा ठीक किया गया है:

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=4cecf6d401a01d054afc1e5f605bcbfe553cb9b9

आप निम्न शीर्षक के लिए LKML खोज सकते हैं (2 से अधिक लिंक पोस्ट नहीं कर सकते): [स्थिर] 2.6.32.21 - अपटाइम संबंधित क्रैश?

और यह एलपी # बग है जो कर्नेल फिक्स लाता है:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317

ल्यूसिड-अपडेट में नवीनतम कर्नेल को अपग्रेड करना इस मुद्दे को अच्छे के लिए ठीक करना चाहिए।

HTH

— लुई
स्रोत
2

क्या ऐसा हो सकता है कि वर्चुअलाइजेशन होस्ट में कुछ पावर-सेविंग फीचर्स ("ग्रीन आईटी") सक्षम हों, जो अप्रयुक्त कोर को कम-शक्ति / नींद मोड में भेज सकते हैं, जिससे उस कोर का उपयोग करके वीएम में दिलचस्प व्यवधान उत्पन्न हो सकता है? मैंने सुना है कि यह मुख्य रूप से हाइपरवि वातावरण में एक समस्या हुआ करती थी, लेकिन इस पर ध्यान देना चाहिए।

— daff
स्रोत
1

मामले में किसी और को यह पता चलता है, एक कर्नेल उन्नयन मेरे लिए एक समान समस्या तय की। मेरे पास एक जेबीओडी था जो एसएएस 3 नियंत्रक के माध्यम से सिस्टम से जुड़ा था जो इन सीपीयू सॉफ्टलॉक त्रुटियों को बूट पर फेंक रहा था।

मेरे पास Ubuntu 14.04.2 कर्नेल संस्करण 3.16.0-30 था, और "apt -y उन्नयन" करने से मुझे k गिरी 3.16.0-49 पर समाप्त हो गया, और इससे समस्या हल हो गई।

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