[sisyphus] dmfe vs tulip

[sisyphus] dmfe vs tulip

[А.Китайкин]

	Доброй, спокойной всем ночи!

Подскажите пожалуйста, кого и как отучить грузить модуль tulip
в данном конкретном случае?

У меня имеется сетевая карточка:

00:10.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40)
        Subsystem: Unknown device 4554:434e
        Flags: bus master, medium devsel, latency 32, IRQ 10
        I/O ports at e400 [size=256]
        Memory at df001000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 20000000 [disabled] [size=256K]
        Capabilities: <access denied>
        Kernel driver in use: dmfe

При загрузке компьютера усердно грузится tulip. Но сеть работает
через dmfe.

В настройках etcnet в options прописано MODULE=dmfe, в результате
в память загружаются оба. С ядром 2.6.18 сеть как-то работала.
Попробовал 2.6.24-std-def и облом: теперь сеть запускается только
после выгрузки обоих модулей и повторной загрузки dmfe.

...До и в процессе сочинения этого письма провел несколько
экспериментов.

Правил pci.ids и pcitable в hwdatabase, добавил девайс и связь с
dmfe, не помогло.

Правка /etc/hotplug/blacklist не помогла (убрал dmfe, добавил tulip,
все равно грузится!).

В udev ничего не понял. В т.ч. как vendor и devid связать с чем-л.

О, чудо! Ура! Заработало! - Добавил blacklist tulip в новый файлик
в /etc/modprobe.d


Вопрос остался: кто хранит тайные знания о правильных драйверах?
И почему вечно грузится tulip, хотя не работает, а работает dmfe?
На работе за последние годы прошло несколько карточек от C-Net,
и все dmfe, и все конфигурировались вручную. Раньше было просто,
главное прозрачно, alias eth0 "и получи то что ты видишь".
А что взамен?

Можно ли все-таки этот Unknown device 4554:434e по 150 руб. за шт.
куда-нибудь занести в виде опыта для будущих поколений?

-- 
Анатолий Китайкин
ОАО Радиоавионика, СПб

Re: [sisyphus] dmfe vs tulip

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3691 bytes --]

On Thu, Feb 28, 2008 at 02:03:58AM +0300, А.Китайкин wrote:
> Подскажите пожалуйста, кого и как отучить грузить модуль tulip
> в данном конкретном случае?
> 
> У меня имеется сетевая карточка:
> 
> 00:10.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40)
>         Subsystem: Unknown device 4554:434e
>         Flags: bus master, medium devsel, latency 32, IRQ 10
>         I/O ports at e400 [size=256]
>         Memory at df001000 (32-bit, non-prefetchable) [size=256]
>         [virtual] Expansion ROM at 20000000 [disabled] [size=256K]
>         Capabilities: <access denied>
>         Kernel driver in use: dmfe
> 
> При загрузке компьютера усердно грузится tulip. Но сеть работает
> через dmfe.
> 
> В настройках etcnet в options прописано MODULE=dmfe, в результате
> в память загружаются оба. С ядром 2.6.18 сеть как-то работала.

Потому что в это ядро входил патч, который по умолчанию отключал
поддержку этих карточек в модуле tulip (грузились всё равно оба
модуля, но без дополнительных параметров модуль tulip игнорировал
устройство).

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334104
    https://launchpad.net/bugs/48287

> Попробовал 2.6.24-std-def и облом: теперь сеть запускается только
> после выгрузки обоих модулей и повторной загрузки dmfe.

На ядро 2.6.24 этот патч ещё не перенесён; апстрим, очевидно, тоже до
сих пор не исправил эту проблему.

> ...До и в процессе сочинения этого письма провел несколько
> экспериментов.
> 
> Правил pci.ids и pcitable в hwdatabase, добавил девайс и связь с
> dmfe, не помогло.

Эти файлы не используются при загрузке модулей (когда-то очень давно
информация бралась из pcitable, сейчас используются только данные из
самих модулей и blacklist в конфигурации modprobe).

> Правка /etc/hotplug/blacklist не помогла (убрал dmfe, добавил tulip,
> все равно грузится!).

hotplug сейчас не используется (остались только старые хвосты типа
acpi.rc; на 2.6.24 и они станут окончательно ненужными).

> В udev ничего не понял. В т.ч. как vendor и devid связать с чем-л.

Этим занимается не непосредственно udev, а modprobe (модуль ищется по
modalias и встроенным алиасам).

> О, чудо! Ура! Заработало! - Добавил blacklist tulip в новый файлик
> в /etc/modprobe.d

Этот вариант будет работать, если не потребуется установить рядом
другую карточку, для которой нужен будет модуль tulip.

> Вопрос остался: кто хранит тайные знания о правильных драйверах?

