На машинке с матерью ASUS (ATI Xpress 200/ULI M1573) при попытке немного нагрузить набортный eth (ULi M5261/M5263) двумя X-терминалами пошли сетевые таймауты, в dmesg наблюдался oops. Сейчас тот отключен и воткнута 8139 -- к сожалению, lspci сохранить не догадался. К ней вроде бы шли некие драйверы, по крайней мере из C:\Install были сбэкаплены на всякий. Поскольку 8139 работает и это сразу три машинки, то экспериментировать не особенно хочется, но dmesg (ksymoops под рукой тоже, увы, не было; исправлю в образе на будущее) и тарбол прилагаю. (SATA с одним диском на первом канале и sata_uli работает без проблем, но тоже на всякий затарил -- может, для Sisyphus пригодится)
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
таймаут (уже вряд ли смогу даже проверить фикс)
