36863 2019-06-05 06:08:17 +0300 Просьба обновить драйвере сетевых карт Intel до 5.2.0 2019-11-16 15:32:14 +0300 1 1 4 Development Sisyphus kernel-image-std-def unstable all Linux CLOSED FIXED P3 critical --- 1 taf vt asy kernelbot placeholder vt qa-sisyphus oldest_to_newest 182212 0 taf 2019-06-05 06:08:17 +0300 Ранее, в ветке ядра 4.9 собирались драйвера Intel версии 5.2.1, в версиях 4.19 собираются старые драйвера 5.1.0 Хотелось бы чтобы и далее в ядрах std-def драйвера были 5.2.1 и свежее. 182214 1 rider 2019-06-05 07:48:33 +0300 Если уж обновлять, то пожалуй весь стек интеловских драйверов: https://sourceforge.net/projects/e1000/files/ И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами на mainline. 182218 2 boyarsh 2019-06-05 10:20:34 +0300 > И да, можно собрать внешними модулями для Sisyphus, но лучше всё-таки патчами > на mainline. Не лучше. Надо собрать именно отдельными модулями. Отдельные модули меньше разваливаются при обновлении ядра внутри ветки и у них понятный workflow переезда между ветками. Если что-то живёт вне ядра и у него отдельный релизный цикл, не привязанный к ядру -- пусть будет отдельными модулями. 182219 3 rider 2019-06-05 10:30:09 +0300 Отдельные модули нельзя делать для обратной совместимости - потерять доступ к серверу после обновления ядра по причине того, что ментейнер вынес модули в отдельные пакеты - недопустимо. Как вариант - подумать на предмет зависимостей, но помоему это для ядерных модулей не работает из-за allow-duplicated. 182223 4 boyarsh 2019-06-05 12:17:00 +0300 (В ответ на комментарий №3) > Отдельные модули нельзя делать для обратной совместимости - потерять доступ к > серверу после обновления ядра по причине того, что ментейнер вынес модули в > отдельные пакеты - недопустимо. Переименовать в этих отдельных пакетах модули и положить в пакет с ними blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего пакета будет работать ядерная реализация. Так или иначе, эксперимент с включением патчем модулей, имеющих отдельный релизный цикл я считаю провалившимся и повторять его не собираюсь. > > Как вариант - подумать на предмет зависимостей, но помоему это для ядерных > модулей не работает из-за allow-duplicated. 182225 5 rider 2019-06-05 12:28:28 +0300 (В ответ на комментарий №4) > (В ответ на комментарий №3) > > Отдельные модули нельзя делать для обратной совместимости - потерять доступ к > > серверу после обновления ядра по причине того, что ментейнер вынес модули в > > отдельные пакеты - недопустимо. > > Переименовать в этих отдельных пакетах модули и положить в пакет с ними > blacklist файл. Тогда их можно не выключать в ядре и при отсутствии внешнего > пакета будет работать ядерная реализация. У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре патчем обновлять. > > Так или иначе, эксперимент с включением патчем модулей, имеющих отдельный > релизный цикл я считаю провалившимся и повторять его не собираюсь. А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание патча, это же совсем просто. > > > > > Как вариант - подумать на предмет зависимостей, но помоему это для ядерных > > модулей не работает из-за allow-duplicated. 182226 6 taf 2019-06-05 12:33:48 +0300 А насколько будет удачным вынесение внешних драйверов сетевух при очередной смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча. 182227 7 boyarsh 2019-06-05 12:43:39 +0300 > У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре > патчем обновлять. Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей -- это твои грабли. > А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание > патча, это же совсем просто. А мне так не кажется. Периодически при выходе нового релиза приходится решать конфликты в этих модулях. И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не какое-то редкостное событие, а бывает раз в полтора месяца. У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их собирается множество. И только ixgb надо обязательно тащить в ядро. 182228 8 rider 2019-06-05 14:05:42 +0300 (В ответ на комментарий №7) > > У меня, например, скрипты заточены на имена модулей. Это ещё хуже, чем в ядре > > патчем обновлять. > Если ты разложил себе грабли, написав скрипты, заточенные на имена модулей -- > это твои грабли. Да не я один такой. Проверка или загрузка модуля по имени это зачастую стандартная схема деплоя. Убирая одну проблему ты создаёшь кучу новых, главная из которых - несовместимость с апстримом. > > > А мне кажется, это было очень удачно. У меня ушло около 15 минут на создание > > патча, это же совсем просто. > А мне так не кажется. Периодически при выходе нового релиза приходится решать > конфликты в этих модулях. > И выход нового ядра, на которое прежний патч, разумеется, не ляжет это не > какое-то редкостное событие, а бывает раз в полтора месяца. Ну и что ? Не вижу проблем раз в полтора месяца пройтись по драйверам и смержить. Если патч перестал накладываться - это в любом случае повод заглянуть внутрь и посмотреть что происхожиди. > > У нас есть хороший, удобный и работающий механизм сборки внешних модулей, их > собирается множество. И только ixgb надо обязательно тащить в ядро. Да если бы изначально собирали ixgbe отдельно от ядра, тотак бы и было. e1000, кстати, одно время был вне ядра, потом зачем-то втащили внутрь (что делается заметно легче). 182275 9 asy 2019-06-06 15:18:02 +0300 (In reply to comment #6) > А насколько будет удачным вынесение внешних драйверов сетевух при очередной > смене версии ядра (типа 4.19 -> 5.0)? А до этого момента держать в виде патча. На самом деле если момент выбирать, то это прямо сейчас, пока про p9 официально не объявлено. Переделывать в рамках бранча плохо, а вот в момент перехода с бранча на бранч - это ещё более-менее. И, всё же, лучше для всех ядер, так как бывет надо скакать бежду std-def и un-def. 185605 10 taf 2019-11-16 15:32:14 +0300 Отдельно собран модуль kernel-modules-ixgbe-std-def