Bug 25709

На рядом установленном Branch 5.1 и ядре 2.6.32 из p5 всё работает.

(В ответ на комментарий №0)
> Имею USB->Ethernet адаптер D-Link Corp. DUB-E100 Fast Ethernet [asix]
> 
> На ядре 2.6.32, только не текущее el-smp, и ранее этот адаптер прекрасно
> работает.
> На той же машине, с Сизифом и похоже всеми ядрами в нём, замечаю, что PPPOE
> соединение не идёт, перебрасываю на встроенный Ethernet контроллер - всё
> нормально.
> 
> Т.е. драйвер asix корректно грузится, интерфейс создаётся, линк обнаруживается,
> а пакеты в сеть не идут. Сетевые экраны даже не трогал.
> 
> Подключаю через этот адаптер ноутбук и вижу, что никакие пакеты ни от одного ни
> другого не идут.

А что написано в dmesg после попытки послать пакет?

Какая у вас архитектура? Я соберу вам модуль от вендора для std-def, чтобы вы его потестили. А то похоже, что asix сломан в ванильном ядре довольно давно:

https://bugzilla.kernel.org/show_bug.cgi?id=16831
https://bugzilla.kernel.org/show_bug.cgi?id=30952

(В ответ на комментарий №3)
> Какая у вас архитектура? Я соберу вам модуль от вендора для std-def, чтобы вы
> его потестили. А то похоже, что asix сломан в ванильном ядре довольно давно:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=16831
> https://bugzilla.kernel.org/show_bug.cgi?id=30952
Похоже на эту багу.
Архитекура: x86.

Created attachment 4962 [details]
Binary module (i586)

Binary module for i586 arch

(В ответ на комментарий №5)
> Created an attachment (id=4962) [details]
> Binary module (i586)
> 
> Binary module for i586 arch

Ммм да, это для std-def-2.6.38-alt8.1

Установил.
Вроде работает, однако сильно не тестировал.

kernel-image-std-def-1:2.6.39-alt1 -> sisyphus:

* Tue Jun 07 2011 Anton Protopopov <aspsk@altlinux> 1:2.6.39-alt1
- Update to 2.6.39.1
- Update ipt_NETFLOW to 1.7.1 (ALT 25697)
- Build asix.ko as a separate module with src from vendor (ALT 25709)
- Build u200.ko as a separate module (ALT 24265)
- Update aufs to the latest one
- Don't build broken subfs, fglrx, dahdi, lirc

модуль asix, раздаваемый с ядром, у меня вполне работает, 2.6.39 (не std-def)
железка trendnet tu2-et100, ASIX AX88772 USB 2.0 Ethernet.

(В ответ на комментарий №9)
> модуль asix, раздаваемый с ядром, у меня вполне работает, 2.6.39 (не std-def)
> железка trendnet tu2-et100, ASIX AX88772 USB 2.0 Ethernet.

А раздаваемый вендором?

раздаваемый вендором у меня проверять желания нет.

(В ответ на комментарий №8)
> - Don't build broken subfs, fglrx, dahdi, lirc
Скорее интерфейсы ядра очередной раз изменили, причём в пределах уже выпущенной версии 2.6.39.

Переоткрываю для P6 в виду актуальности этой проблемы тут.

(В ответ на комментарий №13)
> Переоткрываю для P6 в виду актуальности этой проблемы тут.

Проверили для atd-def-alt8.2 из p6?

