CentOS 7. Kernel panic — not syncing: Fatal machine check on current CPU
linux centos linux
Published: 2017-05-01

Провайдер услуг: ovh

Проц: Intel Xeon D-1521

ОС: CentOS 7.3

Ядро: 3.14 кастомное от ovh

Дело было на майских праздниках. Клиент, держащий сервис, написанный на php и использующий mysql как бд, попросил посмотреть, почему сервер внезапно перестаёт отвечать.

Предположили, что дело может быть в высокой нагрузке и отваливается сеть. Но нет, нагрузка так себе, на интерфейсе максимум 300 pps, трафик низкий, память не кушается, проц процентов на 40% загружен. В процессе выяснилось, что сервер не только перестаёт отвечать, но и сам перезагружается.

Ага! Настраиваем kdump. kdump не запускается на кастомном ядре 3.14 ovh. Ставим ванильное из родных реп

yum install kernel

Пересоздаём конфиг для загрузчика (grub2, да)

grub2-mkconfig -o /boot/grub2/grub.cfg

Грузимся в ванильное ядро, где kdump корректно работает.

Выловились такие ошибки при каждом ребуте

[  617.734479] Disabling lock debugging due to kernel taint
[  617.734483] mce: [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 4: be00000000800400
[  617.734490] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81390207> {intel_idle+0xd7/0x160}
[  617.734491] mce: [Hardware Error]: TSC 22f02fc14382 ADDR ffffffff81390200 MISC ffffffff81390207
[  617.734493] mce: [Hardware Error]: PROCESSOR 0:50663 TIME 1493660122 SOCKET 0 APIC 1 microcode 700000a
[  617.734494] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[  617.754549] mce: [Hardware Error]: Some CPUs didn't answer in synchronization
[  617.754550] mce: [Hardware Error]: Machine check: Processor context corrupt
[  617.754551] Kernel panic - not syncing: Fatal machine check on current CPU

Дело ясное - проблема в процессоре! Пишем в поддержку ovh с описанием проблемы. Нам отвечают, что да, похоже на проблемы с железом, но неплохо бы прогнать тесты, так что загрузитесь по pxe в наш специальный rescue-image и вперёд.

Далаем тесты. 64GB оперативки… ждём…

Тесты говорят нам, что всё в порядке О_О Как так? Нельзя просто заменить проц, чтобы всё было хорошо? Перезагружаем сервер и видим, что centos всё так же продолжает свой kernel panic.

Зато пока гнались тесты, нагуглились похожие проблемы, и, проанализировав их, появилось предположение, в которую нужно копать - питание и частота процессора (ну да, логично)

CPUs didn't answer in synchronization

Идём в БИОС, ищем Advanced Power Management, начинаем читать… EIST и C-STATE позволяют снижать частоты процессора для экономии электроэнергии и уменьшения уровня шума. И они как раз включены. Отключаем.

Ребут. Запуск. Нагрузка. Работает!

Итого, мы имеем ядро, которое не умеет работать с некоторыми функциями относительно новых процессоров intel (D-1521 октябрь 2015). Вероятно, есть способ побороть это со стороны ОС.


Upd.: после сделанных изменений аптайм стал дольше, но внезапные ребуты, хоть и реже, но остались. Поддержка невнятная, онлайн проекту нужен срочно, поэтому клиент переехал на linode.


3.14.32-xxxx-grs-ipv6-643.10.0-514.16.1.el7.x86_644.11.0-1.el7.elrepo.x86_644.4.66-1.el7.elrepo.x86_64
CentOS 7Kernel panic - not syncingKernel panic - not syncingKernel panic - not syncingсм.ниже

[20131.766316] perf interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

[21855.799002] conntrack: generic helper won’t handle protocol 47. Please consider loading the specific helper module.

[66335.445024] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler

Если мне когда-нибудь удастся протестировать с этим процессором, например, ubuntu 16.04.2 с ядром 4.8, то дополню заметку, как она ведёт себя при включённых EIST и C-STATE.

comments powered by Disqus