Визначення причини паніки ядра Linux

Я використовую похідне Ubuntu 12.04 (amd64) і останнім часом у мене виникли дуже дивні проблеми. Зовнішній вигляд, здавалося б, X на деякий час повністю застигне (1-3 хвилини?), І тоді система перезавантажиться. Ця система розігнана, але дуже стабільна, як перевірено в Windows, що призводить до того, що у мене виникає паніка з ядром або проблема з одним із моїх модулів. Навіть в Linux я можу запустити LINPACK і не побачу збоїв, незважаючи на смішні навантаження на процесор. Здається, збої трапляються випадковим чином, навіть коли машина сидить у режимі очікування.

Як я можу налагоджувати те, що дає збій у системі?

Зважаючи на те, що це може бути власний драйвер 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 у повноекранному режимі і дозволю йому повторити деякий час або прокручувати тонну GIF-файлів і з’явиться повідомлення Skype, іноді воно вийде з ладу. Повністю чухаю голову на цьому.

Процесор розігнаний до 4,8 ГГц, але він повністю стабільний і пережив величезні запуски LINPACK та 9 годин Prime95 вчора без жодного збою.

Оновлення

Я встановив 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 виводить 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

Якісь ідеї?

У мене є дві пропозиції для початку.

Перше, що вам не сподобається. Якою б стабільною ви не вважаєте вашу розігнану систему, це був би мій перший підозрюваний. І будь-який розробник, про який ви повідомляєте про проблему, скаже те саме. Ваша стабільна тестова завантаженість не обов'язково використовує одні й ті ж інструкції, підкреслюючи підсистему пам’яті стільки, скільки завгодно. Зупиніть розгін. Якщо ви хочете, щоб люди вірили, що проблема не розгонуться, тоді це зробить, коли не буде розгону, щоб ви могли отримати чистий звіт про помилку. Це призведе до величезної різниці в тому, скільки зусиль вкладуть інші люди у вирішення цієї проблеми. Наявність програмного забезпечення без помилок - це гордість, але повідомлення людей з особливо сумнівними налаштуваннями апаратних засобів розчаровують час, який, ймовірно, зовсім не пов’язаний з реальною помилкою.

Друга - отримати дані oops, які, як ви вже помітили, не переходять ні в одне з згаданих вами місць. Якщо збій трапляється лише під час запуску X11, я думаю, що локальна консоль значно виходить (це все одно біль), тому це потрібно робити через послідовну консоль, через мережу або зберегти на локальному диску (що складніше, ніж це може звучати, оскільки ви не хочете, щоб ненадійне ядро ​​псувало вашу файлову систему). Ось кілька способів зробити це:

• використовувати netdump для збереження на сервері по мережі. Я цього не робив роками, тому я не впевнений, що це програмне забезпечення все ще існує і працює з сучасними ядрами, але це досить просто, що варто його зняти.
• завантаження за допомогою послідовної консолі ; вам знадобиться безкоштовний послідовний порт на обох машинах (будь то старий шкільний або USB-послідовний адаптер) та нульовий модемний кабель; ви налаштували іншу машину для збереження результатів.
• kdump, здається, є тим, що класні діти сьогодні використовують, і здається досить гнучким, хоча це не буде моїм уподобанням, оскільки він виглядає складною для налаштування. Коротше кажучи, це передбачає завантаження іншого ядра, яке може робити все, що завгодно, і перевіряти вміст пам'яті колишнього ядра, але ви, по суті, повинні будувати весь процес, і я не бачу там багато консервованих варіантів. Оновлення: насправді є деякі приємні речі дистрибуції; на Ubuntu, linux-crashdump

Як тільки ви отримаєте інформацію про налагодження, з'явиться інструмент під назвою ksymoops, за допомогою якого ви можете перетворити адреси в імена символів і почати отримувати уявлення про збій вашого ядра. І якщо символізований дамп для вас нічого не означає, принаймні, про це щось корисне, щоб повідомити тут або, можливо, про список розсилки / трекер помилок вашого дистрибутива Linux.

