Пролог

Я пользуюсь стареньким ноутбуком — Emachines E732. Он настолько старый, что максимальная поддержка объёма ОЗУ — 8 ГБ! Однако он по сей день является рабочей лошадкой в моих делах.

Сейчас я понимаю: LiveCD грузится с другим порядком инициализации модулей и, вероятно, использовал более старую версию ядра на тот момент.

Я тогда подумал, что, возможно, в CachyOS может быть из-за каких-либо модификации что-то пошло не так. И это мысль жила до тех пор пока я в EndeavourOS не решил поэкспериментировать с выбором ядра. Когда я выбрал linux-zen , звук пропал. И тогда понял, что дело было не в ОС, а какое ядро я использую. И как оказалось, всё работает, если ядро было LTS (неважно: обычный или с модификациями от cachyos или endeavour). И всё бы хорошо, если бы не одно НО… После очередного обновления, я заметил пропажу звука даже на LTS ядре. И оказалось ещё интереснее - даже в LiveCD звука не было! Тогда я немного был в досаде и купил внешнюю звуковую карту. Однако недавно подумал, что так дела не пойдут и должен быть хоть какой-то выход.

Глава 1: Диагностика

Я решил провести подробную диагностику. Первым делом я проверил базу. Результат был неутешительным: aplay -l выдавал лаконичное:

aplay: device_list:274: no soundcards found...

Однако самое интересное, я решил использовать команду для получения подробной информации об аудиосистеме ноутбука, скрывая при этом личные данные:

❯ sudo inxi -Axxz
Audio:
  Device-1: Intel 5 Series/3400 Series High Definition Audio
    vendor: Acer Incorporated ALI driver: snd_hda_intel v: kernel
    bus-ID: 00:1b.0 chip-ID: 8086:3b56
  API: ALSA v: k6.18.20-1-cachyos-lts status: kernel-api
  Server-1: sndiod v: N/A status: off
  Server-2: JACK v: 0.126.0 status: off
  Server-3: PipeWire v: 1.6.2 status: n/a (root, process) with:
    1: pipewire-pulse status: active 2: wireplumber status: active
    3: pipewire-alsa type: plugin

А также узнать, какие физические звуковые устройства (контроллеры) подключены к PCI-шине.

❯ sudo lspci | grep -i audio
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)

Ещё я решил почитать логи:

❯ sudo journalctl  -b -p err | grep -i audio
апр 09 21:37:46 cachyos-x8664 kernel: hdaudio hdaudioC0D0: no AFG or MFG node found
апр 09 21:37:46 cachyos-x8664 kernel: hdaudio hdaudioC0D1: no AFG or MFG node found
апр 09 21:37:46 cachyos-x8664 kernel: hdaudio hdaudioC0D2: no AFG or MFG node found
апр 09 21:37:46 cachyos-x8664 kernel: hdaudio hdaudioC0D3: no AFG or MFG node found

Исходя из этих входных данных можно сделать вывод, что система всё-таки знает о существовании звуковой карты в ноутбуке, но по определённым причинам не может как-то достучаться.

Здесь я кратко перечислю то, что не сработало, чтобы сэкономить время читателям (то есть вам) с похожей проблемой:

1. User-space: переустановка PipeWire/WirePlumber и мучение alsamixer. Если ALSA не видит карту, крутить ползунки в софте бесполезно.

2. Параметры модуля: манипуляции с /etc/modprobe.d/alsa-fix.conf (вроде model=auto или enable=1). Последняя попытка была такой: options snd-hda-intel enable=1 power_save=0 power_save_controller=N. Меняют поведение драйвера, но не могут исправить ошибку выделения ресурсов на шине PCI.

3. Параметры загрузчика (GRUB): попытки прокинуть pci=nocrs, pci=nomsi или pcie_aspm=off. Система упорно игнорировала эти костыли. В конфиге последний раз было такая строка GRUB_CMDLINE_LINUX_DEFAULT='nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 pci=nocrs pci=nomsi pcie_aspm=off snd_hda_intel.power_save=0 snd_hda_intel.dma_mask=0'

Глава 2: Погружение в dmesg (Ошибка 0xFFFF)

Настоящая причина вскрылась только после внимательного изучения логов ядра. Когда драйвер snd_hda_intel пытается проснуться, он ловит таймаут:

❯ sudo dmesg | grep "00:1b.0"
[    0.360470] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 PCIe Root Complex Integrated Endpoint
[    0.360526] pci 0000:00:1b.0: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]
[    0.360608] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[   17.387236] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[   17.387530] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[   17.387919] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[   17.492159] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[   17.492380] snd_hda_intel 0000:00:1b.0: no codecs initialized

Что такое CORB и почему это критично?

CORB (Command Output Ring Buffer) — это кольцевой буфер, через который драйвер отправляет команды аудиокодеку.

