ใครที่ทำให้เคอร์เนลของฉันเสียหาย


4

อาการ

ทันใดนั้นมีข้อความว่า "ตรวจพบปัญหาในแพ็คเกจเคอร์เนล" ปรากฏขึ้นหลังจากที่ฉันเข้าสู่ระบบเมื่อบูต ข้อความใหม่จะปรากฏขึ้นทุกวินาทีไม่หยุดหย่อน (การแปลด้านล่าง)

ป้อนคำอธิบายรูปภาพที่นี่

การแปล :

รายงานปัญหาแล้ว

ตรวจพบปัญหาในแพ็คเกจเคอร์เนล

ฉันไม่รู้ว่าสิ่งใดที่ทำให้ข้อความเหล่านี้ปรากฏ ฉันจะรับรายละเอียดเกี่ยวกับระบบล่มได้อย่างไร

รายละเอียด

ฉันไม่ได้อัปเดตเคอร์เนลในช่วง 12 วันที่ผ่านมา (3.19.7-200.fc21.x86_64) การบูตจากเคอร์เนลที่เก่ากว่าจะไม่หยุดคำเตือน

ฉันได้ติดตั้ง 5 แพ็คเกจใหม่วันนี้: subversion-1.8.11-1.fc21.x86_64, gitk-2.1.0-4.fc21.noarch, git-gui-2.1.0-4.fc21.noarch, subversion-libs- 1.8.11-1.fc21.x86_64 และ libserf-1.3.7-2.fc21.x86_64

ฉันได้ติดตั้ง gnome extension เล็กน้อย แต่ฉันใช้มันสองสามชั่วโมงโดยไม่มีปัญหาก่อนทำการรีบูต ฉันปิดการใช้งานส่วนขยายและปัญหายังคงอยู่

สิ่งที่ฉันพยายาม

abrtผมเชื่อว่าข้อความแจ้งเตือนเหล่านี้เป็นส่วนหนึ่งของ แต่เมื่อฉันพยายามรับรายละเอียดเพิ่มเติมabrt-cli listไม่แสดงอะไรเลยสำหรับเดือนปัจจุบัน

dmesg ไม่แสดงสิ่งที่น่าสงสัย (หรือฉันอาจตีความผิดฉันจะโพสต์บันทึก)

เป็นข้อเสนอแนะเกี่ยวกับการแสดงความคิดเห็นผมตรวจสอบ/var/log/messages, /var/log/syslogและ/var/log/kern.log:

สองหลังไม่อยู่ tail /var/log/messagesมีจำนวนมาก (มากกว่าหนึ่งพัน) ต่อไปนี้ซ้ำแล้วซ้ำอีกครั้ง (ด้วยการประทับเวลาที่แตกต่างกัน):

May 26 16:39:28 [hostname] abrt-dump-journal-oops: Reported 1 kernel oopses to Abrt
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Found oopses: 1
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Creating problem directories
May 26 16:39:30 [hostname] abrt-server: Deleting problem directory oops-2015-05-26-16:39:30-585-0 (dup of oops-2015-04-28-15:49:00-21380-1)
May 26 16:39:30 [hostname] gnome-session: abrt-applet: repeated problem in kernel, not showing the notification

ปัญหาที่ตรวจพบที่ 2015-04-28-15: 49: 00 ผ่านabrt-cli listคือ:

id dadaa8ca8525cf44b21c438b086cc731ac73c2cd
reason:         WARNING: CPU: 0 PID: 21350 at fs/block_dev.c:67 bdev_inode_switch_bdi+0x87/0x90()
time:           Ter 28 Abr 2015 15:49:02 BRT
cmdline:        BOOT_IMAGE=/boot/vmlinuz-3.19.3-100.fc20.x86_64 root=UUID=45f0c704-ada0-411d-95ba-50169ce0994a ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole$
package:        kernel
count:          1529
Directory:  /var/tmp/abrt/oops-2015-04-28-15:49:00-21380-1
Relatado:   https://retrace.fedoraproject.org/faf/reports/bthash/392cacbf6958e88053298dbce758bf6865c4db3f

2
คุณสามารถเริ่มต้นโดยการดูที่บันทึกใน/var/logรวมทั้งmessages, และsyslog kern.log
Faheem Mitha

