У моей сестры есть ноутбук, который всегда зависал на ней во времена Windows (синий экран) (оборудование относительно новое и современное). Тогда она отправила файлы дампа из Windows в Dell, который отправил инженера, который сменил материнскую плату, но, тем не менее, после настройки Ubuntu во многих различных версиях с использованием множества разных ядер паника не исчезла.
Поэтому я решил предпринять действия, чтобы найти точную причину проблемы. Я установил и настроил пакет linux-crashdump (kdump-tools), чтобы автоматически запускать ядро аварийного отказа, используя kexec, который генерирует файл дампа. памяти, а также хранит вывод dmesg. Я также установил crash, kernel-image-generic-dbgsym и mcelog, чтобы было все, чтобы собрать как можно больше информации.
Таким образом, сбой ноутбука и ядро сбоя успешно сгенерировали файл дампа и сохранили вывод dmesg. Я также проверил / var / log / mcelog, но файл был полностью пуст, хотя демон до запуска работал, что странно, но в конце концов у нас все еще есть вывод dmesg, который гласит:
[ 3933.364173] mce: [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000200135
[ 3933.364177] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff8171d9c2> {_raw_spin_lock+0x12/0x50}
[ 3933.364182] mce: [Hardware Error]: TSC a0255fbd7f7 ADDR 42dd14480 MISC d62285
[ 3933.364185] mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1398357146 SOCKET 0 APIC 1 microcode 15
[ 3933.364186] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 3933.364188] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 3: be00000000200135
[ 3933.364190] mce: [Hardware Error]: RIP !INEXACT! 33:<0000045a7992c1b5>
[ 3933.364191] mce: [Hardware Error]: TSC a0255fbd7f0 ADDR 42dd14480 MISC d62285
[ 3933.364194] mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1398357146 SOCKET 0 APIC 0 microcode 15
[ 3933.364195] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 3933.364196] mce: [Hardware Error]: Machine check: Processor context corrupt
[ 3933.364197] Kernel panic - not syncing: Fatal Machine check
Таким образом, мой первый вопрос будет касаться "Запустите выше через 'mcelog --ascii'" ... что именно я должен запустить там и как? Я пытался, например:
[ 3933.364173] mce: [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000200135 | sudo mcelog --ascii
, который просто ничего не возвращал. Итак, что я должен здесь делать?
Я также запустил
crash /usr/lib/debug/boot/vmlinux<kernelversion> /path/to/crashdump/file
, который запустил программу, как и ожидалось, и я набрал в bt
, чтобы сгенерировать обратную трассировку, которая дала мне:
PID: 0 TASK: ffff8804177617f0 CPU: 6 COMMAND: "swapper/6"
#0 [ffff88042dd89ca0] machine_kexec at ffffffff8104a732
#1 [ffff88042dd89cf0] crash_kexec at ffffffff810e6ab3
#2 [ffff88042dd89db8] panic at ffffffff8170ec6c
#3 [ffff88042dd89e30] mce_panic at ffffffff8103687a
#4 [ffff88042dd89e70] do_machine_check at ffffffff81038684
#5 [ffff88042dd89f50] machine_check at ffffffff8171e25f
[exception RIP: intel_idle+216]
RIP: ffffffff813dfd78 RSP: ffff88041775de28 RFLAGS: 00000046
RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffff81c93220 RDI: 0000000000000006
RBP: ffff88041775de50 R8: ffff88042dd912d0 R9: 000000000000001c
R10: 0000000000000320 R11: 0000000000000249 R12: 0000000000000002
R13: 0000000000000001 R14: 0000000000000001 R15: ffffffff81c932e8
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <MCE exception stack> ---
#6 [ffff88041775de28] intel_idle at ffffffff813dfd78
#7 [ffff88041775de58] cpuidle_enter_state at ffffffff815c9570
#8 [ffff88041775de90] cpuidle_idle_call at ffffffff815c96a9
#9 [ffff88041775ded0] arch_cpu_idle at ffffffff8101ceae
#10 [ffff88041775dee0] cpu_startup_entry at ffffffff810beb85
#11 [ffff88041775df30] start_secondary at ffffffff81040fc8
Подводя итог, я хотел бы знать, как я могу вызвать mcelog
для вывода dmesg и, возможно, какие еще шаги вы предпримете, чтобы получить как можно больше информации о проблеме / найти неисправный компонент, чтобы я мог связаться с поставщиком оборудования, уже имея обоснованное предположение, что не так.
Я знаю, как эта мемчек может помочь мне с большой вероятностью предсказать, что баран не является причиной.
РЕДАКТИРОВАТЬ: Я выяснил, как правильно передать вывод в mcelog: поместите строки вывода перед «Выполнить вышеописанное через« mcelog --ascii »» в файле и вызвать mcelog
с
sudo mcelog --ascii < file
Можно видеть, что сообщение «Run the through through« mcelog --ascii »» печатается два раза в файле dmesg, поэтому я дважды вызывал mcelog, начиная с «CPU» : "и заканчивая строку перед сообщением (я оставил dmesg наподобие" [3933.364173] mce: [Аппаратная ошибка]: "прочь).
Итак, mcelog
говорит мне:
Hardware event. This is not a software error.
CPU 4 BANK 3 TSC a0255fbd7f7
RIP !INEXACT! 10:ffffffff8171d9c2
MISC d62285 ADDR 42dd14480
TIME 1398357146 Thu Apr 24 18:32:26 2014
MCG status:RIPV MCIP
MCi status:
Uncorrected error
Error enabled
MCi_MISC register valid
MCi_ADDR register valid
Processor context corrupt
MCA: Data CACHE Level-1 Data-Read Error
STATUS be00000000200135 MCGSTATUS 5
CPUID Vendor Intel Family 6 Model 58
RIP: _raw_spin_lock+0x12/0x50}
SOCKET 0 APIC 1 microcode 15
и
Hardware event. This is not a software error.
CPU 0 BANK 3 TSC a0255fbd7f0
RIP !INEXACT! 33:45a7992c1b5
MISC d62285 ADDR 42dd14480
TIME 1398357146 Thu Apr 24 18:32:26 2014
MCG status:RIPV MCIP
MCi status:
Uncorrected error
Error enabled
MCi_MISC register valid
MCi_ADDR register valid
Processor context corrupt
MCA: Data CACHE Level-1 Data-Read Error
STATUS be00000000200135 MCGSTATUS 5
CPUID Vendor Intel Family 6 Model 58
SOCKET 0 APIC 0 microcode 15
, при условии, что с материнской платой все в порядке (так как она была изменена), и если ОЗУ в порядке, есть только процессор остался, чтобы быть нарушителем спокойствия, верно? Кто-нибудь знаком со всем приведенным результатом?
Хороший на Вас для выбранного инструментария, это точно, как бежать по проблеме как это.
дампу катастрофического отказа нужны отладочные символы Linux, которые составляют приблизительно 600 МБ за ядро, который является, почему они не установлены по умолчанию. Вот то, как установить и вызвать катастрофический отказ с помощью символов.
https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
Это немного опаздывает в меня в данный момент, чтобы сделать подробно анализ Вашего машинного контроля, но мое начальное впечатление - то, что или кэш на памяти ЦП или оперативная память поставились под угрозу.
я потребовал бы полной гарантийной замены.
, Если это не возможная подкачка поршень, который является недорогим тестом, и если проблема сохраняется, можно быть довольно уверены, что ЦП является источником. В которой точке я серьезно рассмотрел бы компромисс замены ЦП к стоимости нового компьютера.