• Таймаут (timeout) означает, что драйвер посылает команду «сброс» (reset), но железо не отвечает в положенный срок.

• CORBRP = 65535 (0xFFFF) — это самое интересное. Это значение «все единицы», что в мире железа обычно означает одно из двух: либо шина зависла, либо устройство физически недоступно/обесточено (чтение из несуществующего регистра).

и попытки что-то сделать “на горячую” , например:

sudo modprobe -r snd_hda_intel
sudo modprobe snd_hda_intel msi=0 dsp_driver=1 probe_mask=1

Были провальными. И если посмотреть снова детально (сравнить вывод dmesg до и после попытки махинаций modprobe), _новые попытки загрузить модуль лишь добавляют в лог те же ошибки с другими таймстемпами — ситуация не меняется.:

❯ sudo dmesg | grep "00:1b.0"
[    0.360470] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 PCIe Root Complex Integrated Endpoint
[    0.360526] pci 0000:00:1b.0: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]
[    0.360608] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[   17.387236] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[   17.387530] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[   17.387919] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[   17.492159] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[   17.492380] snd_hda_intel 0000:00:1b.0: no codecs initialized
[  620.805099] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[  620.805413] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[  620.910305] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[  620.910506] snd_hda_intel 0000:00:1b.0: no codecs initialized
~
❯ sudo modprobe -r snd_hda_intel
  sudo modprobe snd_hda_intel msi=0 dsp_driver=1 probe_mask=1
~
❯ sudo dmesg | grep "00:1b.0"
[    0.360470] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 PCIe Root Complex Integrated Endpoint
[    0.360526] pci 0000:00:1b.0: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]
[    0.360608] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[   17.387236] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[   17.387530] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[   17.387919] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[   17.492159] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[   17.492380] snd_hda_intel 0000:00:1b.0: no codecs initialized
[  620.805099] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[  620.805413] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[  620.910305] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[  620.910506] snd_hda_intel 0000:00:1b.0: no codecs initialized
[  703.517764] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[  703.518073] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[  703.622901] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[  703.623068] snd_hda_intel 0000:00:1b.0: no codecs initialized

Проблема CORB reset timeout#2, CORBRP = 65535 остаётся… Самое интересное обнаружилось при сравнении адресов памяти (BAR). При холодной загрузке ядро выделяло карте адрес в нижнем диапазоне: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]. Там карта упорно молчала.

Глава 3: Эврика и программный «Hot-swap»

Раз стандартная инициализация при загрузке (Cold Boot) приводит к таймауту, я решил попробовать принудительно «переткнуть» карту на уже запущенной системе через интерфейс sysfs.

Логика простая:

1. Удаляем устройство из дерева PCI.

2. Заставляем ядро заново просканировать шину.

# Выкидываем карту из системы
echo 1 | sudo tee /sys/bus/pci/devices/0000:00:1b.0/remove
sleep 2
# Сканируем шину заново
echo 1 | sudo tee /sys/bus/pci/rescan

И это сработало. В dmesg посыпались совсем другие логи. Ядро, выполняя rescan в уже «прогретой» системе, выделило карте совершенно другой адрес:

❯ sudo dmesg | grep "00:1b.0"
[    0.377930] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 PCIe Root Complex Integrated Endpoint
[    0.377985] pci 0000:00:1b.0: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]
[    0.378066] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[   19.591952] snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002)
[   19.592222] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[   19.593111] snd_hda_intel 0000:00:1b.0: number of I/O streams is 30, forcing separate stream tags
[   19.698497] snd_hda_intel 0000:00:1b.0: CORB reset timeout#2, CORBRP = 65535
[   19.698628] snd_hda_intel 0000:00:1b.0: no codecs initialized
[  473.969035] pci 0000:00:1b.0: [8086:3b56] type 00 class 0x040300 PCIe Root Complex Integrated Endpoint
[  473.969102] pci 0000:00:1b.0: BAR 0 [mem 0x00000000-0x00003fff 64bit]
[  473.969214] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[  473.969982] pci 0000:00:1b.0: BAR 0 [mem 0x23c000000-0x23c003fff 64bit]: assigned
[  473.970480] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[  474.095498] input: HDA Intel MID Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input24
[  474.095675] input: HDA Intel MID Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input25
[  474.095852] input: HDA Intel MID HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input26

Что вероятно произошло: раз rescan помог, значит, диагноз про кривую инициализацию при загрузке подтвердился на 100%. При обычном старте ядро пытается проинициализировать аудио-карту слишком рано или с неверными параметрами, которые дает BIOS. В итоге контроллер «залипает» в состоянии ошибки (0xFFFF). Потом после рескана ядро назначило устройству новый адрес в памяти (BAR 0):

• Было: mem 0xd4400000 (нижняя память, где часто случаются конфликты со старым BIOS).