Обычно сопоставление идёт по modalias - список поддерживаемых модулем
устройств виден в выводе modinfo; общий список извлекается из модулей
при выполнении depmod и помещается в /lib/modules/$KVER/modules.alias.
Проблемы возникают в ситуациях, когда на один и тот же идентификатор
по каким-то причинам претендует несколько модулей (в данном случае это
означает, что для устройства есть несколько разных драйверов с
различным набором ошибок в каждом из них).

> И почему вечно грузится tulip, хотя не работает, а работает dmfe?

По приведённым выше ссылкам указано, что на некоторых архитектурах по
каким-то причинам с аналогичными устройствами нормально работает
драйвер tulip, а как раз dmfe не работает; что с этим делать -
непонятно.

> На работе за последние годы прошло несколько карточек от C-Net,
> и все dmfe, и все конфигурировались вручную. Раньше было просто,
> главное прозрачно, alias eth0 "и получи то что ты видишь".
> А что взамен?

Насколько я понял, с 2.6.18-std-smp эти карточки всё-таки должны были
работать сразу; с vanilla (чем по сути сейчас является std-def) они
действительно не работают без дополнительной настройки.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] dmfe vs tulip

[Led]

В сообщении от Thursday 28 February 2008 12:40:24 Sergey Vlasov написал(а):
> On Thu, Feb 28, 2008 at 02:03:58AM +0300, А.Китайкин wrote:
> > Подскажите пожалуйста, кого и как отучить грузить модуль tulip
> > в данном конкретном случае?
> >
> > У меня имеется сетевая карточка:
> >
> > 00:10.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip
> > compatible 10/100 Ethernet (rev 40) Subsystem: Unknown device 4554:434e
> >         Flags: bus master, medium devsel, latency 32, IRQ 10
> >         I/O ports at e400 [size=256]
> >         Memory at df001000 (32-bit, non-prefetchable) [size=256]
> >         [virtual] Expansion ROM at 20000000 [disabled] [size=256K]
> >         Capabilities: <access denied>
> >         Kernel driver in use: dmfe
> >
> > При загрузке компьютера усердно грузится tulip. Но сеть работает
> > через dmfe.
> >
> > В настройках etcnet в options прописано MODULE=dmfe, в результате
> > в память загружаются оба. С ядром 2.6.18 сеть как-то работала.
>
> Потому что в это ядро входил патч, который по умолчанию отключал
> поддержку этих карточек в модуле tulip (грузились всё равно оба
> модуля, но без дополнительных параметров модуль tulip игнорировал
> устройство).
>
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334104
>     https://launchpad.net/bugs/48287
>
> > Попробовал 2.6.24-std-def и облом: теперь сеть запускается только
> > после выгрузки обоих модулей и повторной загрузки dmfe.
>
> На ядро 2.6.24 этот патч ещё не перенесён; апстрим, очевидно, тоже до
> сих пор не исправил эту проблему.
>
> > ...До и в процессе сочинения этого письма провел несколько
> > экспериментов.
> >
> > Правил pci.ids и pcitable в hwdatabase, добавил девайс и связь с
> > dmfe, не помогло.
>
> Эти файлы не используются при загрузке модулей (когда-то очень давно
> информация бралась из pcitable, сейчас используются только данные из
> самих модулей и blacklist в конфигурации modprobe).
>
> > Правка /etc/hotplug/blacklist не помогла (убрал dmfe, добавил tulip,
> > все равно грузится!).
>
> hotplug сейчас не используется (остались только старые хвосты типа
> acpi.rc; на 2.6.24 и они станут окончательно ненужными).
>
> > В udev ничего не понял. В т.ч. как vendor и devid связать с чем-л.
>
> Этим занимается не непосредственно udev, а modprobe (модуль ищется по
> modalias и встроенным алиасам).
>
> > О, чудо! Ура! Заработало! - Добавил blacklist tulip в новый файлик
> > в /etc/modprobe.d
>
> Этот вариант будет работать, если не потребуется установить рядом
> другую карточку, для которой нужен будет модуль tulip.
>
> > Вопрос остался: кто хранит тайные знания о правильных драйверах?
>
> Обычно сопоставление идёт по modalias - список поддерживаемых модулем
> устройств виден в выводе modinfo; общий список извлекается из модулей
> при выполнении depmod и помещается в /lib/modules/$KVER/modules.alias.
> Проблемы возникают в ситуациях, когда на один и тот же идентификатор
> по каким-то причинам претендует несколько модулей (в данном случае это
> означает, что для устройства есть несколько разных драйверов с
> различным набором ошибок в каждом из них).

кстати, вот этот modalias повторяется и в 8139too, и в 8139cp:
pci:v000010ECd00008139sv*sd*bc*sc*i*


-- 
Led

