ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | doesn't load snd-es18xx automatically | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Michael Shigorin <mike> |
| Component: | kernel-image-led-tc | Assignee: | Michael Shigorin <mike> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P2 | CC: | led, vsu |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 15333 | ||
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=bd20bada37d55f1a747d7bc797e18f990cb9cdfe Вероятно, без этого костыля модули isapnp на старых ядрах не загружаются. Хотя может быть сломано и на новых - isapnp сейчас встречается довольно редко; хорошо бы проверить работу свежих ядер и udev на этом железе. Там были ещё проблемы с pnp_card_device_id (специфичные именно для isapnp, и не для всех драйверов), и драйвер snd-es18xx использует как раз идентификаторы такого типа, хотя более простые pnp_device_id там тоже есть. Похоже, алиасы для pnp_card_device_id починены только в 2.6.26: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0c81eed4b9d6273124c7ab5eb99760b4d3a3cb9e Хотя, если работало на М40, скорее всего, дело не в этом, а в отрывании правил для старых ядер. Можно вернуть костыль локально - например, в файл 79-pnp-drivers.rules (две строки, которые там удалили, только ещё добавить проверку ACTION=="add", которая в 80-drivers.rules одна на все правила). 2 vsu: спасибо; а правила для старых ядер совсем вредные? И осмысленно ли сделать свои udev-rules с дублем скрипта с возвращёнными строками, который зацепит эту железку? 2 led: придётся и мне теперь разучивать сборку ядра... или получится? :) Ладно, разучил за пару дней. С переездом на 2.6.27 (держит vm_deadlock patch) проблема действительно исправилась. Ядро вылизываю, проверяю на железе и забрасываю на git.alt и в сизиф -- только вот с чего бы там clone сделать, чтоб объекты заново не тягать туда-сюда... |
Понимаю, что может быть проблема взаимодействия с 2.6.22, но решил повесить, чтоб данные не потерялись... На тонком клиенте из Compaq Deskpro EN SFF (440BX) при использовании udev-139-alt1 и 2.6.22-led-tc-alt25 не загружается автоматически модуль для ESS1869 (snd-es18xx). После успешной загрузки модуля руками нашлось такое: --- /sys/devices/pnp0/00:0b/uevent DRIVER=es18xx-pnpbios PHYSDEVBUS=pnp PHYSDEVDRIVER=es18xx-pnpbios --- В udevinfo не особенно понимаю, но: --- # udevadm info --query=all --path=/sys/devices/pnp0/00\:0b P: /devices/pnp0/00:0b E: UDEV_LOG=3 E: DEVPATH=/devices/pnp0/00:0b E: DRIVER=es18xx-pnpbios E: PHYSDEVBUS=pnp E: PHYSDEVDRIVER=es18xx-pnpbios # udevadm info --query=all --path=/sys/devices/pnp0/00\:0b --attribute-walk Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/pnp0/00:0b': KERNEL=="00:0b" SUBSYSTEM=="pnp" DRIVER=="es18xx-pnpbios" ATTR{id}=="ESS1869" looking at parent device '/devices/pnp0': KERNELS=="pnp0" SUBSYSTEMS=="" DRIVERS=="" --- С udev-118-alt1.1 на M40 всё подхватывается само. Что требуется сделать, чтобы заработала текущая комбинация, или обязательно обновлять сборку ядра? На железе с PCI-звуком snd-* грузятся.