• Стало: mem 0x23c000000 (ушло в область выше 4 ГБ), прерывания пошли, и кодек Realtek ALC272 наконец-то отозвался.

Глава 4: Лечение

Когда уже понятно, как можно оживить звук, осталось сделать так, чтобы это не делать каждый раз руками при каждом запуске системы. Обычно тут два метода: udev и systemd. Я сначала попытался сделать правило в /etc/udev/rules.d/99-fix-audio.rules.

ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x3b56", RUN+="/usr/bin/sh -c 'echo 1 > /sys/bus/pci/devices/0000:00:1b.0/remove; sleep 1; echo 1 > /sys/bus/pci/rescan'"

Однако он почему-то не сработал и решил тогда сделать через systemd, а именно в /etc/systemd/system/fix-audio.service:

[Unit]
Description=Fix Audio PCI Rescan
After=multi-user.target

[Service]
Type=oneshot
ExecStartPre=/usr/bin/sh -c 'echo 1 > /sys/bus/pci/devices/0000:00:1b.0/remove'
ExecStart=/usr/bin/sh -c 'sleep 2 && echo 1 > /sys/bus/pci/rescan'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

И тогда проблема была решена.

❯ sudo systemctl status fix-audio.service
● fix-audio.service - Fix Audio PCI Rescan
     Loaded: loaded (/etc/systemd/system/fix-audio.service; enabled; preset: disabled)
     Active: active (exited) since Fri 2026-04-10 13:48:17 MSK; 10h ago
 Invocation: fac95ab4cd7841e4a70a981c23bddaec
    Process: 858 ExecStartPre=/usr/bin/sh -c echo 1 > /sys/bus/pci/devices/0000:00:1b.0/remove (code=exited, status=0/SUCCESS)
    Process: 860 ExecStart=/usr/bin/sh -c sleep 2 && echo 1 > /sys/bus/pci/rescan (code=exited, status=0/SUCCESS)
   Main PID: 860 (code=exited, status=0/SUCCESS)
   Mem peak: 2M
        CPU: 34ms

апр 10 13:48:15 cachyos-x8664 systemd[1]: Starting Fix Audio PCI Rescan...
апр 10 13:48:17 cachyos-x8664 systemd[1]: Finished Fix Audio PCI Rescan.

Глава 5: Почему не сработал udev и зачем нам systemd?

Многие могут спросить: «Зачем плодить сервисы, если есть udev?». Моя попытка с правилом в udev провалилась по классической причине: состояние гонки (race condition).

Когда udev ловит событие «add» для звуковой карты и тут же пытается её удалить (remove), он входит в конфликт с ядром, которое в этот момент ещё пытается инициализировать устройство. В худшем случае можно было получить бесконечный цикл переповторов.

Кроме того, udev запускает правила в изолированном окружении с ограниченными переменными. Прямой вызов echo в RUN часто требует указания полного пути к интерпретатору и обёртки в /bin/sh -c, но даже с этим надёжность оставляет желать лучшего. Systemd-сервис в этом плане гораздо прозрачнее и предсказуемее.

Systemd-сервис с привязкой к multi-user.target и задержкой sleep 2 действует иначе: он дожидается, пока система «успокоится», и только потом наносит точечный удар дефибриллятором по PCI-шине. Это чище и стабильнее для десктопного окружения.

Заключение

Эта история — наглядный пример того, что LTS не гарантирует отсутствие регрессий. Иногда прогресс (в виде новых механизмов энергосбережения или аллокации ресурсов в ядре) просто забывает спросить мнение чипсетов 15-летней давности.

Основные выводы:

• 0xFFFF в логах — это не всегда смерть железа. Часто это крик о помощи от шины PCI.

• Адреса имеют значение. Если устройство не заводится в нижних адресах (32-bit BAR), принудительный рескан может «забросить» его выше 4 ГБ, где конфликты с BIOS минимальны.

• Не спешите покупать USB-свистки. Иногда Linux просто нужно «переткнуть» устройство программно.

Теперь мой Emachines E732 снова радует звуком, а я получил отличный кейс в копилку системного администрирования.

FAQ: Почему так, а не иначе?

• «Почему не баг-репорт на kernel.org?» Железу 15 лет (если не больше). Для внятного репорта нужна бисекция (kernel bisect) — десятки пересборок ядра. На ноутбуке с 8 ГБ ОЗУ это превратится в пытку. Как будущий SRE, я выбрал путь эффективного workaround-а: стабильное решение за 5 минут работы скрипта против недель компиляции ради фикса, который могут и не принять.

• «Может, просто железо умирает?» Логи говорят об обратном. Если устройство оживает после перераспределения адресов в область выше 4 ГБ — это чистая проблема софта и аллокации ресурсов. Умирающее железо не стало бы стабильно работать после rescan — оно бы сыпало ошибками в случайные моменты или не определялось вовсе.