SokolovS Posted January 22, 2015 · Report post Имеется двухголовая Intel Corporation 82576 Gigabit Network Connection Ядро: 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux Дравйвер: igb-5.2.15 После установки параметров igb в следующие: options igb IntMode=2,2 InterruptThrottleRate=3,3 RSS=3,1 QueuePairs=1,1 Первый интерфейс, для которого задано 3 очереди перестает работать. Второй продолжает нормально функционировать. При отсуствии параметров драйвера оба работают нормально, по одной TxRx очереди на интерфейс. Выглядит все так: интерфейс падает и поднимается при попытке передачи пакетов. Подобная ситуация повторяется на CentOS 6.5 с ядром 3.1 с ELRepo. Кто-то сталкивался с подобным? Как решается. Сейчас машинка включена в порты 100BaseT для тестов. Может дело быть в этом? Проблема только тогда когда несколько очередей, с однйо очередью проблемы нет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Abram Posted January 22, 2015 · Report post Если не секрет - чем вызвано такое странное количество очередей? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
anix Posted January 23, 2015 · Report post После обновления драйвера до igb-5.2.15 (5.2.9) в логах появились сообщения igb ... Detected Tx Unit Hang , при RSS 1 всё работало, больше 1 - переставало, откатились до версии igb-5.2.5. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dnvk Posted January 23, 2015 (edited) · Report post 2SokolovS, буквально вчера поймал подобные чудеса при попытке запустить сетвушку e1g42et. Ядро 3.14.29, igb 5.2.15, дистрибутив на базе slackware 14.0. При подгрузке модуля с RSS=2,2 - получал постоянное "моргание" портов. На коммутаторе порты периодически включались-выключались. В логах тазика наблюдал: igb 0000:02:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None igb 0000:02:00.0: Detected Tx Unit Hang Tx Queue <1> TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean] time_stamp <2cd0c1> next_to_watch <ed345000> jiffies <2cdc64> desc.status <d8000> igb 0000:02:00.0: Detected Tx Unit Hang Tx Queue <1> TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean] time_stamp <2cd0c1> next_to_watch <ed345000> jiffies <2ce434> desc.status <d8000> igb 0000:02:00.0: Detected Tx Unit Hang Tx Queue <1> TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean] time_stamp <2cd0c1> next_to_watch <ed345000> jiffies <2cec04> desc.status <d8000> igb 0000:02:00.0: Detected Tx Unit Hang Tx Queue <1> TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean] time_stamp <2cd0c1> next_to_watch <ed345000> jiffies <2cf3d4> desc.status <d8000> igb 0000:02:00.0 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Периодически выпадало и такое: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x1dd/0x1f0() NETDEV WATCHDOG: eth2 (igb): transmit queue 0 timed out Modules linked in: xt_TCPMSS iptable_mangle xt_CT iptable_raw xt_REDI RECT xt_comment xt_hashlimit xt_limit xt_conntrack xt_set xt_multiport xt_tcpudp ipt_NETFLOW(O) ipt_REJECT xt_LOG iptable_ nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables ip_set_hash_ip ip_s et nfnetlink 8021q garp stp llc igb(O) e1000e(O) agpgart parport_pc parport hid_generic usbhid hid serio_raw lpc_ich mfd_c ore i2c_i801 i2c_core hwmon ehci_pci ehci_hcd ptp pps_core dca ipmi_si evdev ipmi_msghandler video tpm_tis tpm [last unloa ded: igb] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.14.29-smp #1 Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 00000000 00000000 ee40bec8 c1567a2e ee40bf08 ee40bef8 c1043654 c16b619c ee40bf24 00000000 c16b2a97 00000108 c14e7dbd c14e7dbd ee6e4000 00000000 000423b8 ee40bf10 c1043713 00000009 ee40bf08 c16b619c ee40bf24 ee40bf44 Call Trace: [<c1567a2e>] dump_stack+0x41/0x52 [<c1043654>] warn_slowpath_common+0x84/0xa0 [<c14e7dbd>] ? dev_watchdog+0x1dd/0x1f0 [<c14e7dbd>] ? dev_watchdog+0x1dd/0x1f0 [<c1043713>] warn_slowpath_fmt+0x33/0x40 [<c14e7dbd>] dev_watchdog+0x1dd/0x1f0 [<c104d974>] call_timer_fn+0x34/0xe0 [<f82bd538>] ? e1000e_poll+0xf8/0x2f0 [e1000e] [<c14e7be0>] ? dev_deactivate_queue.constprop.33+0x60/0x60 [<c104eaf9>] run_timer_softirq+0x139/0x1e0 [<c14e7be0>] ? dev_deactivate_queue.constprop.33+0x60/0x60 [<c1047dab>] __do_softirq+0xcb/0x240 [<c1047ce0>] ? ftrace_raw_event_irq_handler_exit+0x120/0x120 <IRQ> [<c1048105>] ? irq_exit+0x85/0x90 [<c156cea8>] ? smp_apic_timer_interrupt+0x38/0x50 [<c156c17c>] ? apic_timer_interrupt+0x34/0x3c [<c1086272>] ? cpu_startup_entry+0xe2/0x210 [<c1560317>] ? rest_init+0x67/0x70 [<c174cafe>] ? start_kernel+0x3a3/0x3a9 [<c174c54c>] ? repair_env_string+0x51/0x51 [<c174c380>] ? i386_start_kernel+0x12e/0x131 ---[ end trace b0bda29df539aaaa ]--- При RSS отличном от 1,1 - происходила такая ерунда. Переключения QueuePairs - эффекта не давали. Настройки ethtool - gro off gso off tso off Также не приносили эффекта. Возможно чего-то не хватало в ядре. Занялся перебором версий igb. Остановился на 5.2.5 - работает с тем же ядром. Всё-таки интересно чего не хватило igb 5.2.15? 2anix, чуть-чуть опередили. Я долго клавиатуру топтал. Edited January 23, 2015 by dnvk Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Abram Posted January 23, 2015 · Report post А, вот тут о чём. У меня вчера такая же проблема было. Было - 3.10 + 5.1.чего-то там, обновился до 3.16 + 5.2.15 и сдохло. Помог откат на ядро 3.10 (драйвер оставил 5.2.15). Чего-то они там между собой потерялись и не договорились. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pppoetest Posted January 23, 2015 · Report post Detected Tx Unit Hang В моем случае помогло lro off gro off tso off gso off Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted January 23, 2015 · Report post Если не секрет - чем вызвано такое странное количество очередей? Если сервер терминирует VLAN или PPPx и роутит преимущественно в default, то я всегда так очереди распределяю. Эмпирическим путем заметил, что нагрузка так ровнее. На выходном интерфейсе, который смотрит в сторону default хватает одной очереди и одного ядра. Это все при условии что нет никаких шейперов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SokolovS Posted January 23, 2015 · Report post Драйвер v5.2.5 действительно исправил ситуацию. Видимо что-то не допилили в интеле. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...