Определение причины паники ядра Linux

Я использую производную Ubuntu 12.04 (amd64), и у меня недавно были действительно странные проблемы. По всей видимости, внезапно X на некоторое время полностью замерзнет (1-3 минуты?), А затем система перезагрузится. Эта система разогнана, но очень стабильна, как проверено в Windows, что наводит меня на мысль, что у меня паника ядра или проблема с одним из моих модулей. Даже в Linux я могу запустить LINPACK и не увидеть сбоя, несмотря на то, что нагрузка на процессор оказывается нелепой. Кажется, что аварии случаются в случайные моменты времени, даже когда машина бездействует.

Как я могу отладить то, что сбивает систему?

Предполагая, что это может быть проприетарный драйвер NVIDIA, я полностью вернулся к стабильной версии драйвера, версии 304, и до сих пор испытываю сбой.

Может ли кто-нибудь провести меня через хорошую процедуру отладки после сбоя? Я был бы более чем счастлив загрузить загрузочный диск и опубликовать все мои файлы конфигурации после сбоя, я просто не уверен, какими они будут. Как я могу узнать, что сбивает мою систему?

Вот куча бревен, обычные преступники.

.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

Я даже не могу найти запись об аварии вообще.

Вызвать сбой не так просто, кажется, что это происходит, когда графический процессор пытается нарисовать несколько вещей одновременно. Если я выложу видео на 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 выводит обратную трассировку:

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

Любые идеи?

У меня есть два предложения для начала.

Первое, что вам не понравится. Независимо от того, насколько стабильной вы считаете вашу разогнанную систему, это будет моим первым подозреваемым. И любой разработчик, которому вы сообщаете о проблеме, скажет то же самое. Ваша стабильная рабочая нагрузка на тестирование не обязательно использует одни и те же инструкции, что сильно влияет на подсистему памяти. Прекратите разгон. Если вы хотите, чтобы люди поверили, что проблема не в разгоне, сделайте это, когда не разгон, чтобы вы могли получить чистый отчет об ошибке. Это будет иметь огромное значение в том, сколько усилий другие люди будут инвестировать в решение этой проблемы. Наличие программного обеспечения без ошибок является предметом гордости, но сообщения людей с особенно сомнительными аппаратными настройками расстраивают время, которое, вероятно, вообще не связано с реальной ошибкой.

Второй - получить данные об ошибках, которые, как вы заметили, не попадают ни в одно из мест, которые вы упомянули. Если сбой происходит только во время работы X11, я думаю, что локальная консоль практически отсутствует (в любом случае, это боль), поэтому вам нужно сделать это через последовательную консоль, по сети или путем сохранения на локальный диск (что сложнее, чем это может звучать, потому что вы не хотите, чтобы ненадежное ядро ​​повредило вашу файловую систему). Вот несколько способов сделать это:

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

Как только вы получите отладочную информацию, есть инструмент под названием ksymoops, который вы можете использовать, чтобы превратить адреса в имена символов и начать понимать, как работает ваше ядро. И если символический дамп ничего не значит для вас, по крайней мере, об этом полезно сообщить здесь или, возможно, в списке рассылки / отслеживателе ошибок вашего дистрибутива Linux.

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

Также из этого кода, похоже, что если вы загрузитесь с mce=3параметром ядра, он перестанет падать ... но я бы не рекомендовал это, кроме как в качестве диагностического шага. Если ядро ​​Linux считает, что эта ошибка заслуживает сбоя, возможно, это правильно.

а) Проверьте, записываются ли сообщения ядра в файл демоном rsyslog

vi /etc/rsyslog.conf

И добавьте следующее

kern.*                 /var/log/kernel.log

Перезапустите rsyslogсервис.

/etc/initd.d/rsyslog restart

б) Запишите загруженные модули

`lsmod >/your/home/dir`

в) Поскольку паника не воспроизводима, подождите, пока она не произойдет

d) Как только возникла паника, загрузите систему с живого или аварийного компакт-диска.

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

е) Зайдите в /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 - это то, что ядро ​​использовало для обработки сбоя (имеет значение в системах с несколькими процессорами), и сокет 0 является нарушающим процессором (хотя я предполагаю, что у вас есть только 1). Либо это плохо, либо, как вы заметили, разгон является причиной неисправностей. Я знаю, что вы сказали, что прошли через prime95, но поскольку у меня нет больше информации о том, сколько лет системе, я хватаю несколько соломинок, как выглядит ваша термопаста, и проверили ли вы, чтобы убедиться, что ваш LGA (под CPU) выглядит хорошо? Я думаю, может быть, согнутые булавки или немного пасты под LGA. Опять корень здесь вызывающий.

Если это не помогает решить проблему, есть небольшой трюк, который вы можете сделать, чтобы использовать SMBIOS, чтобы точно определить, где именно возникает паника, другая строка (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) - это, в основном, данные SMBIOS, которые могут показать, где произошел сбой. Когда ваша машина включена, в командной строке запустите команду «TSC 539b174de9d ADDR 3fe98d264ebd MISC 1» | sudo mcelog --ascii --dmi для получения выходных данных, это скажет вам, что это аппаратная ошибка, и даже то, на каком DIMM он обрабатывался, это может указывать на неисправный DIMM или шинный путь, если сбой DIMM перепрыгивает с каждым сбой, однако, это указывает на процессор.

У нас на старом оборудовании был установлен микротик роутер. Вентилятор перестал вращаться, что привело к нагреву процессора. Маршрутизатор тогда начинает Kernel Panic время от времени. После смены вентилятора процессора все прошло хорошо.

Поскольку вы разгоняете свою машину, это может быть возможной причиной.