Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: если железо ведёт себя странно, зависает, не просыпается из сна или роняет драйвер при загрузке, лечи это связкой «свежий микрокод + параметр ядра». Микрокод чинит ошибки процессора, а параметр командной строки заставляет ядро обходить то, что прошивка не умеет. По отдельности они часто не срабатывают, вместе закрывают оба уровня проблемы.
Микрокод это встроенная прошивка процессора, которую ядро загружает при старте. Производитель выпускает обновления, которые чинят реальные ошибки 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: ошибки переходов между состояниями подтверждают диагноз.
Симптом: система виснет через несколько минут бездействия, при нагрузке работает стабильно. На процессорах 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-состояния.
Симптом: 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.
Симптом: при старте системы экран гаснет, драйвер 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, механизм энергосбережения шины 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.
Сколько угодно, но проверяй по одному. Если добавить пять параметров разом и система перестанет грузиться, ты не поймёшь, кто виноват. Один параметр, одна перезагрузка, один вывод.
Не опасны, но дороги: растёт потребление, падает частота. Используй их для диагностики, а не как постоянное решение. После подтверждения диагноза ищи менее жёсткий вариант.
Кривое железо лечится связкой «микрокод + параметр ядра»: микрокод чинит ошибки процессора, параметр заставляет ядро обходить то, что прошивка не умеет. Обнови amd-ucode или intel-ucode, добавь один параметр в GRUB_CMDLINE_LINUX_DEFAULT, перегенерируй grub.cfg и проверяй каждый параметр на один запуск через редактирование записи в GRUB. Ядерные параметры вроде max_cstate=1 используй только для подтверждения диагноза, а потом сужай проблему до конкретного состояния или драйвера. Начни с микрокода и одного параметра, остальное подключай по мере необходимости.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии