Почему некоторые работники udev не работают?

Несколько недель назад ALSA и USB перестали работать на моем ноутбуке. Такие вещи, как видео на YouTube, просто не имеют звука в Firefox; mpv печать [ao/alsa] Playback open error: No such file or directory. Could not open/initialize audio device -> no sound., alsamixer жалуется что нет такого файла как mixer, Флешки не отображаются в /dev или же /dev/diskи их светодиоды не загораются. Как ни странно, я все еще могу использовать порты для зарядки телефона...

udev Кажется, что он тоже капризничает, гасит сапоги целую минуту (сам по себе!) waiting for uevents to be processed ... и остановка выключения на полминуты (я рассчитал это) stopping udev ..., Он также жалуется на журнал ядра:

<28>[  130.669180] udevd[1745]: worker [1763] /devices/pci0000:00/0000:00:14.0 is taking a long time
<28>[  130.669196] udevd[1745]: worker [1762] /devices/pci0000:00/0000:00:1b.0 is taking a long time

И пару минут спустя:

[  251.500125] udevd[1745]: worker [1763] /devices/pci0000:00/0000:00:14.0 timeout; kill it
[  251.500156] udevd[1745]: seq 1333 '/devices/pci0000:00/0000:00:14.0' killed
[  251.500166] udevd[1745]: worker [1762] /devices/pci0000:00/0000:00:1b.0 timeout; kill it
[  251.500174] udevd[1745]: seq 1336 '/devices/pci0000:00/0000:00:1b.0' killed
[  251.500535] udevd[1745]: worker [1763] terminated by signal 9 (Killed)
[  251.500540] udevd[1745]: worker [1763] failed while handling '/devices/pci0000:00/0000:00:14.0'

Эти PCI-адреса оказались для контроллера USB и аудиоустройства соответственно. Также я заметил, что пока lsmod не кажется ничего необычного, /proc/modules списки xhci_pci, snd_hda_intel, а также sunrpc как вечно Loading, modprobe на этих трех (и других, которые от них зависят) будут зависать (-v показывает, что он зависает при попытке insmod их).

Система работает под управлением Gentoo на Linux 4.4.6. udev предоставляется eudev 3.1.5. Корневая файловая система находится в контейнере LUKS; Я использую initrd для загрузки.

Поиск в Web и Stack Exchange не помог. Я проверил мой конфиг ядра по отрывку вики и попробовал заново eudev (без изменений). Так что здесь происходит?

1 ответ

Решение

Пока у меня нет полного объяснения, отключение TIMER_STATS в конфигурации ядра (это Kernel hacking Collect kernel timers statistics если вы используете menuconfig), кажется, это исправили.

Я предполагаю, что по некоторым причинам некоторые из моих модулей не загружаются с TIMER_STATS на, каким-то странным образом, что делает insmod похмелья. Два udev рабочие, упомянутые в журнале ядра, пытаются загрузить их, повесить, а затем убить. Отсутствие модулей ядра и других настроек udev сделал бы, вещи, связанные со звуком и USB ... не работают.


ОБНОВИТЬ:

Я понял, что многие модули загружались раньше / был установлен. Был очень смущен, пока я не копался в своем initrd и не обнаружил, что у него есть свой /lib/modules с копиями некоторых модулей (в том числе xhci_pci а также sunrpc ). Несмотря на то, что я позаботился об установке всех модулей в корневую файловую систему после их восстановления, я никогда не перестраивал initrd, что означало, что работающее ядро ​​имело конфигурацию, отличную от (некоторых) модулей, которые оно пыталось загрузить. Очевидно, это привело к странным вещам. подобно insmod повешение.

Итак, если вы используете initrd и у него есть копии модулей ядра, обязательно перестройте его при перестройке ядра.

Другие вопросы по тегам