Микрокод и kernel cmdline: сценарии для кривого железа
Если железо ведёт себя странно, зависает, не просыпается из сна или роняет драйвер при загрузке, лечи это связкой «свежий микрокод + параметр ядра». Микрокод чинит ошибки процессора, а параметр командной строки заставляет ядро обходить то, что прошивка не умеет. По отдельности они часто не срабатывают, вместе закрывают оба уровня проблемы.
Почему микрокод и параметры ядра работают в связке?
Микрокод это встроенная прошивка процессора, которую ядро загружает при старте. Производитель выпускает обновления, которые чинят реальные ошибки CPU: кривые переходы между C-состояниями, зависания в простое, сбои в новых инструкциях. Параметры ядра работают на другом уровне: они говорят ядру, как обходить кривое железо, не дожидаясь исправления прошивки.
По отдельности не всегда помогает. Микрокод исправляет ошибку процессора, но не меняет поведение драйверов и ACPI. Параметр ядра обходит симптом, но не лечит причину. Классический пример: ноутбук, который не просыпается из сна. Обновлённый микрокод чинит баг C-состояний, а mem_sleep_default=deep заставляет ядро использовать полноценный S3 вместо s2idle. Один без другого даёт лишь половину результата.
Зачем вообще обновлять микрокод и как он попадает в initramfs, разобрано в статье «Микрокоды CPU: зачем и когда».
Как проверить, что микрокод реально загрузился?
До того как крутить параметры, убедись, что микрокод вообще применился:
dmesg | grep "microcode: current"
cat /proc/cpuinfo | grep microcode
Первая команда покажет версию микрокода, которую ядро загрузило при старте. Вторая покажет ту же версию из /proc/cpuinfo. Если микрокод подхватился рано, ещё до старта ядра, в dmesg будет строка microcode: early. Сравни номер ревизии с актуальным: если версия старая, обнови пакет amd-ucode или intel-ucode и перегенерируй initramfs:
sudo mkinitcpio -P
Без этого шага новый микрокод не попадёт в образ, и ядро продолжит грузить старую ревизию.
Что делать, если ноутбук не просыпается из сна?
Симптом: закрыл крышку, через час открыл, а экран не загорается, или система просыпается, но виснет. Частая причина: баг C-состояний в старом микрокоде плюс режим сна s2idle, при котором питание не отключается полностью.
Лечение в два шага. Сначала обнови микрокод. Потом добавь параметр:
GRUB_CMDLINE_LINUX_DEFAULT="quiet mem_sleep_default=deep"
Перегенерируй конфиг:
grub-mkconfig -o /boot/grub/grub.cfg
Проверь, что система реально использует S3:
cat /sys/power/mem_sleep
Если в выводе s2idle [deep], квадратные скобки стоят у deep, значит, параметр работает. Если остался только s2idle, BIOS не отдаёт ядру S3, и тут поможет только настройка прошивки. Заодно глянь dmesg | grep -i cstate: ошибки переходов между состояниями подтверждают диагноз.
Почему зависает AMD Zen 4 в простое?
Симптом: система виснет через несколько минут бездействия, при нагрузке работает стабильно. На процессорах Zen 4 это известная история: старый микрокод неправильно управляет idle-состояниями, а драйвер amd-pstate по умолчанию работает в режиме, который не подходит конкретному экземпляру CPU.
Обнови amd-ucode и добавь один из параметров:
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_pstate=guided"
amd_pstate=guided переводит драйвер управления частотой в режим, где ядро задаёт диапазон частот, а процессор сам выбирает точку внутри. Если зависания остались, попробуй amd_pstate=active: там ядро управляет частотами напрямую. На новых процессорах один из этих режимов обычно стабильнее дефолтного.
Ядерный вариант, если ничего не помогло:
GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1"
Это запрещает процессору уходить в глубокие C-состояния. Зависания в простое исчезнут, но потребление энергии вырастет, а частота может просесть. Используй processor.max_cstate=1 только для подтверждения диагноза, потом сузь проблему до конкретного C-состояния.
Что делать, если гибернация на Intel зависает при пробуждении?
Симптом: systemctl hibernate отрабатывает, но при включении система не возвращается: чёрный экран или вечная загрузка. Причин две: старый микрокод с багом в глубоких C-состояниях и отсутствие параметра resume, из-за которого ядро не находит образ подкачки.
Обнови intel-ucode, добавь resume с UUID раздела подкачки:
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=5678-90ab"
UUID подставляй свой, его показывает lsblk -f. В initramfs должен быть хук resume, иначе параметр проигнорируется.
Если зависание осталось, ограничь глубину idle:
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=5678-90ab intel_idle.max_cstate=1"
intel_idle.max_cstate=1 запрещает драйверу intel_idle уводить процессор в глубокие состояния. Это тоже диагностический параметр: если с ним гибернация работает, а без него виснет, проблема в конкретном C-состоянии, и можно подобрать менее жёсткое ограничение вроде intel_idle.max_cstate=4.
Почему видеокарта AMD падает при загрузке?
Симптом: при старте системы экран гаснет, драйвер amdgpu сыплет ошибками в dmesg, или система уходит в чёрный экран сразу после GRUB. Часто виновата не карта, а устаревшая прошивка GPU в пакете linux-firmware.
Сначала обнови прошивки:
sudo pacman -Syu linux-firmware
Что именно обновляется в этом пакете, описано в статье «linux-firmware: что обновляется». Перед обновлением посмотри текущую версию прошивки GPU: dmesg | grep -i firmware. После обновления и перезагрузки версия должна вырасти.
Если не помогло, добавь параметр отладки Display Core:
GRUB_CMDLINE_LINUX_DEFAULT="quiet amdgpu.dcdebugmask=0x10"
amdgpu.dcdebugmask=0x10 отключает часть функций подсистемы дисплея и включает расширенное логирование. Это не постоянное решение, а способ выяснить, какой именно блок DC роняет карту. Собери логи из dmesg, найди виновника и либо обнови прошивку, либо подбери точечный параметр.
Почему старый ноутбук просыпается сам по себе?
Симптом: ноутбук сам выходит из сна, или после сна система ведёт себя нестабильно. На старом железе новый кернел часто конфликтует с кривой ACPI-таблицей из BIOS.
Два проверенных параметра:
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_sleep=nonvs acpi_osi=Linux"
acpi_sleep=nonvs запрещает ядру сохранять и восстанавливать область NVS при переходе в сон, а на некоторых ноутбуках именно это вызывает случайные пробуждения. acpi_osi=Linux заставляет ACPI-код прошивки вести себя как на «настоящей» Linux-системе, что чинит странные реакции на события питания.
Что делать, если сетевая карта нестабильна из-за ASPM?
Симптом: проводная сеть периодически отваливается, пинги скачут, скорость падает до нуля на несколько секунд. На некоторых контроллерах виноват ASPM, механизм энергосбережения шины PCI Express, который криво реализован в прошивке.
GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=off"
pcie_aspm=off полностью отключает энергосбережение PCIe. Сеть стабилизируется, но потребление чуть вырастет. Если отключать ASPM целиком не хочется, попробуй pcie_aspm=performance: он запрещает переходы в энергосберегающие состояния, но оставляет механизм включённым.
Как применить параметры и не сломать загрузку?
Все параметры добавляются одинаково: в /etc/default/grub в строку GRUB_CMDLINE_LINUX_DEFAULT, затем:
grub-mkconfig -o /boot/grub/grub.cfg
Проверяй каждый параметр по одному. В меню GRUB наведись на запись, нажми e, найди строку linux и допиши параметр в конец. Ctrl+X загрузит систему с ним один раз. Если что-то сломалось, просто перезагрузись, конфиг не пострадал. После загрузки проверь, что параметр реально применился:
cat /proc/cmdline
Как GRUB собирает аргументы из разных строк, разобрано в статье «Кастомные аргументы ядра в GRUB». Полный справочник параметров есть в статье «Параметры ядра в командной строке».
Если ты используешь systemd-boot, параметры живут в файле записи в /boot/loader/entries/ в строке options. Там же работает проверка на один запуск: нажми e в меню загрузки, отредактируй строку и запусти запись. Разница между загрузчиками описана в статье «Прямая загрузка ядра через EFISTUB и UKI».
Какие параметры лучше не оставлять навсегда?
processor.max_cstate=1, intel_idle.max_cstate=1, pcie_aspm=off и mitigations=off можно назвать молотками. Они решают проблему, но ценой производительности, энергопотребления или безопасности. Их задача: подтвердить диагноз. Если с параметром всё работает, а без него виснет, значит, проблема локализована. Дальше сужай: пробуй менее жёсткие значения (max_cstate=4 вместо 1), обновляй микрокод и прошивки, ищи свежий кернел. Оставлять молоток навсегда стоит только в крайнем случае.
Частые вопросы
Чем микрокод отличается от параметров ядра?
Микрокод загружается ядром при старте и обновляет прошивку процессора. Параметр ядра говорит самому ядру, как вести себя с железом. Они дополняют друг друга: микрокод чинит ошибку CPU, параметр обходит кривое поведение прошивки.
Как понять, что проблема в микрокоде, а не в параметрах?
Обнови микрокод первым и проверь dmesg | grep "microcode: current". Если версия свежая, а симптом остался, подключай параметры. Если симптом ушёл после обновления микрокода, параметры не нужны.
Параметр сломал загрузку. Что делать?
Перезагрузись, в меню GRUB нажми e, удали проблемный параметр из строки linux и загрузись через Ctrl+X. Конфиг при этом не меняется. Потом поправь /etc/default/grub и перегенерируй grub.cfg.
Сколько параметров можно добавить сразу?
Сколько угодно, но проверяй по одному. Если добавить пять параметров разом и система перестанет грузиться, ты не поймёшь, кто виноват. Один параметр, одна перезагрузка, один вывод.
Ядерные параметры вроде max_cstate=1 опасны?
Не опасны, но дороги: растёт потребление, падает частота. Используй их для диагностики, а не как постоянное решение. После подтверждения диагноза ищи менее жёсткий вариант.
Полезные ресурсы
- Microcode, ArchWiki: установка и ранняя загрузка микрокода.
- Kernel parameters, ArchWiki: полный список параметров и способы их передачи.
- Остановка загрузки: диагностика таймингов: как читать логи загрузки и находить виновника зависаний.
Заключение
Кривое железо лечится связкой «микрокод + параметр ядра»: микрокод чинит ошибки процессора, параметр заставляет ядро обходить то, что прошивка не умеет. Обнови amd-ucode или intel-ucode, добавь один параметр в GRUB_CMDLINE_LINUX_DEFAULT, перегенерируй grub.cfg и проверяй каждый параметр на один запуск через редактирование записи в GRUB. Ядерные параметры вроде max_cstate=1 используй только для подтверждения диагноза, а потом сужай проблему до конкретного состояния или драйвера. Начни с микрокода и одного параметра, остальное подключай по мере необходимости.
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии