Bug 9560

Created attachment 1485 [details]
tulip oops dmesg

btw, oops'алось оно уже при любом действии, требующем e.g. резолвинга,
похоже...

Created attachment 1486 [details]
некий драйвер для этого eth

Э... не, ULi_SATA вряд ли осмысленно -- три метра разных бинарников для "RAID" и
sata_uli версии 0.10 (в 2.6.12-std26-up-alt4 -- 0.5).

В 2.6.13 поддержку ULi вынесли из драйвера tulip в отдельный модуль -
собственно, именно он и лежит в том архиве (только с ^M и без нескольких мелких
исправлений).

commit 4689ced99b18937e28c0f6c190394ccc3c61d651
Author: Peer Chen <Peer.Chen@uli.com.tw>
Date:   Fri Jul 29 15:33:58 2005 -0400

    [netdrvr] add 'uli526x' driver (a tulip clone)
    
    We want to extract our LAN card driver from tulip core driver and
    make a new file uli526x.c at tulip folder, because we have added
    some ethtool interface support and non-eprom support in our driver
    and may be other change in the futher.
    
    If our controllers support are still contained in the tulip core
    driver, I think it'll increase the complexity of maintenance, you
    know, tulip core driver include several files and support so many
    other controllers.  Furthermore, I tested the newest kernel 2.6.12
    and I found the tulip driver can not work on our lan controller, and
    I no time to debug it, so I aspired want to make a single uli526x.c
    file just for our controllers.  Could you help us remove the ULi
    m5261/m5263 lan controller support from tulip core driver and add
    the new single uli526x.c file for us?
    
    Signed-off-by: Peer Chen <Peer.Chen@uli.com.tw>
    Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

Можно попробовать собрать этот модуль с помощью однострочного Makefile:

obj-m := uli526x.o

командой "make -C /usr/src/linux-2.6.12-std26-up modules SUBDIRS=`pwd`", и
проверить работу на том 2.6.12 (только придётся убрать куда-нибудь имеющийся
tulip.ko, чтобы hotplug его не грузил, или засунуть его в blacklist).

Oops происходит в месте, совершенно не имеющем отношения к сети - либо эта
сетевуха ухитряется как-то портить чужую память, либо дело в чём-то другом.

