Bug 9560 - tulip oops with ULi Fast Ethernet
: tulip oops with ULi Fast Ethernet
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/kernel-image-std-def)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
: 9758
:
  Show dependency tree
 
Reported: 2006-05-13 15:35 by
Modified: 2010-04-18 12:22 (History)


Attachments
tulip oops dmesg (19.28 KB, text/plain)
2006-05-13 15:36, Michael Shigorin
no flags Details
некий драйвер для этого eth (323.13 KB, application/octet-stream)
2006-05-13 15:37, Michael Shigorin
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-05-13 15:35:16
На машинке с матерью ASUS (ATI Xpress 200/ULI M1573) при попытке немного
нагрузить набортный  eth (ULi M5261/M5263) двумя X-терминалами пошли сетевые
таймауты, в dmesg наблюдался oops.  Сейчас тот отключен и воткнута 8139 -- к
сожалению, lspci сохранить не догадался.

К ней вроде бы шли некие драйверы, по крайней мере из C:\Install были
сбэкаплены
на всякий.  Поскольку 8139 работает и это сразу три машинки, то
экспериментировать не особенно хочется, но dmesg (ksymoops под рукой тоже, увы,
не было; исправлю в образе на будущее) и тарбол прилагаю.

(SATA с одним диском на первом канале и sata_uli работает без проблем, но тоже
на всякий затарил -- может, для Sisyphus пригодится)
------- Comment #1 From 2006-05-13 15:36:26 -------
Created an attachment (id=1485) [details]
tulip oops dmesg