2
นอกจากนี้อาจเกี่ยวข้องกับ: bugzilla.redhat.com/show_bug.cgi?id=1167001
Derobert

คำตอบ:


2

แรกของทุกเคอร์เนลของคุณไม่ได้ล้มเหลว หากระบบล่มระบบของคุณจะหยุดทำงานอย่างสมบูรณ์และคุณจะไม่สามารถใช้งานได้

มีปัญหาหลายประเภทที่อาจเกิดขึ้นในเคอร์เนล

  • เตือน (เตือน) ข้อผิดพลาด (BUG) หรือOOPSสามารถเกิดขึ้นเมื่อเคอร์เนลที่สร้างขึ้นในการตรวจสอบด้วยตนเองตรวจสอบสถานการณ์ที่อาจนำไปสู่ความไม่แน่นอนของระบบหรือการสูญหายของข้อมูลในอนาคต อย่างไรก็ตามโดยทั่วไปปัญหาเหล่านี้ไม่ได้ทำให้ระบบล่ม (ทันที) โดยทั่วไปแล้ว OOPSes นั้นรุนแรงที่สุดและจะนำไปสู่กระบวนการ userpace ที่เกี่ยวข้องที่ได้รับสัญญาณSIGKILL("เจ้าจะต้องตาย" ไม่ใช่ "โปรดหายไป") จากเคอร์เนล

  • ความตื่นตระหนกเป็นที่ที่ระบบจะทยอยเพื่อที่จะปฏิเสธที่จะไป นี่คือที่เคอร์เนลเพียงแค่หยุดการดำเนินการ (หลังจากพิมพ์การติดตามสแต็คถ้ามันสามารถทำเช่นนั้น) และผลผลิตควบคุม .... ไม่มีอะไร มักจะ แม้ว่าคุณจะมีเคอร์เนลที่ขัดข้องแต่บางครั้งเคอร์เนลที่เสียหายจะพยายามโหลดเคอร์เนลตัวที่สองซึ่งมีวัตถุประสงค์เพื่อรวบรวมข้อมูลเกี่ยวกับสาเหตุของความผิดพลาดและลองเขียนลงดิสก์ โดยทั่วไปแล้วมันเป็นไปไม่ได้ที่แม้แต่เคอร์เนลที่มีข้อผิดพลาดที่แข็งแกร่งมากในการกู้คืนสถานะของระบบอย่างเต็มที่เพื่อให้สามารถใช้งานได้และมีเสถียรภาพอีกครั้งโดยไม่ต้องรีบูตเครื่อง

ในใจของฉันเป็นความผิดพลาดเป็นตรงกันกับความหวาดกลัว มีหลายสถานการณ์ที่ a WARNหรือBUGสามารถเพิกเฉยได้อย่างปลอดภัยโดยมีความน่าจะเป็นน้อยที่ข้อมูลจะสูญหาย หากระบบของคุณยังคงทำงานหลังจากรายงาน "ปัญหา" เหล่านี้มันก็แทบจะไม่ต้องตกใจ

คุณไม่ได้ให้บันทึก (โดยเฉพาะอย่างยิ่งdmesg) ให้ฉันพอที่จะบอกเหตุผลของความผิดพลาดนี้ได้ แต่โดยทั่วไปเมื่อเคอร์เนลรายงานปัญหาตัวเองมันจะแสดงให้เห็นในdmesgบัฟเฟอร์วงแหวนเคอร์เนล เรียกใช้งานคำสั่งdmesgบนคอนโซลเพื่อดูบัฟเฟอร์วงแหวนเคอร์เนล

ดูเหมือนว่าในกรณีของคุณคุณอาจเคยเจอโอ๊ะโอที่ถูกจัดการโดยabrtระบบแจ้งเตือนเหตุการณ์ผิดพลาดอย่างไม่ถูกต้อง(หรือโครงสร้างพื้นฐานส่วนติดต่อผู้ใช้ของ GNOME ที่แสดงให้คุณเห็น)

26 พฤษภาคม 16:39:30 segtic-1c505e gnome-session: abrt-applet: ปัญหาซ้ำ ๆ ในเคอร์เนลไม่แสดงการแจ้งเตือน

