Почему некоторые работники 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 и у него есть копии модулей ядра, обязательно перестройте его при перестройке ядра.