Назад | Перейти на главную страницу

Можно ли получить модуль для поддержки устройства, которое (иногда) сообщает неверный идентификатор PCI?

Я пытаюсь настроить беспроводную сетевую карту (TP-Link TL-WN350GD) на сервере Linux (Debian Squeeze).

После холодной перезагрузки lspci -nn показывает, что идентификатор PCI для карты - 168c: ffa1. Ядро (2.6.38 из backports) не имеет модуля для этого идентификатора устройства, поэтому модуль не загружается.

Однако после горячей загрузки (т. Е. Выполнения команды перезагрузки) то же устройство отображается как 168c: 001d, что кажется правильным идентификатором и обрабатывается модулем ath5k, как описано в документации. Вот. Насколько я могу судить, устройство безупречно работает в Debian с этим конкретным ядром (я могу подключаться к AP и общаться по беспроводной сети с остальной частью сети).

Проблема в том, что когда система отключается, при следующей загрузке устройство получает неправильный идентификатор (168c: ffa1) и, очевидно, не обнаруживается. Если я выполню перезагрузку, все вернется в нормальное состояние (ID устройства = 168c: 001d, модуль ath5k загружается автоматически).

Я никогда раньше не видел такого странного поведения в отношении идентификаторов PCI ID, и вот что я хотел бы знать:

Есть ли способ обхода подобной ситуации? Есть ли способ «принудительно» установить идентификатор этого конкретного устройства, чтобы драйвер загружался каждый раз, а не только после горячей перезагрузки? Если это можно сделать с помощью правила udev, пример будет действительно полезным.

ТИА, Алексей

Наверное, это можно как-то сделать и через udev. Много лет назад я применил другой подход, пытаясь заставить работать неизвестный USB-накопитель; Я добавил идентификатор устройства вручную, и, к счастью, он заработал.

Итак, очень хардкорный способ - изменить drivers/net/wireless/ath/ath5k/pci.c файл в исходном коде Linux и измените Известные идентификаторы PCI раздел немного. Уже есть такая строка:

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */

Интересно, что бы произошло, если бы вы изменили его так:

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
    { PCI_VDEVICE(ATHEROS, 0xffa1) }, /* 2417 Nala */

а затем скомпилировал собственное ядро.

Но я раньше не видел такого изменения поведения PCI id. Вполне возможно, что беспроводная карта на самом деле не находится в рабочем состоянии, пока она сообщает этот другой идентификатор.

Вы, вероятно, могли бы впихнуть это в udev, но я недостаточно пьян, чтобы пытаться бороться с правилами udev в данный момент. Не совсем безумный способ - заставить драйвер правильно зарегистрировать, чтобы он мог работать с альтернативным идентификатором PCI, но только если он действительно жестяная банка.

Я предполагаю, что когда появляется альтернативный идентификатор PCI, он показывает какое-то другое устройство, которое на самом деле не является беспроводной картой. Я ожидал, что если бы это альтернативное устройство действительно могло управляться драйвером, драйвер уже справился бы с этим случаем. (Учитывая, что это разница в теплой / холодной загрузке, я предполагаю, что это какие-то боллоки при загрузке прошивки). Если водитель не могу управляйте альтернативным устройством, тогда никакие «рожки» не будут работать, udev или что-то еще.

Я бы избавился от карты и заменил ее чем-нибудь не таким уж безумным.

Безумным, хотя, возможно, и работающим, подходом было бы сделать lspci во время загрузки и принудительная перезагрузка при обнаружении неправильного идентификатора. Обратите внимание безумный часть (и убедитесь, что приняты меры против бесконечного цикла загрузки).

Я думаю, что предложение womble заменить устройство на то, что работает каждый раз, является правильным.