Re: [sisyphus] dmfe vs tulip

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Thu, Feb 28, 2008 at 01:55:13PM +0200, Led wrote:
> кстати, вот этот modalias повторяется и в 8139too, и в 8139cp:
> pci:v000010ECd00008139sv*sd*bc*sc*i*

Эти устройства различаются по диапазонам revision, что нельзя указать
в modalias.  Причём, если 8139too загрузится раньше 8139cp, он будет
обслуживать все карты (правда, с выдачей предупреждения о том, что для
8139C+ лучше использовать 8139cp); модуль 8139cp просто игнорирует
неподдерживаемые им устройства, чтобы с ними мог работать 8139too.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] dmfe vs tulip

[Led]

В сообщении от Thursday 28 February 2008 14:26:13 Sergey Vlasov написал(а):
> On Thu, Feb 28, 2008 at 01:55:13PM +0200, Led wrote:
> > кстати, вот этот modalias повторяется и в 8139too, и в 8139cp:
> > pci:v000010ECd00008139sv*sd*bc*sc*i*
>
> Эти устройства различаются по диапазонам revision, что нельзя указать
> в modalias.  Причём, если 8139too загрузится раньше 8139cp, он будет
> обслуживать все карты (правда, с выдачей предупреждения о том, что для
> 8139C+ лучше использовать 8139cp); модуль 8139cp просто игнорирует
> неподдерживаемые им устройства, чтобы с ними мог работать 8139too.