(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > Переоткрываю для P6 в виду актуальности этой проблемы тут.
> 
> Проверили для atd-def-alt8.2 из p6?

Нет тут такого. Последний atd-def-alt8.1 и на нём не работает.

После перехода p6 на 2.6.39 эта бага уйдет. 
2aspsk & boyarsh: Обсудите, пожалуйста. Если смена ядра p6 планируется в течение недели, то фиксить 2.6.38 не надо. В противном случае -- придется.
2vitty: el-smp хорошо бы исправить.
critical->normal

(In reply to comment #16)
> После перехода p6 на 2.6.39 эта бага уйдет. 
На всякий -- в 2.6.39 регрессов относительно много, его выпускали по сокращённой программе.

В 39.1 и выходящем днями 39.2 много исправлений.
Если есть сведения о конкретных регрессах, -- сообщите, пожалуйста.

(В ответ на комментарий №17)
> (In reply to comment #16)
> > После перехода p6 на 2.6.39 эта бага уйдет. 
> На всякий -- в 2.6.39 регрессов относительно много, его выпускали по
> сокращённой программе.

(В ответ на комментарий №18)
> В 39.1 и выходящем днями 39.2 много исправлений.
> Если есть сведения о конкретных регрессах, -- сообщите, пожалуйста.

Новый fglrx, который сегодня собран в Сизиф, поддерживает 2.6.39

(В ответ на комментарий №19)
> (В ответ на комментарий №17)
> > (In reply to comment #16)
> > > После перехода p6 на 2.6.39 эта бага уйдет. 
> > На всякий -- в 2.6.39 регрессов относительно много, его выпускали по
> > сокращённой программе.
> 
> (В ответ на комментарий №18)
> > В 39.1 и выходящем днями 39.2 много исправлений.
> > Если есть сведения о конкретных регрессах, -- сообщите, пожалуйста.
> 
> Новый fglrx, который сегодня собран в Сизиф, поддерживает 2.6.39
lirc входит в 2.6.39 . Проблема с dahdi и subfs , но они не собираются лечиться от BKL. 
Если не будут найдены серьезные возражения, то в ближайшее время переходим в p6 на 2.6.39.2. Что исправит обсуждаемую ошибку.

2aspsk@: Прошу собрать ядро 39.2 test-only в p6 asap и  попросить в списках рассылки и на форуме его тестировать.

Ядро 2.6.39.2 в t6 и p6

(В ответ на комментарий №20)
> Если не будут найдены серьезные возражения, то в ближайшее время переходим в p6
> на 2.6.39.2. Что исправит обсуждаемую ошибку.
Не совсем исправляет.
Замечено исчезновение интерфейса данного драйвера примерно через полчаса работы.
Восстанавливается перегрузом модуля.

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

(В ответ на комментарий №23)
> (В ответ на комментарий №20)
> > Если не будут найдены серьезные возражения, то в ближайшее время переходим в p6
> > на 2.6.39.2. Что исправит обсуждаемую ошибку.
> Не совсем исправляет.
> Замечено исчезновение интерфейса данного драйвера примерно через полчаса
> работы.
> Восстанавливается перегрузом модуля.

Ну, тогда ждем исправления от апстрима.

(В ответ на комментарий №24)
> > Замечено исчезновение интерфейса данного драйвера примерно через полчаса
> > работы.
> > Восстанавливается перегрузом модуля.
> 
> Ну, тогда ждем исправления от апстрима.
Ждём, только не исправления драйвера asix, а ядра 2.6.39, в данном смысле!
Сегодня загрузился с ядра 2.6.38-std-def-alt8.1 и уже почти день как на нём проработало с активным соединением.

Похоже это ещё одна регрессия ядра 2.6.39, после разлома API и т.д. На себе я уже насчитал две активные регрессии этого ядра.

P.S. Может в репозитории стабильной платформы откатиться назад на версию 2.6.38, в качестве основного ядра?

(В ответ на комментарий №25)
> P.S. Может в репозитории стабильной платформы откатиться назад на версию
> 2.6.38, в качестве основного ядра?

В 2.6.39 много полезного. Еще есть время до релизов, давайте подождем.
А 2.6.28-alt8.1 можно пока положить в сторонке, -- да, Антон?

(В ответ на комментарий №25)
> > Ну, тогда ждем исправления от апстрима.
> Ждём, только не исправления драйвера asix, а ядра 2.6.39, в данном смысле!
> Сегодня загрузился с ядра 2.6.38-std-def-alt8.1 и уже почти день как на нём
> проработало с активным соединением.
Сглазил. Только что откинулся интерфейс и на 2.6.38, единственно, что дольше прожил. Но на ядре 2.6.32 из p5 такого точно не замечается.

2 aen, aspsk: собсно из-за подобных случаев со сложными codebase'ами приходится порой принимать решение _отложить_ копирование между бранчами, чтоб хоть возможность выкрутиться была.  Неприятная форкообразующая причина, конечно.

(В ответ на комментарий №28)
> 2 aen, aspsk: собсно из-за подобных случаев со сложными codebase'ами приходится
> порой принимать решение _отложить_ копирование между бранчами, чтоб хоть
> возможность выкрутиться была.  Неприятная форкообразующая причина, конечно.

Нужны архивы бранчей.

Похоже это не проблема asix, или как минимум не только.
Заметил следующие моменты:
Необратимое отключение происходит в случае возникновения проблем на интерфейсе, т.е. пакеты или не идут или идут с затором. При этом в логе наблюдаю:
[ 7217.493602] eth1: rxqlen 0 --> 10
[ 7217.493668] eth1: rxqlen 10 --> 20
[ 7217.493747] eth1: rxqlen 20 --> 30
[ 7217.493795] eth1: rxqlen 30 --> 40
[ 7217.493828] eth1: rxqlen 40 --> 44
[ 7217.546888] eth1: ax88772 - Link status is: 0
[ 7264.650872] eth1: ax88772 - Link status is: 1

После этого помогает только отключение и подключение.

Однако самое интересное тут то, что я попробовал подключить кабель к стационарной (forcedeth) сетевой карте и увидел ровно такую-же проблему! Т.е. интерфейс отключился и линк по нему перестал обнаруживаться при заведомо корректном подключении и мигающим лампочкам:
[root@roman ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Link detected: no

Склонен предположить, что проблема в сетевом стеке ядра, где некорректно обрабатывается переполнение буфера приёмо-передачи!

(В ответ на комментарий №30)
> После этого помогает только отключение и подключение.
В случае с USB->Eth можно физически передёрнуть адаптер.
Для обоих также можно исправить проблему перегрузом модуля ядра asix или forcedeth.

Как мы понимаем, сетевой стек в этом случае сбрасывается, что ещё раз указывает на него!

(В ответ на комментарий №30)
> Похоже это не проблема asix, или как минимум не только.

Проявляется на других адаптерах? На каких?

(В ответ на комментарий №32)
> (В ответ на комментарий №30)
> > Похоже это не проблема asix, или как минимум не только.
> 
> Проявляется на других адаптерах? На каких?
nVidia Corporation MCP51 Ethernet Controller (rev a3)

[root@roman ~]# dmesg | grep forcedeth
[    8.110081] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
[    8.110333] forcedeth 0000:00:14.0: PCI INT A -> Link[APCH] -> GSI 21 (level, low) -> IRQ 21
[    8.110338] forcedeth 0000:00:14.0: setting latency timer to 64
[    8.625901] forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:1a:92:81:8c:4d
[    8.625906] forcedeth 0000:00:14.0: highdma pwrctl gbit lnktim desc-v3
[   23.303131] forcedeth 0000:00:14.0: eth0: no link during initialization