Ядро Linux сможет обнаруживать неисправные ядра ЦП

Ядро Linux получило возможность аккуратнее обрабатывать отказы отдельных ядер процессора. Для обычного пользователя это звучит абстрактно, но за новостью стоит практическая задача: отличить программный сбой от аппаратной деградации и не потерять данные, если CPU начал ошибаться.

Разберём, как Linux обнаруживает проблемы с ядрами, какие инструменты помогают диагностировать железо и что делать, если в журнале появились сообщения об ошибках.

Почему ядра процессора отказывают

Современный CPU — это миллиарды транзисторов, работающих на высоких частотах и температурах. Причины отказов бывают разными: деградация кремния, недостаточное охлаждение, нестабильное питание, ошибки микрокода, разгон или заводской дефект. Некоторые ошибки исправимы (ECC-память, повторная операция), другие приводят к неверным вычислениям.

Для операционной системы это опасно тем, что сбой может выглядеть как случайное падение приложения, повреждение файла или зависание. Если не вести журнал, проблему легко списать на «глючный Linux» и потерять время.

Machine Check и EDAC

На x86 за аппаратные ошибки отвечает подсистема Machine Check Exception (MCE). Ядро читает регистры ошибок и пишет сообщения в журнал. Для памяти и кэша используется EDAC — подсистема, которая показывает исправленные и неисправленные ошибки через sysfs.

dmesg | grep -iE "mce|machine check|hardware error"
journalctl -k -b | grep -iE "mce|edac|corrected|uncorrected"
ls /sys/devices/system/edac/

Если сообщений нет, это ещё не значит, что железо идеально: часть ошибок не логируется или скрыта прошивкой. Для регулярного мониторинга ставят rasdaemon, который собирает MCE и EDAC в базу и умеет показывать статистику.

sudo apt install rasdaemon
sudo systemctl enable --now rasdaemon
ras-mc-ctl --status
ras-mc-ctl --errors

Как понять, что виноват CPU

Симптомы аппаратной проблемы: случайные падения разных приложений, ошибки сегментации в стабильном ПО, повреждённые архивы после распаковки, зависания под нагрузкой, разные результаты одинаковых вычислений. Программный баг обычно воспроизводится, аппаратный — плавает.

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

sensors
lscpu | grep -E "Model name|MHz|CPU\(s\)"
cpupower frequency-info
journalctl -k -b | grep -iE "thermal|throttl|mce"

Проверьте микрокод: производители выпускают обновления, исправляющие ошибки CPU. В Debian/Ubuntu пакеты называются intel-microcode и amd64-microcode.

sudo apt install intel-microcode
# или
sudo apt install amd64-microcode
dmesg | grep -i microcode

Стресс-тесты и память

Нагрузочные тесты помогают воспроизвести проблему, но не гарантируют её обнаружение. Запускайте их на машине, которую не боитесь перезагрузить, и следите за температурой.

sudo apt install stress-ng
stress-ng --cpu 0 --cpu-method all --timeout 300s --metrics-brief
# проверка памяти (требует перезагрузки в memtest)
sudo apt install memtester
sudo memtester 4G 3

Для памяти надёжнее Memtest86+ с загрузочной флешки: он проверяет адреса, недоступные из работающей системы. Один проход ничего не доказывает; для диагностики нужно несколько часов или ночь.

Если ошибки появляются только под нагрузкой и только на одном ядре, попробуйте временно отключить его и повторить тест. Это не лечение, но помогает локализовать проблему.

# отключить ядро cpu7 (до перезагрузки)
echo 0 | sudo tee /sys/devices/system/cpu/cpu7/online
cat /sys/devices/system/cpu/online

Что делает ядро

При фатальной аппаратной ошибке ядро может изолировать проблемное ядро или аварийно завершить работу, чтобы не допустить повреждения данных. Новые механизмы позволяют аккуратнее обрабатывать такие события и оставлять больше информации для диагностики. Но никакая программная логика не «лечит» деградировавший кремний: она лишь выигрывает время и снижает риск.

Для серверов важна интеграция с BMC/IPMI: ошибки CPU и памяти видны в логах управления, а замена железа планируется до отказа. Для домашней машины достаточно следить за журналом и не игнорировать повторяющиеся ошибки.

Практический план действий

1. Зафиксируйте симптомы и время: что запускалось, какая температура, какие сообщения.
2. Обновите BIOS/UEFI и микрокод, сбросьте разгон.
3. Проверьте охлаждение и питание, продуйте радиаторы.
4. Прогоните Memtest86+ и стресс-тест CPU.
5. Сравните поведение с отключённым подозрительным ядром.
6. Если ошибки повторяются — планируйте замену CPU или материнской платы.

Не откладывайте резервное копирование: нестабильный CPU может испортить файлы тихо, без сообщений об ошибках.

Что это значит для обычного пользователя

Большинству домашних машин новые механизмы обнаружения не понадобятся: современный CPU работает годами без аппаратных ошибок. Но если вы видите в журнале повторяющиеся MCE, нестабильность под нагрузкой или случайные падения, новость — повод отнестись к этому серьёзно, а не переустанавливать систему.

Практический минимум: обновляйте микрокод, следите за температурой, не игнорируйте странные ошибки в dmesg и держите резервные копии. Для домашней лаборатории полезно раз в месяц просматривать journalctl -k -p err: это занимает минуту, но помогает заметить деградацию до потери данных.

Если машина на гарантии и ошибки подтверждаются тестами, сохраните логи и обратитесь в поддержку производителя. «Само пройдёт» — не работает, когда речь идёт о кремнии.

Итог

Обнаружение неисправных ядер CPU — это не магия, а работа с журналами MCE/EDAC, микрокодом, охлаждением и стресс-тестами. Ядро Linux даёт инструменты, но интерпретировать их должен администратор. Если ошибки повторяются, не списывайте их на софт: проверьте железо, сохраните данные и только потом меняйте конфигурацию.