Проверялось на eBox: udev грузит оба - сеть работает плохо, если грузить 
только 8139cp - работает лучше, если грузить 8139too - работает ещё лучше.
Жаль, что, всё же, нельзя развести их по диапазонам :(

-- 
Led

Re: [sisyphus] dmfe vs tulip

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Thu, Feb 28, 2008 at 02:33:52PM +0200, Led wrote:
> В сообщении от Thursday 28 February 2008 14:26:13 Sergey Vlasov написал(а):
> > On Thu, Feb 28, 2008 at 01:55:13PM +0200, Led wrote:
> > > кстати, вот этот modalias повторяется и в 8139too, и в 8139cp:
> > > pci:v000010ECd00008139sv*sd*bc*sc*i*
> >
> > Эти устройства различаются по диапазонам revision, что нельзя указать
> > в modalias.  Причём, если 8139too загрузится раньше 8139cp, он будет
> > обслуживать все карты (правда, с выдачей предупреждения о том, что для
> > 8139C+ лучше использовать 8139cp); модуль 8139cp просто игнорирует
> > неподдерживаемые им устройства, чтобы с ними мог работать 8139too.
> 
> Проверялось на eBox: udev грузит оба - сеть работает плохо, если грузить 
> только 8139cp - работает лучше, если грузить 8139too - работает ещё лучше.

А вот это очень странно - в любом случае с конкретным устройством
работает только один драйвер, загрузка другого ни на что влиять не
должна.  Как именно проявлялось "работает плохо"?

> Жаль, что, всё же, нельзя развести их по диапазонам :(

Вообще 8139C+ - редко встречающийся чип; можно просто поставить
blacklist 8139cp по умолчанию.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] dmfe vs tulip

[Владимир]

Sergey Vlasov пишет:
>> Проверялось на eBox: udev грузит оба - сеть работает плохо, если грузить 
>> только 8139cp - работает лучше, если грузить 8139too - работает ещё лучше.
>>     
>
> А вот это очень странно - в любом случае с конкретным устройством
> работает только один драйвер, загрузка другого ни на что влиять не
> должна.  Как именно проявлялось "работает плохо"?
>
>   

Могу подтвердить, сталкивался с другими драйверами, какими сейчас точно 
не вспомню.
Если грузятся два "подходящих" модуля для карточки, то сеть работает не 
просто плохо,
а отвратительно плохо.


-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [sisyphus] dmfe vs tulip

[Led]

В сообщении от Thursday 28 February 2008 14:46:33 Sergey Vlasov написал(а):
> On Thu, Feb 28, 2008 at 02:33:52PM +0200, Led wrote:
> > В сообщении от Thursday 28 February 2008 14:26:13 Sergey Vlasov 
написал(а):
> > > On Thu, Feb 28, 2008 at 01:55:13PM +0200, Led wrote:
> > > > кстати, вот этот modalias повторяется и в 8139too, и в 8139cp:
> > > > pci:v000010ECd00008139sv*sd*bc*sc*i*
> > >
> > > Эти устройства различаются по диапазонам revision, что нельзя указать
> > > в modalias.  Причём, если 8139too загрузится раньше 8139cp, он будет
> > > обслуживать все карты (правда, с выдачей предупреждения о том, что для
> > > 8139C+ лучше использовать 8139cp); модуль 8139cp просто игнорирует
> > > неподдерживаемые им устройства, чтобы с ними мог работать 8139too.
> >
> > Проверялось на eBox: udev грузит оба - сеть работает плохо, если грузить
> > только 8139cp - работает лучше, если грузить 8139too - работает ещё
> > лучше.
>
> А вот это очень странно - в любом случае с конкретным устройством
> работает только один драйвер, загрузка другого ни на что влиять не
> должна.  Как именно проявлялось "работает плохо"?

простой тест на скорость копирования большого файла по NFS.

>
> > Жаль, что, всё же, нельзя развести их по диапазонам :(
>
> Вообще 8139C+ - редко встречающийся чип; можно просто поставить
> blacklist 8139cp по умолчанию.

Ну, в этом устройстве как раз был 8139C+

-- 
Led

Re: [sisyphus] dmfe vs tulip

[Michael Shigorin]

On Thu, Feb 28, 2008 at 02:03:58AM +0300, А.Китайкин wrote:
> Можно ли все-таки этот Unknown device 4554:434e

Так, вот чтоб это не смущало -- просьба проверить свежие pciutils:
http://fly.osdn.org.ua/~mike/packages/pciutils/

lspci -q потянет свежую строчку из сети, если в локальном кэше
не окажется.

PS: вендора 4554 на http://pciids.sf.net не вижу (точнее,
http://pci-ids.ucw.cz/iii/?p=4) -- предлагаю засабмитить.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] dmfe vs tulip

[Michael Shigorin]

On Thu, Feb 28, 2008 at 04:17:43PM +0200, Led wrote:
> > > Проверялось на eBox: udev грузит оба - сеть работает плохо,
> > > если грузить только 8139cp - работает лучше, если грузить
> > > 8139too - работает ещё лучше.
> > Вообще 8139C+ - редко встречающийся чип; можно просто
> > поставить blacklist 8139cp по умолчанию.
> Ну, в этом устройстве как раз был 8139C+

Повесишь FR на module-init-tools? (/etc/modprobe.d/blacklist-net)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] dmfe vs tulip

[Konstantin A. Lepikhov]

Hi Michael!

Saturday 01, at 12:08:04 PM you wrote:

> On Thu, Feb 28, 2008 at 02:03:58AM +0300, А.Китайкин wrote:
> > Можно ли все-таки этот Unknown device 4554:434e
> 
> Так, вот чтоб это не смущало -- просьба проверить свежие pciutils:
> http://fly.osdn.org.ua/~mike/packages/pciutils/
> 
> lspci -q потянет свежую строчку из сети, если в локальном кэше
> не окажется.
> 
> PS: вендора 4554 на http://pciids.sf.net не вижу (точнее,
> http://pci-ids.ucw.cz/iii/?p=4) -- предлагаю засабмитить.
предлагаешь запихать туда полкитая и всю российскую оборонку? Ну не все
такие богатые чтобы регистрировать свой vendor id. 

-- 
WBR et al.

Re: [sisyphus] dmfe vs tulip

[Anton Farygin]

Konstantin A. Lepikhov пишет:
> Hi Michael!
> 
> Saturday 01, at 12:08:04 PM you wrote:
> 
>> On Thu, Feb 28, 2008 at 02:03:58AM +0300, А.Китайкин wrote:
>>> Можно ли все-таки этот Unknown device 4554:434e
>> Так, вот чтоб это не смущало -- просьба проверить свежие pciutils:
>> http://fly.osdn.org.ua/~mike/packages/pciutils/
>>
>> lspci -q потянет свежую строчку из сети, если в локальном кэше
>> не окажется.
>>
>> PS: вендора 4554 на http://pciids.sf.net не вижу (точнее,
>> http://pci-ids.ucw.cz/iii/?p=4) -- предлагаю засабмитить.
> предлагаешь запихать туда полкитая и всю российскую оборонку? Ну не все
> такие богатые чтобы регистрировать свой vendor id. 

Естественно запихать. Уж кль смогли зарегистрировать свой deviceid.

Re: [sisyphus] dmfe vs tulip

[Michael Shigorin]

On Wed, Mar 05, 2008 at 01:08:00AM +0300, Konstantin A. Lepikhov wrote:
> > > Можно ли все-таки этот Unknown device 4554:434e
> > Так, вот чтоб это не смущало -- просьба проверить свежие pciutils:
> > http://fly.osdn.org.ua/~mike/packages/pciutils/
> > lspci -q потянет свежую строчку из сети, если в локальном кэше
> > не окажется.
> > PS: вендора 4554 на http://pciids.sf.net не вижу (точнее,
> > http://pci-ids.ucw.cz/iii/?p=4) -- предлагаю засабмитить.
> предлагаешь запихать туда полкитая и всю российскую оборонку?
> Ну не все такие богатые чтобы регистрировать свой vendor id. 

По крайней мере то, к чему по этим PCI ID грузятся дрова --
да, предлагаю.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/