На некоторых картах не срабатывает вызов DHCP при подъеме интерфейса. Обсуждалось тут http://lists.altlinux.ru/pipermail/sisyphus/2006-September/190672.html и http://lists.altlinux.ru/pipermail/desktop/2007-September/005294.html Предположительно, вызов ifplugstatus возвращает 3 (Unplugged) вместо ожидаемого 2 (Link beat detected). Под подозрением карты 0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) и какие-то из Интел (100Мбит)
--- desktop@ > Вдогрнку: в данный момент на sky2 у меня все работает без проблем. а на новом sk98lin? Недавно в сизифе/бранче появилась новая версия.
На sk98lin наступил я. Занимаюсь.
Как ручное исправление надо при поднятом DHCP добавить строку LINKDETECT=no в /etc/net/ifaces/ethX/options После этого всё работает.
Нельзя ли пострадавшим выяснить, перманентно ли сломано обнаружение линка в их модулях или спустя какое-то время после загрузки модуля и/или перевода интерфейса в UP состояние показывается корректно? И если так, то сколько секунд составляет это время? Спасибо.
После поднятия интерфейса (ip link set eth0 up) линк возникает через 2 секунды.
Вдогонку: линк показывается только после поднятия интерфейса.
Бывает до 30 сек для гигабита, воткнутого в cisco -- но это более характерно для серверов, которым более положено static ip.
Закодировано, проверять буду.
релиз 0.9.4 собран и залит
Алексей, проверите на своих? BTW это и к #11647 относится вроде.
Да, проверка не помешала бы.
Поставил etcnet-0.9.4-alt1 и kernel-modules-sk98lin-std-smp#10.21-alt1.132626.8 из Сизифа (что потянуло новое ядро). Под новым ядром карта определяется, но ни Ethernet на WiFi-карты не поднимаются - нет устройств. Под старым ядром те же старые симптомы.
"Нет устройств" это что?
при service network restart: NO SUCH DEVICE. И в ip link вылаётся lo и eth2.
Давайте тогда пока вернёмся к той версии ядра и модулей, на которой наблюдалась исходная ошибка, и проверим ещё раз.
Говорите, как проверять. и где взять последнюю версию etcnet, к которой rider@ руку приложил?
Для проверки необходимо взять систему, на которой из-за запаздывания индикации линка на порту интерфейс не конфигурировался, обновить там etcnet до версии 0.9.4-alt1 (которую я отправил в Sisyphus) и сказать, что дефект исчез (или не исчез). Другие версии релиза 0.9.4, если они существуют, имеет смысл обсуждать с их авторами.
(In reply to comment #16) > Говорите, как проверять. и где взять последнюю версию etcnet, к которой rider@ > руку приложил? В 0.9.4 все мои пожелания учтены. Более ни к чему я руку не прикладывал ;)
По поводу более нового ядерного модуля могу предложить сменить MODULE=sk98lin на MODULE=sky2. Иногда помогает.
Starting eth0: ....??..RTNETLINK answers: Network is unreachable ..OK Несмотря на это, всё работает.
С etcnet-0.9.4 всё работает. Перенесите в branch.
При выключении (или остановки) сети компьютер наглухо зависает.
(In reply to comment #20) > Starting eth0: ....??..RTNETLINK answers: Network is unreachable > ..OK Этого сообщения быть не должно. Скорее всего какой-то несогласованный хвост в конфигурации, нужно на неё взглянуть.
(In reply to comment #22) > При выключении (или остановки) сети компьютер наглухо зависает. В чём это выражается? Я проверил инсталляцию Desktop 4 на ноутбуке с портом Yukon (sk98lin), который имеет четырёхсекундную глухоту к линку после перехода в UP --- и старт и стоп обрабатываются корректно. [root@localhost ~]# rpmquery -a|fgrep etcnet etcnet-0.9.4-alt1 etcnet-defaults-server-0.9.4-alt1
(In reply to comment #7) > Бывает до 30 сек для гигабита, воткнутого в cisco -- но это более характерно для > серверов, которым более положено static ip. Скорее всего путаете с STP forward delay timer, который по умолчанию равен 15 секунд. Линк при этом никуда не девается.
судя по всему, ошибка исправлена