(In reply to comment #4)
> Можно попробовать собрать этот модуль с помощью однострочного Makefile:
Дело в том, что тут сборочной среды нет; в принципе, вытянуть можно, но надёжнее
сменить сетевую (поскольку если придётся обновить ядро через полгода и тут
плавно отвалится сеть, то вспоминать нюансы можно будет долго).

В принципе, появиться где-то летом для экспериментов скорее реально, в этом
городе мы с adiel@ порой бываем.

> Oops происходит в месте, совершенно не имеющем отношения к сети - либо эта
> сетевуха ухитряется как-то портить чужую память, либо дело в чём-то другом.

Да, мне тоже странным oops показался.  Но дотянуться до пакета ksymoops уже не
получалось...

(In reply to comment #5)
> Дело в том, что тут сборочной среды нет; в принципе, вытянуть можно, но надёжнее
> сменить сетевую (поскольку если придётся обновить ядро через полгода и тут
> плавно отвалится сеть, то вспоминать нюансы можно будет долго).
> 
> В принципе, появиться где-то летом для экспериментов скорее реально, в этом
> городе мы с adiel@ порой бываем.

В принципе была мысль завернуть патч с этим драйвером в updates, но без
тестирования это как-то неправильно. Впрочем, тут придётся ещё и править за
инсталятором (который, скорее всего, пропишет модуль tulip), да и в hwdatabase
могут быть лишние мешающие записи.

> Да, мне тоже странным oops показался.  Но дотянуться до пакета ksymoops уже не
> получалось...

ksymoops для ядер 2.6.x, собранных с KALLSYMS, не особо нужен - символы в
backtrace ядро пишет само, а дизассемблировать строку Code можно в любом месте.

(In reply to comment #6)
> В принципе была мысль завернуть патч с этим драйвером в updates, но без
> тестирования это как-то неправильно.
С другой стороны, этот на этом заведомо не жилец, но вообще как бы не отменяется ;-)

> Впрочем, тут придётся ещё и править за
> инсталятором (который, скорее всего, пропишет модуль tulip), да и в hwdatabase
> могут быть лишние мешающие записи.
Угу.  Если всё-таки решите с Антоном такие изменения в принципе вносить, то
конкретно это можно попробовать летом проверить.

Тут ещё в процессе дорассмотрения платы выяснилось, что с snd-hda-intel из 3.0
мы работать тоже не собираемся (похожие симптомы вместе со ссылкой на нерабочий
по состоянию на прошлое лето драйвер на asus.com описаны здесь:
http://lkml.org/lkml/2005/7/28/325).  Сорри, что пишу сюда же -- получается
сводная бага, хотя по сути правится здесь только сеть...

что-нибудь делать будем?

(In reply to comment #8)
> что-нибудь делать будем?
Ну, мы-то там realtek воткнули...

Но если вдруг доберёшься, то мож вместе с #9354 было бы неплохо, конечно.
Особенно если какой 3.0.5 по ходу дела предвидится.

Как оказалось, сеть на ULi M5263 нам уже попадалась - bug #8331, и в
std26-2.6.12-alt5 был добавлен некий патч, что-то там исправляющий. А тут
почему-то тестировалось на -alt4. Надо бы всё это как следует проверить на
реальном железе...

Если всё-таки будем переезжать на отдельный модуль uli526x, в крайнем случае
можно будет засунуть в модуль tulip лишнюю зависимость, чтобы старые
конфигурации продолжали работать (правда, тогда люди, использующие другие карты,
получат в памяти лишний ненужный модуль, и конфигурации вида "uli526x и рядом в
PCI другой tulip" всё равно могут сломаться).

(In reply to comment #10)
> почему-то тестировалось на -alt4
Просто образ на нём фиксировался.  А вытянуть оперативно не получалось (хотя бы
потому, что дополнительная сетевая всё равно нужна тогда).

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

мне кажется, что пока-что лучше оставить tulip. Только исправить.

Железа к сожалению под рукой нет.

Если проверять - то не за лето, а прямо сейчас.

Ибо 3.0.5 будет где-то на днях, судя по всему.

Прямо сейчас не могу, та железка во Львове.  Рыпнуться куда по Киеву тоже не
успею, завтра в командировку на пару дней.

Есть ещё один вариант - можно собрать модуль uli526x, но не выносить pci id из
модуля tulip (и, возможно, даже скрыть таблицу PCI ID в модуле uli5261 - тогда
его можно будет загрузить только вручную, но хотя бы он там будет).

Кстати, в hwdatabase-0.3.19-alt1 из C3.0 обнаружилась следующая запись:

10b9	5261	dmfe

В модуле dmfe такого идентификатора нет.  Записей для 5263 в pcitable не обнаружено.

Давай так и сделаем. а hwdatabase я исправлю, завесьте на него чего-нить тяжёлое.

(In reply to comment #14)
> Прямо сейчас не могу, та железка во Львове.
Перевешиваю с 3.0/kernel-image-std26-up на Sisyphus/hwdatabase; проверить
теоретически возможно с каким livecd, хотя сильно в этом не уверен.

Боюсь, придётся перевесить на Стаса.

-> udev

В udev таблиц нет, драйвер uli526x давно отдельный...

Вот и аюшки, а то болтается тут :)

Поскольку проблема в драйвере и для 2.6.24 она актуальна, переоткрываю.
Цитирую vsu@ в sisyphus@:

> В настройках 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 этот патч ещё не перенесён; апстрим, очевидно, тоже до
сих пор не исправил эту проблему.

reassign

Похоже, всё грустнее -- есть две подобные карты с одинаковым PCI ID.  В дебиане вроде как остановились на хуке в инсталер.

<Led> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334104

apparently just another oops nobody@'s workin' on

таймаут (уже вряд ли смогу даже проверить фикс)