Я использую производную 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
Любые идеи?
источник
tail -f /var/log/kern.logзапустить его и попытаться поймать его таким образом./var/log/kern.log, но теперь изучаюsyslog.Ответы:
У меня есть два предложения для начала.
Первое, что вам не понравится. Независимо от того, насколько стабильной вы считаете вашу разогнанную систему, это будет моим первым подозреваемым. И любой разработчик, которому вы сообщаете о проблеме, скажет то же самое. Ваша стабильная рабочая нагрузка на тестирование не обязательно использует одни и те же инструкции, что сильно влияет на подсистему памяти. Прекратите разгон. Если вы хотите, чтобы люди поверили, что проблема не в разгоне, сделайте это, когда не разгон, чтобы вы могли получить чистый отчет об ошибке. Это будет иметь огромное значение в том, сколько усилий другие люди будут инвестировать в решение этой проблемы. Наличие программного обеспечения без ошибок является предметом гордости, но сообщения людей с особенно сомнительными аппаратными настройками расстраивают время, которое, вероятно, вообще не связано с реальной ошибкой.
Второй - получить данные об ошибках, которые, как вы заметили, не попадают ни в одно из мест, которые вы упомянули. Если сбой происходит только во время работы X11, я думаю, что локальная консоль практически отсутствует (в любом случае, это боль), поэтому вам нужно сделать это через последовательную консоль, по сети или путем сохранения на локальный диск (что сложнее, чем это может звучать, потому что вы не хотите, чтобы ненадежное ядро повредило вашу файловую систему). Вот несколько способов сделать это:
Как только вы получите отладочную информацию, есть инструмент под названием ksymoops, который вы можете использовать, чтобы превратить адреса в имена символов и начать понимать, как работает ваше ядро. И если символический дамп ничего не значит для вас, по крайней мере, об этом полезно сообщить здесь или, возможно, в списке рассылки / отслеживателе ошибок вашего дистрибутива Linux.
От
crashна вашем crashdump, вы можете попробовать печататьlogиbtполучить немного больше информации (то регистрируется во время паники и стека трассировки). Вы ,Fatal Machine checkкажется, приходит от сюда , хотя. После сканирования кода ваш процессор сообщил об исключении проверки компьютера - аппаратная проблема. Опять же, моя первая ставка будет из-за разгона. Кажется, что вlogвыводе может быть более конкретное сообщение, которое может рассказать вам больше.Также из этого кода, похоже, что если вы загрузитесь с
mce=3параметром ядра, он перестанет падать ... но я бы не рекомендовал это, кроме как в качестве диагностического шага. Если ядро Linux считает, что эта ошибка заслуживает сбоя, возможно, это правильно.источник
linux-crashdumpи получить файл аварийного дампа, в котором, как мы надеемся, достаточно информации, чтобы определить причину.а) Проверьте, записываются ли сообщения ядра в файл демоном rsyslog
И добавьте следующее
Перезапустите
rsyslogсервис.б) Запишите загруженные модули
в) Поскольку паника не воспроизводима, подождите, пока она не произойдет
d) Как только возникла паника, загрузите систему с живого или аварийного компакт-диска.
е) Смонтируйте файловые системы (обычно / будет достаточно , если / вар и / дома являются не отдельные файловые системы) пораженной системы (
pvs,vgs,lvsкоманды должны быть запущены , если вы используете LVM на уязвимой системе , чтобы открыть LV)mount -t ext4 /dev/sdXN /mntе) Зайдите в
/mnt/var/log/каталог и проверьтеkernel.logфайл. Это должно дать вам достаточно информации, чтобы выяснить, происходит ли паника для определенного модуля или чего-то еще.источник
kernel.log, поскольку информация журнала должна проходить довольно долгий путь через системный журнал, драйвер файловой системы, дисковый кэш и драйвер диска. Самый простой и элегантный способ - использоватьnetconsoleмодуль ядра.Ваш процессор разогнан? У меня была такая же проблема сегодня, когда я играл с множителем в меню разгона в моем BIOS; Различные множители около 20х могут привести к этому. Я уменьшил его до 18,5x (3,7 ГГц), и проблема ушла; Я думаю, что это была проблема с материнской платой / питанием.
источник
mce=3чтобы предотвратить сбой, но в прошлом я просто увеличивал напряжение каждый раз, когда он падал (что было не так часто). Стоит отметить, что я использую напряжение смещения, которое, вообще говоря, более нестабильно.Наиболее определенно проблема процессора, обратите внимание на строки, которые говорят: 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 время от времени. После смены вентилятора процессора все прошло хорошо.
Поскольку вы разгоняете свою машину, это может быть возможной причиной.
источник