Bug 19343 - doesn't load snd-es18xx automatically
Summary: doesn't load snd-es18xx automatically
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-led-tc (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Michael Shigorin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 15333
  Show dependency tree
 
Reported: 2009-03-26 17:18 MSK by Michael Shigorin
Modified: 2009-06-13 16:26 MSD (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2009-03-26 17:18:21 MSK
Понимаю, что может быть проблема взаимодействия с 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-* грузятся.
Comment 1 Sergey Vlasov 2009-03-26 19:15:31 MSK
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 одна на все правила).
Comment 2 Michael Shigorin 2009-03-28 15:45:27 MSK
2 vsu: спасибо; а правила для старых ядер совсем вредные?  И осмысленно ли сделать свои udev-rules с дублем скрипта с возвращёнными строками, который зацепит эту железку?

2 led: придётся и мне теперь разучивать сборку ядра... или получится? :)
Comment 3 Michael Shigorin 2009-06-13 02:37:16 MSD
Ладно, разучил за пару дней.  С переездом на 2.6.27 (держит vm_deadlock patch) проблема действительно исправилась.

Ядро вылизываю, проверяю на железе и забрасываю на git.alt и в сизиф -- только вот с чего бы там clone сделать, чтоб объекты заново не тягать туда-сюда...