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

Question

Несколько недель назад на моем ноутбуке перестали работать ALSA и USB. Такие вещи, как видео на YouTube, просто не имеют звука в Firefox; mpv prints [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 (без изменений). Так что здесь происходит?

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