btw, oops'алось оно уже при любом действии, требующем e.g. резолвинга,
похоже...
------- Comment #2 From 2006-05-13 15:37:25 -------
Created an attachment (id=1486) [details]
некий драйвер для этого eth
------- Comment #3 From 2006-05-13 15:41:02 -------
Э... не, ULi_SATA вряд ли осмысленно -- три метра разных бинарников для "RAID"
и
sata_uli версии 0.10 (в 2.6.12-std26-up-alt4 -- 0.5).
------- Comment #4 From 2006-05-13 16:06:11 -------
В 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 происходит в месте, совершенно не имеющем отношения к сети - либо эта
сетевуха ухитряется как-то портить чужую память, либо дело в чём-то другом.
------- Comment #5 From 2006-05-13 18:49:10 -------
(In reply to comment #4)
> Можно попробовать собрать этот модуль с помощью однострочного Makefile:
Дело в том, что тут сборочной среды нет; в принципе, вытянуть можно, но надёжнее
сменить сетевую (поскольку если придётся обновить ядро через полгода и тут
плавно отвалится сеть, то вспоминать нюансы можно будет долго).

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

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

Да, мне тоже странным oops показался.  Но дотянуться до пакета ksymoops уже не
получалось...
------- Comment #6 From 2006-05-13 19:01:12 -------
(In reply to comment #5)
> Дело в том, что тут сборочной среды нет; в принципе, вытянуть можно, но надёжнее
> сменить сетевую (поскольку если придётся обновить ядро через полгода и тут
> плавно отвалится сеть, то вспоминать нюансы можно будет долго).
> 
> В принципе, появиться где-то летом для экспериментов скорее реально, в этом
> городе мы с adiel@ порой бываем.

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

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

ksymoops для ядер 2.6.x, собранных с KALLSYMS, не особо нужен - символы в
backtrace ядро пишет само, а дизассемблировать строку Code можно в любом месте.
------- Comment #7 From 2006-05-13 20:22:54 -------
(In reply to comment #6)
> В принципе была мысль завернуть патч с этим драйвером в updates, но без
> тестирования это как-то неправильно.
С другой стороны, этот на этом заведомо не жилец, но вообще как бы не отменяется ;-)

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

Тут ещё в процессе дорассмотрения платы выяснилось, что с snd-hda-intel из 3.0
мы работать тоже не собираемся (похожие симптомы вместе со ссылкой на нерабочий
по состоянию на прошлое лето драйвер на asus.com описаны здесь:
http://lkml.org/lkml/2005/7/28/325).  Сорри, что пишу сюда же -- получается
сводная бага, хотя по сути правится здесь только сеть...
------- Comment #8 From 2006-06-30 17:51:15 -------
что-нибудь делать будем?
------- Comment #9 From 2006-06-30 18:22:34 -------
(In reply to comment #8)
> что-нибудь делать будем?
Ну, мы-то там realtek воткнули...

Но если вдруг доберёшься, то мож вместе с #9354 было бы неплохо, конечно.
Особенно если какой 3.0.5 по ходу дела предвидится.
------- Comment #10 From 2006-07-02 21:36:03 -------
Как оказалось, сеть на ULi M5263 нам уже попадалась - bug #8331, и в
std26-2.6.12-alt5 был добавлен некий патч, что-то там исправляющий. А тут
почему-то тестировалось на -alt4. Надо бы всё это как следует проверить на
реальном железе...

Если всё-таки будем переезжать на отдельный модуль uli526x, в крайнем случае
можно будет засунуть в модуль tulip лишнюю зависимость, чтобы старые
конфигурации продолжали работать (правда, тогда люди, использующие другие
карты,
получат в памяти лишний ненужный модуль, и конфигурации вида "uli526x и рядом в
PCI другой tulip" всё равно могут сломаться).
------- Comment #11 From 2006-07-03 12:50:57 -------
(In reply to comment #10)
> почему-то тестировалось на -alt4
Просто образ на нём фиксировался.  А вытянуть оперативно не получалось (хотя бы
потому, что дополнительная сетевая всё равно нужна тогда).

Проверить на реальном железе за лето, думаю, получится -- я туда могу выбраться
как-нибудь.
------- Comment #12 From 2006-07-03 12:51:43 -------
мне кажется, что пока-что лучше оставить tulip. Только исправить.

Железа к сожалению под рукой нет.
------- Comment #13 From 2006-07-03 12:52:27 -------
Если проверять - то не за лето, а прямо сейчас.

Ибо 3.0.5 будет где-то на днях, судя по всему.
------- Comment #14 From 2006-07-03 13:26:49 -------
Прямо сейчас не могу, та железка во Львове.  Рыпнуться куда по Киеву тоже не
успею, завтра в командировку на пару дней.
------- Comment #15 From 2006-07-03 13:44:23 -------
Есть ещё один вариант - можно собрать модуль uli526x, но не выносить pci id из
модуля tulip (и, возможно, даже скрыть таблицу PCI ID в модуле uli5261 - тогда
его можно будет загрузить только вручную, но хотя бы он там будет).

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

10b9    5261    dmfe

В модуле dmfe такого идентификатора нет.  Записей для 5263 в pcitable не
обнаружено.
------- Comment #16 From 2006-07-03 17:38:27 -------
Давай так и сделаем. а hwdatabase я исправлю, завесьте на него чего-нить
тяжёлое.
------- Comment #17 From 2008-02-15 19:45:32 -------
(In reply to comment #14)
> Прямо сейчас не могу, та железка во Львове.
Перевешиваю с 3.0/kernel-image-std26-up на Sisyphus/hwdatabase; проверить
теоретически возможно с каким livecd, хотя сильно в этом не уверен.
------- Comment #18 From 2008-02-15 20:17:20 -------
Боюсь, придётся перевесить на Стаса.
------- Comment #19 From 2008-02-18 19:38:11 -------
-> udev
------- Comment #20 From 2008-02-18 20:41:59 -------
В udev таблиц нет, драйвер uli526x давно отдельный...
------- Comment #21 From 2008-02-20 11:00:33 -------
Вот и аюшки, а то болтается тут :)
------- Comment #22 From 2008-03-01 13:33:32 -------
Поскольку проблема в драйвере и для 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 этот патч ещё не перенесён; апстрим, очевидно, тоже до
сих пор не исправил эту проблему.
------- Comment #23 From 2008-03-01 13:33:57 -------
reassign
------- Comment #24 From 2008-08-26 19:06:56 -------
Похоже, всё грустнее -- есть две подобные карты с одинаковым PCI ID.  В дебиане
вроде как остановились на хуке в инсталер.

<Led> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334104
------- Comment #25 From 2009-09-29 01:25:02 -------
apparently just another oops nobody@'s workin' on
------- Comment #26 From 2010-04-18 12:22:50 -------
таймаут (уже вряд ли смогу даже проверить фикс)