AlKov Опубликовано 12 июня, 2018 · Жалоба CentOS 6.9, ядро 3.10.108-1.el6.elrepo.x86_64, accel-ppp version 03d9f8c59b6375325d7dfef0313c8c54705cfe0b, QinQ, ip-unnumbered, сетевые карты - две набортные intel I210. Непредсказуемо уходят в down ВСЕ IPoE интерфейсы, связанные с QinQ, включая "родителя"(eth0). Что примечательно, второго интерфейса (eth1) это ни в малейшей степени не касается, хотя на нём также поднят vlan, правда без второго тега - обычный 802.1q. Происходит это в-основном в момент перевода сегмента сети с PPPoE-Dual access на IPoE, иногда - гораздо реже - уже в "только IPoE состоянии". В логах - как системных, так и аццел-я - ничего, что бы могло пролить свет на причину. Написал "сторожа", который следит за состоянием "родительского интерфейса", выполняя цикл "ifconfig eth0 up... ifconfig eth0.XXXX.YYYY up" после его отключения. После чего всё восстанавливается. Добавил в "сторожа" запись dmesg, ifconfig eth0, ethtool -S eth0 (перед восстановлением интерфейсов). В dmesg в момент отключения вообще ничего, проливающего свет, не пишется. В messages и kern.log - аналогично. Такое ощущение, что на сервере в этот момент ШТАТНО выполняется команда ifconfig eth0 down, что соотв. приводит к отключению всех сабинтерфейсов. Вот "свежий" журнал проблемы Скрытый текст Цитата Tue Jun 12 11:16:01 MSK 2018 перезагрузка по причине отключения eth0 eth0 Link encap:Ethernet HWaddr A4:BF:01:25:B5:35 BROADCAST MULTICAST MTU:1526 Metric:1 RX packets:5657874962 errors:252 dropped:0 overruns:0 frame:252 TX packets:7859823059 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:2121981699879 (1.9 TiB) TX bytes:9454277946102 (8.5 TiB) NIC statistics: rx_packets: 5660054776 tx_packets: 7859823033 rx_bytes: 2150704111175 tx_bytes: 9492654973046 rx_broadcast: 2249911 tx_broadcast: 423981 rx_multicast: 2015235 tx_multicast: 19630 multicast: 2015235 collisions: 0 rx_crc_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 rx_long_length_errors: 252 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 0 tx_tcp_seg_failed: 0 rx_flow_control_xon: 0 rx_flow_control_xoff: 0 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_long_byte_count: 2150704111175 tx_dma_out_of_sync: 0 lro_aggregated: 0 lro_flushed: 0 tx_smbus: 0 rx_smbus: 2037749 dropped_smbus: 0 os2bmc_rx_by_bmc: 19630 os2bmc_tx_by_bmc: 0 os2bmc_tx_by_host: 19630 os2bmc_rx_by_host: 0 tx_hwtstamp_timeouts: 0 rx_hwtstamp_cleared: 0 rx_errors: 252 tx_errors: 0 tx_dropped: 0 rx_length_errors: 252 rx_over_errors: 0 rx_frame_errors: 0 rx_fifo_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_queue_0_packets: 558 tx_queue_0_bytes: 44980 tx_queue_0_restart: 0 tx_queue_1_packets: 0 tx_queue_1_bytes: 0 tx_queue_1_restart: 0 tx_queue_2_packets: 0 tx_queue_2_bytes: 0 tx_queue_2_restart: 0 tx_queue_3_packets: 7859822501 tx_queue_3_bytes: 9454277901122 tx_queue_3_restart: 0 rx_queue_0_packets: 5657874008 rx_queue_0_bytes: 2121981197712 rx_queue_0_drops: 0 rx_queue_0_csum_err: 0 rx_queue_0_alloc_failed: 0 rx_queue_1_packets: 72 rx_queue_1_bytes: 39600 rx_queue_1_drops: 0 rx_queue_1_csum_err: 0 rx_queue_1_alloc_failed: 0 rx_queue_2_packets: 828 rx_queue_2_bytes: 435567 rx_queue_2_drops: 0 rx_queue_2_csum_err: 0 rx_queue_2_alloc_failed: 0 rx_queue_3_packets: 54 rx_queue_3_bytes: 27000 rx_queue_3_drops: 0 rx_queue_3_csum_err: 0 rx_queue_3_alloc_failed: 0 Вот это - Цитата RX ..... errors:252 .... frame:252 наблюдалось ещё до падения интерфейса. После "восстановления" стало так Цитата RX ... errors:390 ... frame:390 На сабинтерфейсах этих ошибок нет. Где искать "автора ifconfig ... down" - в accel, или ОС? P.S. Ещё один момент - в самом начале перевода абонентов с PPPoE на IPoE обнаружился вот этот баг на коммутаторах D-Link. Теоретически он может быть причиной проблемы? Вполне возможно, что такой "кастрированный" пакет может и долетать до сервера с accel, несмотря на ACL (вырезают PPPoE, multicact и ipv6), которые вполне могут его пропустить по причине не соответствия стандарту. Правда сейчас функционал pppoe circuit id insertion в IPoE сегментах я везде отключил, но кто его знает, возможно при каких-то условиях он всё равно срабатывает.. Фикс для DES-3200 ещё не вышел, сделали только для DGS-3120, да и то, не до конца. P.P.S. Более подробно - с "уклоном" на accel - тут Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 июня, 2018 · Жалоба поставить для начала нормальные сетевки (те же 82576 копейки стоят). ну и нормальное (не патченное-перепатченное ископаемое с кучей бэкпортов из более свежих) ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 12 июня, 2018 · Жалоба 27 минут назад, NiTr0 сказал: поставить для начала нормальные сетевки (те же 82576 копейки стоят). ну и нормальное (не патченное-перепатченное ископаемое с кучей бэкпортов из более свежих) ядро. Всё это, конечно, здОрово, но только теоретически.. 1. Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке.. Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6). И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно.. 2. Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена. Игры со сборкой ванильных ядер на CentOS мы уже проходили, увы - НЕ успешно.. Т.о. в итоге получаем того же кота в мешке, со всеми вытекающими.. А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми.. А мне сейчас хотелось бы для начала определиться с источником проблемы (accel, или CentOS), и уже только потом принимать решение, в какую сторону двигаться.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 12 июня, 2018 · Жалоба 5 hours ago, AlKov said: Такое ощущение, что на сервере в этот момент ШТАТНО выполняется команда ifconfig eth0 down Небось какой-нибудь systemd или NetworkManager у вас там шалит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 12 июня, 2018 · Жалоба 1 час назад, rm_ сказал: Небось какой-нибудь systemd или NetworkManager у вас там шалит. Нет, тут дело не в этих динозаврах. Ни тот, ни другой не используются. А NetworkManager так и вовсе отсутствует в штатном софте, да и ещё до того, как он пропал в "базовой комплектации", всегда отключался в первую очередь. Вообще, ощущение такое, что от абонента прилетает какой-то изуродованный пакет, на который либо accel, либо ОС неадекватно реагируют. Например, вместо того, чтобы отправить в down eth0.3612.2501, на который этот пакет прилетел, гасят сразу eth0. Но это пока нЕчем ни подтвердить, ни отрицать.. Вот и ищу способы "поимки чёрной кошки". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DDR Опубликовано 12 июня, 2018 · Жалоба Для "кошек" можете попробовать что-нибудь вроде rtmon -0 /var/log/netlink.log Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 июня, 2018 · Жалоба 9 часов назад, DDR сказал: Для "кошек" можете попробовать что-нибудь вроде rtmon -0 /var/log/netlink.log Посмотрел, что могу из этого получить. Навскидку - практически ничего. ..... 2042: eth0.3898.2302@eth0.3898: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 250: eth0.3906.2501@eth0.3906: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 251: eth0.3898.1905@eth0.3898: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 252: eth0.3906.2305@eth0.3906: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff 254: eth0.3869.703@eth0.3869: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff Timestamp: Wed Jun 13 09:36:36 2018 526588 us 172.16.15.65 dev eth0.3815.808 lladdr 90:72:82:11:8b:ae STALE Timestamp: Wed Jun 13 09:36:36 2018 830584 us 172.16.14.186 dev eth0.3716.404 lladdr 84:16:f9:c5:96:19 STALE ..... Что полезного по проблеме отсюда можно вытянуть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 июня, 2018 · Жалоба 17 часов назад, AlKov сказал: Всё это, конечно, здОрово, но только теоретически.. 1. Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке.. Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6). И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно.. 2. Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена. Игры со сборкой ванильных ядер на CentOS мы уже проходили, увы - НЕ успешно.. Т.о. в итоге получаем того же кота в мешке, со всеми вытекающими.. А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми.. А мне сейчас хотелось бы для начала определиться с источником проблемы (accel, или CentOS), и уже только потом принимать решение, в какую сторону двигаться.. 1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте. Попробуйте для начала проверенную карту. 2. Ядро с elrepo вовсе не гарантия стабильности, скорее наоборот. Я б вручную собрал что-то свежее. Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TheUser Опубликовано 13 июня, 2018 · Жалоба 17 часов назад, AlKov сказал: А машина уже в продакшен, пока ещё не ахти какой (~350 абонентов), но с живыми людьми.. Как же вы без резерва запускаетесь в продакшн А со стороны коммутатора что по ошибкам/логам? Flow-control отключен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 13 июня, 2018 · Жалоба Из линуксов мне более-менее подходящим кажется Debian. CentOS ценен только из-за родства с RedHat. Да и версия 6.9 старовата, ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 июня, 2018 · Жалоба @alibek Для линуксов дистрибутив особой роли не играет, любой можно приготовить как нужно. [kayot@IPoE1 ~]$ cat /etc/redhat-release CentOS release 6.8 (Final) [kayot@IPoE1 ~]$ uname -a Linux IPoE1.localdomain 3.18.42 #1 SMP Wed Sep 21 08:20:09 EEST 2016 x86_64 x86_64 x86_64 GNU/Linux [kayot@IPoE1 ~]$ uptime 11:26:38 up 507 days, 12:53, 1 user, load average: 0.72, 0.86, 0.84 [kayot@IPoE1 ~]$ accel-cmd show stat | grep active active: 2008 [kayot@IPoE1 ~]$ ip link show | grep bond1 | wc -l 4335 Такой же IPOE-QinQ БРАС, accel-ppp. Аптайм ограничен профилактиками, 1.5 года на данный момент. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 июня, 2018 · Жалоба 1 час назад, kayot сказал: 1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте. Попробуйте для начала проверенную карту. 2. Ядро с elrepo вовсе не гарантия стабильности, скорее наоборот. Я б вручную собрал что-то свежее. Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем? Нет свободной 82576, надо заказывать. Да и никаких проблем до accel-я не было c I210, три машины работают на том же CentOS 6.9 и не кашляют. Правда, на родном ядре. 3.10 в данном случае только из-за accel поставил, т.к. на родном не собирается он.. Плюс ко всему - ещё раз сделаю акцент - второй интерфейс (eth1), не связанный с accel и QinQ работает без проблем. Через него трафик уходит на NAT/маршрутизатор. Драйвер igb свежий - 5.3.5.4, под ядро пересобран. To @TheUser - коммутатор 100% не при делах, т.к. изначально проблема появилась когда сервер с accel был подключен к совсем другому коммутаторе, Flow-control отключен. В логах его только down/up порта. Падает только тот порт, который подключён к интерфейсу eth0 сервера с accel. Т.е. "инициатива" отключения порта 100% со стороны сервера, инициированная явно каким-то "странным" пакетом от клиентов. Более склоняюсь к тому, что это проблема accel, т.к. со стороны ОС никаких сообщений о НЕштатных событиях нет, но девелоперы пока не подтверждают это.. Вот и пытаюсь понять/посмотреть, что это такое непотребное генерят клиенты.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 июня, 2018 · Жалоба 19 часов назад, AlKov сказал: Соглашусь, что 82576 - это чуть ли не единственная надёжная и проверенная временем сетевуха, но.. Увы - в прошлом веке.. с какой это радости? 19 часов назад, AlKov сказал: Дело в том, что на данной материнке (Intel S1200SP) шина PCI-Ex живёт - как это ни странно - в процессоре (Xeon E3-1220 v6). а что странного-то? ну в проце контроллер, и? причем это к сетевухе-то??? 19 часов назад, AlKov сказал: И будет ли 82576 работать лучше "родных" I210 при таком раскладе, совсем не известно.. а если бы pci-e контроллер был в отдельном чипе, общающемся с кмнем по QPI, что бы изменилось??? как минимум - на 82576 побольше буфер пакетов, ну и как работают на высоком pps дешевые i210 - вопрос. мож у них крышу сносит от флуда. хотя при этом должно быть что-то в dmesg но не факт. если не хотите менять - как минимум свежий драйвер соберите. а лучше - со сежим ядром. ну и dmesg посмотрите. 19 часов назад, AlKov сказал: Данное "ископаемое ядро" взято не с потолка, а с того же elrepo, где позиционируется стабильным для CentOS 6, которая и установлена. оно давно протухло, и как/кемҐкакими патчами патчено - огромный вопрос. в чем смысл держать тухлые оси на брасах (где таки желательно свежая сетевая подсистема) - для меня загадка. тем более - "клон ынтырпрайза" совсем не значит "стабильно работает". я в свое время огребал на центоси 5 висы kvm-а после очередного прихода "свежих патчей"... 1 час назад, kayot сказал: Ну или хотя бы igb-драйвер руками соберите свежий, i210 же на нем? скорее e1000e. i210/211 - наследник 82574. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 13 июня, 2018 · Жалоба 2 часа назад, NiTr0 сказал: с какой это радости? потому что кто-то не в курсе про i350 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 июня, 2018 · Жалоба ethtool в руки и отключаем фичи на сетевухе, всякие gre, tcp, vlan оффлоады. В вашем случае видимо vlan оффлоад точно, по остальным фичам лучше поискать тут на форуме, я точный сипсок не помню того что для роутера вредно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 15 июня, 2018 · Жалоба 10 часов назад, Ivan_83 сказал: ethtool в руки и отключаем фичи на сетевухе, всякие gre, tcp, vlan оффлоады. В вашем случае видимо vlan оффлоад точно, по остальным фичам лучше поискать тут на форуме, я точный сипсок не помню того что для роутера вредно. Уже проходили.. Не помогает.. А вот на "вредный список" я бы всё же взглянул.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 июня, 2018 · Жалоба В 13.06.2018 в 15:11, GrandPr1de сказал: потому что кто-то не в курсе про i350 ну пока их не щупал, да и как вышли - были сырыми (то ли дрова то ли железо). а 82576 - они стоят копейки, продаются на каждом углу, и работают без нареканий. а что еще надо для исключения железных проблем? можно было бы конечно и 82571 насоветовать, но они горячее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 17 июня, 2018 · Жалоба 16 минут назад, NiTr0 сказал: а 82576 - они стоят копейки, продаются на каждом углу, и работают без нареканий. а что еще надо для исключения железных проблем? Ну про то, что работают без проблем - "за" двумя руками, а вот насчёт "копеек" и "на каждом углу" - готов поспорить. Причём по обоим "пунктам". Заказал три дня тому.. Нашлось только в одном месте и за 11500 руб. Это ежли шо, 1 150 000 копеек однако.. ;) P.S. Ну и ближе к теме немного - мне почему-то больше думается, что причина живёт всё же где-то в accel, а не в железе/ОС. Т.к. ещё раз повторюсь, в логах ОС пусто, от слова "совсем" и по ощущениям всё выглядит так, как будто кто-то выполнил команду "ifconfig eth0 down". Плюс ко всему, похожая проблема уже была, но там accel загонял в down только конкретный vlan интерфейс. И она (проблема) подтверждалась на явно другом железе и возможно другой ОС. Либо в моём случае имеет место какая-то программная "нестыковка" accel с ядром/ОС/драйвером сетевухи.. Больше всего в данном случае напрягает неизвестность причины проблемы - что такое может прилететь от клиентов/коммутаторов, чтобы нагнать такого страху на работающий софт.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2018 · Жалоба "Мнения разделились".. Причём, мои собственные.. :) Похоже, I210 действительно "дешманское г..." Нагуглил очень близкую к моей тему, где в итоге обнаружилось следующее Цитата причина: первый ehternet интерфейс на этой материнке идет на прямую от чипсета–проца (soc n3700) – согласно схемы официального мануала материнской платы, а другие 3 интерфейса идут от проца к так называемому Pericom Semiconductor Device, а дальше уже распределяются на три ehternet контролера и mPCI. Отсюда можно сделать вывод, что... В 13.06.2018 в 11:03, kayot сказал: 1. PCIe живет в процессоре еще со времен выхода архитектуры sandy bridge, совсем ничего странного. И никакой разницы нет, распаян сетевой чип на материнке или стоит в слоте. .. далеко не факт... Конечно, у автора другая материнка (супермикро какая-то), а у меня Intel S1200SPOR, но вряд ли архитектура сильно отличается. Учитывая всё вышесказанное про ethernet на процессоре, не факт что 82576 решит проблему.. Но выбора нет.. Карту заказал, жду в конце этой недели.. P.S. @kayot , кстати, у Вас какие сетевые карты используются? P.P.S. Ещё одна необъяснимая фигня - пока не приехала 82576, решил апдейтнуть драйвер. Захожу на intel download и вижу следующее.. Цитата The igb-x.x.x.tag.gz is designed to work with Intel® 82575/6, 82580, I350, and I210/211-based Adapters/Connections under Linux*. The latest version and earlier versions of this driver are available from SourceForge*.If your Intel® Network Adapter/Connection is not 82575/6, 82580, or I350-based, you should use one of the following drivers: e1000e-x.x.x.x.tar.gz driver supports the Intel® PRO/1000 PCI-E* (82563/6/7, 82571/2/3/4/7/8, or 82583) based Gigabit Network Adapters e1000.x.x.x.tar.gz support all PCI and PCI-X Intel® Gigabit Network Adapters/Connections Интересно, и как это понимать?? Какое-то прям "вам шашечки, или ехать"! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 18 июня, 2018 · Жалоба 4 минуты назад, AlKov сказал: .. далеко не факт... Факт. В той теме какая-то супер-компактная мать на атоме, pci-e линий недостаточно(даже pci-e слот физически 8х а реально 1х) и стоит коммутатор для подключения 4ех сетевок. В вашей же плате и проце 20 линий, все подключено независимо напрямую к CPU. 8 минут назад, AlKov сказал: кстати, у Вас какие сетевые карты используются? На одном сервере 2х i340-t4(итого 8 портов в бондах) на 82580, на втором вообще бортовые броадкомы HPшного сервера вперемешку с внешней ET 82576. Ничего не отваливается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 июня, 2018 · Жалоба 2 часа назад, kayot сказал: В вашей же плате и проце 20 линий, все подключено независимо напрямую к CPU. а не факт к слову, обычно pci-e x1 2.0 и прочие набортные девайсы заводятся на южный мост (pch который). таки да, угадал - интегрированные сетевки традиционно на линиях ЮМ висят: https://www.intel.com/content/dam/support/us/en/documents/server-products/S1200SP_TPS_AllSKU.PDF не, в принципе не критично и почти ни на что не влияет, но все же... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 18 июня, 2018 · Жалоба 3 часа назад, NiTr0 сказал: а не факт к слову, обычно pci-e x1 2.0 и прочие набортные девайсы заводятся на южный мост (pch который). Вот и у меня такие же ощущения.. Остаётся только надеяться, что они ошибочны. И Вы 100% правы насчёт В 13.06.2018 в 12:59, NiTr0 сказал: скорее e1000e. i210/211 - наследник 82574. Вот только сейчас удосужился полистать даташит на i210.. А в нём аглицким по белому - Цитата Intel® 82574_82583 Gigabit Ethernet Controller to I210_I211 – Design Guide И это называется "полный писец".. Обидно, что узнал об этом только сейчас.. Когда-то уже обжигался на 82574 - это было нЕчто, как это дерьмо себя вело на сети! Мда... Так глупо наступить на грабли молодости... :( P.S. Вот ещё что нагуглилось в "связке" 82574 и отключение интерфейса. Не особо верится, конечно, но.. Уж очень удачное совпадение двух - вернее даже трёх - "параметров". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 июня, 2018 · Жалоба В 18.06.2018 в 14:35, AlKov сказал: Вот и у меня такие же ощущения.. Остаётся только надеяться, что они ошибочны. не ошибочны, в ДШ есть схема. в принципе пофиг, где контроллер висит, пока ширины DMI хватает. В 18.06.2018 в 14:35, AlKov сказал: Когда-то уже обжигался на 82574 - это было нЕчто, как это дерьмо себя вело на сети! да нормально они себя ведут, даже на брасах с 600-700 мбитами трафика. свои деньги отрабатывают, с рылтеками и прочими аферосами не сравнятся. но учитывая цену 82576 - экономить на спичках не стоит. https://www.ebay.com/itm/Intel-82576EB-Dual-RJ45-Port-E1G42ET-PCI-E-X1-Gigabit-Server-Adapter-ROS-VMare/273085452445 или https://www.ebay.com/itm/Dual-Port-PCI-EX4-1Gbps-Intel-82576EB-E1G42ET-EF-E1G44ET-Gigabit-Server-Adapter/263753128226 с с шиной х4 (хотя там и х1 2.0 должно хватить с головой) да, фирменный интел (или подделка под него) - немногим дороже https://www.ebay.com/itm/NEW-Dual-Port-PCI-EX4-Intel82576-E1G42ET-PRO-10-100-1000M-Server-Adapter/172175117383 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 20 июня, 2018 · Жалоба По-моему вас не туда понесло, автор прав, если в dmesg пусто - проблема абсолютно точно не аппаратная. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 20 июня, 2018 · Жалоба 8 часов назад, NiTr0 сказал: да нормально они себя ведут, даже на брасах с 600-700 мбитами трафика. Ага, я тоже так думал (про I210) до некоторых пор. И действительно, на двух серверах (Border/NAT) к ним (I210) у меня претензий никаких не было. До того момента, пока они не оказались на L2 доступе (текущая тема). Вот тут-то это г.. и всплыло.. Ну а насчёт конкретно 82574, "былин" хватает, кроме моих. раз два три Ну и ещё встречались "баллады" на "нерусских матах". Эх.. Если бы я удосужился внимательно прочесть даташит на I210, то даже бы и мысли не возникло пытаться их использовать. Вот, пока писал, вспомнил свою последнюю "былину" про 82574 - периодически - раза два в месяц - вставал колом сервак на супермикре FreeBSD/mpd5/PPPoE (да-да, тот самый "L2 доступ"). Выглядело это вообще "красиво" - находясь в ступоре, железка реагировала только на кнопку "power", ни сеть, ни клаву не признавала. На "борту" - как это всегда бывает в супер-пупер-микрах - великолепный винегрет - две РАЗНЫЕ сетевухи - 82574/82579. Совсем немного задумался (т.к. сексуальный опыт с 82574 уже имелся).. И... Поставил 82576 и забыл про железку. 8 минут назад, rm_ сказал: По-моему вас не туда понесло, автор прав, если в dmesg пусто - проблема абсолютно точно не аппаратная. Если под "автором" подразумевается моя персона, то я уже так не думаю (см. выше). :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...