![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dadvПозвольте рассказать вам одну поучительную историю, сэр! (c)
Жила-была в проекте FreeBSD ветка исходных текстов RELENG_6, и по сравнению с предыдущей пятеркой, была весьма хороша и в своё время на ней было построено немало серверов. Как и с любой веткой, случилось с ней забвение - пришло время, когда разработчики и база пользователей переместились на более новые релизы из ветки 7, а потом и 8 (скоро будет и 9). Сервера же, помаленьку обновляясь в пределах шестой ветки, достигли версии 6.4 (у кого RELEASE, у кого STABLE), а затем, по принципу "работает - не трогай" и стали работать дальше в таком состоянии.
6.4-RELEASE была выпущена в 2008-м, значимые для пользователей обновления после этого закончились где-то в первой половине 2010-го. До поры до времени, когда осенью 2011 не подписал наконец председатель правительства РФ постановление правительства РФ об изменении исчисления времени в РФ - аккурат за два месяца до этого самого изменения. После чего изменения эти благополучно попали в zoneinfo, а оттуда и в исходные тексты FreeBSD - во все ветки вплоть до шестой включительно.
После обновления очередного сервера шестой ветки (не первого в череде обновлений) оказалось, что policy routing через ipfw fwd сломался - "отполисенные" пакеты драйвер re(4) выпускал в Ethernet битыми (в показаниях tcpdump на источнике было всё чисто), в то время как с "отроученными" проблем, по-прежнему, никаких.
Долгие научные исследования показали, что в августе 2010-го (на дворе была уже 8.1-RELEASE) в шестерке тихой сапой прошло мелкое обновление ядерной подсистемы bus_dma(9), которое оказалось несовместимым с драйвером re(4), и не с ним одним - ещё затронут как минимум de(4).
Работающие и не трогаемые сервера продолжали работать, и факт поломки драйверов в шестерке не был обнаружен. До нынешнего момента. Откат указанного выше изменения полностью восстанавливает работу драйверов.
Формально, обновление bus_dma(9), выполненное jhb@, вроде бы вполне корректно и вина-то лежит на самих драйверах, некорректно использующих bus_dma. Автор драйвера re(4) pyunyh@ любезно предоставил бекпорт нынешней версии драйверов re и rl в шестую ветку, которые без проблем работают с обновленной bus_dma. Однако, поддержка шестой версии давно закончилась и он не собирается мержить новую версию в шестую ветку, а изменения в драйверах довольно значительны и протестированы пока только мной и только с одной картой из поддерживаемых драйвером.
Откат указанного изменения годовой давности в bus_dma тоже никто не будет делать (оно могло, в свою очередь, починить работу других устройств). Так и останется теперь шестерка в сломанном состоянии, видимо. А у меня до обновления серверов шестой ветки (до этого ещё очень долго) приживется обратный патч к этому изменению в bus_dma как меньшее зло при выборе между ним и новой версией двух драйверов.
To be honest,
Date: 2011-09-19 14:00 (UTC)Хотя, конечно, описание процесса (и тред в -stable@) поучительны вельми.
Re: To be honest,
Date: 2011-09-19 15:09 (UTC)Для меня серьезной причиной является совокупность причин: 1) принципиальное отсутствие удаленной консоли (машины являются канало-образующим/терминирующим оборудованием), как и квалифицированного персонала на "той" стороне; 2) отсутствие свободного дискового пространства для безконсольной эквелибристики; 3) нарушение принципа "работает - не трогай"; 4) отсутствие свободного времени для ломки того, что не сломано.
Serial console
Date: 2011-09-20 05:15 (UTC)Re: Serial console
Date: 2011-09-20 06:11 (UTC)> У меня везде одни и теже /etc/ttys и /etc/gettytab
Я через gettytab как-то не привык настраивать, я через /etc/rc.d/serial (в ранних версиях /etc/rc.serial) настраиваю порт. Особое внимание надо уделять настройке контроля потока и соответствии настройки возможностям кабеля. И лучше всего использовать полные кабеля (а не трехпроводки) и аппаратный контроль потока. А если кабель не полный, то обязательно переключаться с аппаратного на программный контроль потока.
Неверные настройки flow control - главная причина проблем serial console.
Re: Serial console
Date: 2011-09-20 10:54 (UTC)ttyu0 "/usr/libexec/getty autologin" vt100 on secure
А в /etc/gettytab
autologin|al.9600:\
:al=root:tc=3wire.9600:
Надо сюда еще и /etc/rc.d/serial задействовать
3wire u 0
Попробую, спасибо за подсказку. А подключаю я, как правило консоль, через USB2COM переходничок и nullmodem.
Re: Serial console
Date: 2011-09-20 11:17 (UTC)Re: Serial console
Date: 2011-09-20 11:38 (UTC)