Jump to content
Калькуляторы

Дравйвер igb-5.2.15 с ядром 3.2 + очереди. Проблема.

Имеется двухголовая 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 для тестов. Может дело быть в этом? Проблема только тогда когда несколько очередей, с однйо очередью проблемы нет.

Share this post


Link to post
Share on other sites

После обновления драйвера до igb-5.2.15 (5.2.9) в логах появились сообщения

igb ... Detected Tx Unit Hang

, при RSS 1 всё работало, больше 1 - переставало, откатились до версии igb-5.2.5.

Share this post


Link to post
Share on other sites

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 by dnvk

Share this post


Link to post
Share on other sites

А, вот тут о чём. У меня вчера такая же проблема было.

Было - 3.10 + 5.1.чего-то там, обновился до 3.16 + 5.2.15 и сдохло.

Помог откат на ядро 3.10 (драйвер оставил 5.2.15). Чего-то они там между собой потерялись и не договорились.

Share this post


Link to post
Share on other sites

Если не секрет - чем вызвано такое странное количество очередей?

Если сервер терминирует VLAN или PPPx и роутит преимущественно в default, то я всегда так очереди распределяю. Эмпирическим путем заметил, что нагрузка так ровнее. На выходном интерфейсе, который смотрит в сторону default хватает одной очереди и одного ядра. Это все при условии что нет никаких шейперов.

Share this post


Link to post
Share on other sites

Драйвер v5.2.5 действительно исправил ситуацию. Видимо что-то не допилили в интеле.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.