Від crashна вашому crashdump, ви можете спробувати друкувати logі btотримати трохи більше інформації (то реєструється під час паніки і стека трасування). Ви , Fatal Machine checkздається, приходить від сюди , хоча. Від знежирення коду ваш процесор повідомив про машинне виняток - апаратну проблему. Знову ж таки, моя перша ставка буде пов’язана з розгоном. Здається, у logвиході може бути більш конкретне повідомлення, яке могло б вам сказати більше.

Також з цього коду виглядає, що якщо ви завантажуєтесь із mce=3параметром ядра, він перестане збиватися ... але я б не рекомендував це, окрім діагностичного кроку. Якщо ядро ​​Linux вважає, що цю помилку варто усунути, можливо, це правильно.

a) Перевірте, чи повідомлення у ядрі вноситься у файл файлом rsyslog

vi /etc/rsyslog.conf

І додайте наступне

kern.*                 /var/log/kernel.log

Перезапустіть rsyslogслужбу.

/etc/initd.d/rsyslog restart

б) Візьміть на замітку завантажені модулі

`lsmod >/your/home/dir`

в) Оскільки паніка не може бути відтворена, зачекайте, коли це станеться

г) Після виникнення паніки завантажте систему за допомогою живого або аварійного компакт-диска

е) Змонтуйте файлові системи (зазвичай / буде досить , якщо / вар і / будинку є не окремі файлові системи) ураженої системи ( pvs, vgs, lvsкоманди повинні бути запущені , якщо ви використовуєте LVM на вразливою системі , щоб відкрити LV) mount -t ext4 /dev/sdXN /mnt

f) Перейдіть до /mnt/var/log/каталогу та перевірте kernel.logфайл. Це повинно дати вам достатньо інформації, щоб зрозуміти, чи виникає паніка для певного модуля чи чогось іншого.

Чи розігнаний ваш процесор? У мене була така сама проблема сьогодні, коли я грав у множнику в меню перезарядки в моєму BIOS; різні множники близько 20 разів спричинили б це. Я зменшив його до 18,5x (3,7 ГГц), і проблема пішла; Я думаю, це була проблема материнської плати / живлення.

Виразно проблема процесора, зверніть увагу на рядки, у яких написано: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Помилка апаратури]: ПРОЦЕСОР 0: 206a7 Час 1357862746 SOCKET 0 Мікрокод APIC 1 28. Процесор 0 - це те, що ядро ​​використовується для обробки аварії. (має значення в мультипроцесорних системах) і socket 0 - це процесор, який порушує (хоча я припускаю, що у вас є лише 1). Або це погано, або, як ви зазначили, причина розбитості. Я знаю, ви сказали, що ви взяли це через prime95, але оскільки я не маю більше інформації про те, скільки років в системі, я захоплюю кілька соломинок, як виглядає ваша термопаста, і чи перевірили ви, щоб переконатися, що ваш LGA (під ЦП) виглядає добре? Я думаю, можливо, зігнуті шпильки або якась паста під LGA. Знову просто причиною тут.

Якщо це не вдається вирішити проблему, є невелика хитрість, яку ви можете скористатися SMBIOS, щоб знайти, де саме паніка потрапляє, інший рядок (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) - це в основному дані SMBIOS, які можуть показувати, де стався збій. Коли ваша машина піднята, у командному рядку запустіть ехо "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi, щоб отримати вихід, це скаже вам, що це апаратна помилка і навіть те, що DIMM він обробляв, це може вказувати на несправний DIMM або шину шляху, якщо поломка DIMM стрибає з кожним крах, однак, це вказує на процесор.

У нас був встановлений маршрутизатор mikrotik на старій установці. Вентилятор перестав обертатися і викликати нагрівання процесора. Тоді маршрутизатор час від часу запускає Kernel Panic. Після зміни вентилятора процесора все пішло добре.

Оскільки ви розгоняєте вашу машину, це може стати причиною.