ดังนั้นจึงคิดว่ามันไม่ได้แสดงให้คุณเห็นเพราะเป็นปัญหาซ้ำแล้วซ้ำอีก แต่ก็ยังส่งผลให้คุณมีข้อผิดพลาดเหมือนเดิม ดังนั้นอาจabrt-applet คิดว่ามันไม่ใช่การทิ้งระเบิดคุณ แต่กำลังทำอยู่ดีหรือมีโปรแกรมอื่นที่จัดการข้อผิดพลาดของเคอร์เนล (อาจเป็นแอปเพล็ตอื่นที่เกี่ยวข้องกับabrt?) ที่ตรวจไม่พบปัญหาซ้ำ ๆ และกระแทกคุณด้วยโปรแกรมเดียวกัน เกิน.

ดังนั้นจึงมีปัญหาหลายอย่างที่นี่:

  1. คุณยังไม่ได้ให้dmesgบันทึกใด ๆที่บ่งบอกถึงปัญหาซ้ำ ๆ สิ่งที่คุณแสดงให้เห็นว่า ACPI อาจเป็นสาเหตุของข้อผิดพลาดหนึ่งข้อ แต่สิ่งนั้นเกิดขึ้นตั้งแต่เริ่มแรกในการบู๊ตและมันก็ไม่ได้เกิดขึ้นซ้ำแล้วซ้ำอีก

  2. ดูเหมือนว่าโครงสร้างพื้นฐานการรายงานข้อผิดพลาดเสีย ฉันคิดว่าในบางระดับabrt รู้ว่ามันเป็นข้อความซ้ำสำหรับเหตุการณ์เดียวกัน (หรือลำดับของเหตุการณ์อิสระที่เหมือนกันในสาเหตุ) แต่อย่างใดการแจ้งเตือนจะได้รับผ่านระบบและ UI ของคุณอย่างไรก็ตาม

  3. เห็นได้ชัดว่ามันเป็นปัญหาที่คุณมีชนิดของความผิดพลาดหรือ OOPS หรือข้อบกพร่องบางส่วนหรือเตือนที่เกี่ยวข้องกับลินุกซ์ในสถานที่แรก แต่เนื่องจากบันทึกของเคอร์เนลที่คุณโพสต์มีน้อยและไม่เกี่ยวข้องโดยเฉพาะรากของปัญหาดูเหมือนจะเข้าใจยากในตอนนี้ หากมีการร้องเรียนเกี่ยวกับปัญหา ACPI จากการบู๊ตตอนต้นควรเรียนรู้ที่จะปิดเครื่อง ความจริงก็คือเมนบอร์ด ACPI DSDTs มักจะถูกทำลายและน่ากลัวและระบบปฏิบัติการก็ต้องเรียนรู้ที่จะจัดการกับสิ่งที่ดีที่สุดเท่าที่จะทำได้ ไม่มีสิ่งใดที่คุณสามารถทำได้ในฐานะผู้ใช้ปลายทาง ไม่ใช่ว่าผู้ผลิต mobo ของคุณจะยังคงปล่อยการอัปเดต BIOS เพื่อลองและปรับปรุงความถูกต้องของ DSDT ของพวกเขา (ก็เป็นไปได้ยากที่จะทำเช่นนั้น)

หรืออาจจะเป็นปัญหาที่ไม่เกี่ยวข้องกับ ACPI อย่างสมบูรณ์และรายงานปัญหาที่เกิดขึ้นจริงก็ไม่ได้ทำให้มันเป็น kernel ringbuffer นี่อาจเป็นเรื่องที่แปลกจริง ๆ และไม่ใช่สิ่งที่ฉันเคยพบมาก่อน สำหรับเรื่องที่ผมไม่แน่ใจว่าสิ่งที่กลไกที่ใช้ในการตรวจสอบการดำรงอยู่ของข้อผิดพลาดหากยังไม่ได้แยกabrtdmesg

เมื่อพูดถึงปัญหาเกี่ยวกับเคอร์เนลของ Linux และวิธีการรายงานใน UI นั้นไม่ค่อยมีวิธีที่ง่ายในการวินิจฉัย มันเป็นธรรมชาติของสัตว์ร้าย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.