Chinaunix

标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题 [打印本页]

作者: platinum    时间: 2005-10-18 11:48
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
做 NAT 服务器,当负载过大时,总出现
Oct 17 14:56:04 server kernel: e1000: eth0: e1000_watchdog: NIC Link is Down
Oct 17 14:56:08 server kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
Oct 17 14:56:09 server kernel: e1000: eth0: e1000_watchdog: NIC Link is Down
Oct 17 14:56:15 server kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex

网卡反复 UP、DOWN,甚至导致系统自动重启
这个 e1000_watchdog 是做什么用的?为何有如此现象?如何不让他自动 UP、DOWN ?
作者: yidou    时间: 2005-10-18 12:03
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题

  1. static void
  2. e1000_watchdog(unsigned long data)
  3. {
  4.         struct e1000_adapter *adapter = (struct e1000_adapter *) data;
  5.         struct net_device *netdev = adapter->;netdev;
  6.         struct e1000_desc_ring *txdr = &adapter->;tx_ring;
  7.         unsigned int i;
  8.         uint32_t link;

  9.         e1000_check_for_link(&adapter->;hw);

  10.         if((adapter->;hw.media_type == e1000_media_type_internal_serdes) &&
  11.            !(E1000_READ_REG(&adapter->;hw, TXCW) & E1000_TXCW_ANE))
  12.                 link = !adapter->;hw.serdes_link_down;
  13.         else
  14.                 link = E1000_READ_REG(&adapter->;hw, STATUS) & E1000_STATUS_LU;

  15.         if(link) {
  16.                 if(!netif_carrier_ok(netdev)) {
  17.                         e1000_get_speed_and_duplex(&adapter->;hw,
  18.                                                    &adapter->;link_speed,
  19.                                                    &adapter->;link_duplex);

  20.                         DPRINTK(LINK, INFO, "NIC Link is Up %d Mbps %s\n",
  21.                                adapter->;link_speed,
  22.                                adapter->;link_duplex == FULL_DUPLEX ?
  23.                                "Full Duplex" : "Half Duplex");

  24.                         netif_carrier_on(netdev);
  25.                         netif_wake_queue(netdev);
  26.                         mod_timer(&adapter->;phy_info_timer, jiffies + 2 * HZ);
  27.                         adapter->;smartspeed = 0;
  28.                 }
  29.         } else {
  30.                 if(netif_carrier_ok(netdev)) {
  31.                         adapter->;link_speed = 0;
  32.                         adapter->;link_duplex = 0;
  33.                         DPRINTK(LINK, INFO, "NIC Link is Down\n");
  34.                         netif_carrier_off(netdev);
  35.                         netif_stop_queue(netdev);
  36.                         mod_timer(&adapter->;phy_info_timer, jiffies + 2 * HZ);
  37.                 }

  38.                 e1000_smartspeed(adapter);
  39.         }

  40.         e1000_update_stats(adapter);

  41.         adapter->;hw.tx_packet_delta = adapter->;stats.tpt - adapter->;tpt_old;
  42.         adapter->;tpt_old = adapter->;stats.tpt;
  43.         adapter->;hw.collision_delta = adapter->;stats.colc - adapter->;colc_old;
  44.         adapter->;colc_old = adapter->;stats.colc;
  45.        
  46.         adapter->;gorcl = adapter->;stats.gorcl - adapter->;gorcl_old;
  47.         adapter->;gorcl_old = adapter->;stats.gorcl;
  48.         adapter->;gotcl = adapter->;stats.gotcl - adapter->;gotcl_old;
  49.         adapter->;gotcl_old = adapter->;stats.gotcl;

  50.         e1000_update_adaptive(&adapter->;hw);

  51.         if(!netif_carrier_ok(netdev)) {
  52.                 if(E1000_DESC_UNUSED(txdr) + 1 < txdr->;count) {
  53.                         /* We've lost link, so the controller stops DMA,
  54.                          * but we've got queued Tx work that's never going
  55.                          * to get done, so reset controller to flush Tx.
  56.                          * (Do the reset outside of interrupt context). */
  57.                         schedule_work(&adapter->;tx_timeout_task);
  58.                 }
  59.         }

  60.         /* Dynamic mode for Interrupt Throttle Rate (ITR) */
  61.         if(adapter->;hw.mac_type >;= e1000_82540 && adapter->;itr == 1) {
  62.                 /* Symmetric Tx/Rx gets a reduced ITR=2000; Total
  63.                  * asymmetrical Tx or Rx gets ITR=8000; everyone
  64.                  * else is between 2000-8000. */
  65.                 uint32_t goc = (adapter->;gotcl + adapter->;gorcl) / 10000;
  66.                 uint32_t dif = (adapter->;gotcl >; adapter->;gorcl ?
  67.                         adapter->;gotcl - adapter->;gorcl :
  68.                         adapter->;gorcl - adapter->;gotcl) / 10000;
  69.                 uint32_t itr = goc >; 0 ? (dif * 6000 / goc + 2000) : 8000;
  70.                 E1000_WRITE_REG(&adapter->;hw, ITR, 1000000000 / (itr * 256));
  71.         }

  72.         /* Cause software interrupt to ensure rx ring is cleaned */
  73.         E1000_WRITE_REG(&adapter->;hw, ICS, E1000_ICS_RXDMT0);

  74.         /* Early detection of hung controller */
  75.         i = txdr->;next_to_clean;
  76.         if(txdr->;buffer_info[i].dma &&
  77.            time_after(jiffies, txdr->;buffer_info[i].time_stamp + HZ) &&
  78.            !(E1000_READ_REG(&adapter->;hw, STATUS) & E1000_STATUS_TXOFF))
  79.                 netif_stop_queue(netdev);

  80.         /* Reset the timer */
  81.         mod_timer(&adapter->;watchdog_timer, jiffies + 2 * HZ);
  82. }
复制代码

[ 本帖最后由 platinum 于 2005-11-3 14:24 编辑 ]
作者: platinum    时间: 2005-10-18 12:19
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题

  1. if((adapter->;hw.media_type == e1000_media_type_internal_serdes) &&
  2.   !(E1000_READ_REG(&adapter->;hw, TXCW) & E1000_TXCW_ANE))
  3. link = !adapter->;hw.serdes_link_down;
  4. else
  5. link = E1000_READ_REG(&adapter->;hw, STATUS) & E1000_STATUS_LU;
复制代码

这段话什么意思?什么情况会导致 link = 0 ?
如果删除了 else 后面的东西重新编译驱动,会不会有副作用?
作者: colddawn    时间: 2005-10-18 12:56
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
watchdog这个好像是检测到坏桢认为可能硬件出现故障复位硬件,不过e1000吃不住流量的情况应该不大,估计是线制作的不合格导致大流量时坏桢严重,或者有电气干扰等。
作者: colddawn    时间: 2005-10-18 12:58
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
对了,ifconfig看一下是不是相应网卡出现很多errors的包
作者: platinum    时间: 2005-10-18 13:11
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
很奇怪呢,RX-ERR RX-DRP RX-OVR,这三项都是 0
是这样的,这台机器上还运行其他服务,CPU 一直比较高,会不会是没有过多的 CPU 来负责处理数据包造成的?

还有,我如果修改源代码,注释掉硬件复位那段代码可不可以?会不会有副作用?
作者: wheel    时间: 2005-10-18 14:38
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
cat /proc/interrupts  看下是否和这相似,注释掉硬件复位那段代码没问题,
          CPU0       CPU1       CPU2       CPU3
0:  347275720  347745526  340396987  340996245    IO-APIC-edge  timer
1:        284        789        878        556    IO-APIC-edge  i8042
8:          0          0          0          1    IO-APIC-edge  rtc
9:          0          0          0          0   IO-APIC-level  acpi
14:          1          0         20         19    IO-APIC-edge  ide0
15:      87104     399199       5819     328406    IO-APIC-edge  libata
169:          0          0          0          0   IO-APIC-level  uhci_hcd
177:          0          0          0          0   IO-APIC-level  uhci_hcd
185:          0          0          0          0   IO-APIC-level  ehci_hcd
209:     186220    5466568     211081    5950435   IO-APIC-level  ioc0
217:   27184131          0          0        157   IO-APIC-level  eth0
225:          0          0   51742411         29   IO-APIC-level  eth1
NMI:          0          0          0          0
LOC: 1376397708 1376397707 1376397706 1376397705
ERR:          0
MIS:          0
作者: platinum    时间: 2005-10-18 14:41
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
           CPU0
  0:    5208209    IO-APIC-edge  timer
  1:          2    IO-APIC-edge  keyboard
  4:         30    IO-APIC-edge  serial
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
15:     108463    IO-APIC-edge  ide1
21:   15700851   IO-APIC-level  eth0
22:   15716884   IO-APIC-level  eth1
NMI:          0
LOC:    5208446
ERR:          0
MIS:          0

这样正常吗?
作者: jackylau    时间: 2005-10-18 15:17
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
不会是负载过大的原因.我们单位做iptv,负荷比你重多了吧,也是e1000
作者: q1208c    时间: 2005-10-18 15:22
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
e1000 是千兆的网卡, 100M应该没事呀?
watchdog 好象是用来检测什么东东的一个计时, 我觉得是不是你的 switch 受不了呀? 因为 switch 如果不行了, 网卡一样会认为网络 down 呀.
作者: platinum    时间: 2005-10-18 15:29
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
[quote]原帖由 "jackylau"]不会是负载过大的原因.我们单位做iptv,负荷比你重多了吧,也是e1000[/quote 发表:

你们的 iptv 服务器的 CPU 负载高吗?
我的服务器 CPU 一直很高
或者网络里面有人捣乱的话,用 dos 工具去弄网关这台机器,一样也会 over。。。。
作者: wheel    时间: 2005-10-18 16:54
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
watchdog是软件狗阿,它是在设备或程序不正常时reboot这设备/程序的,网卡的软狗是监测驱动的情况的,检测到错误为方式tx huang来做的强制reset.软件狗就起动了可见、缓冲区不够大是造成watchdog起动的结果,他在缓冲区满时reboot这设备,你cpu对两网卡的管理明显不对,你的网卡很可能不是厂家的驱动,不过这reboot不象cpu造成的,15:     108463    IO-APIC-edge  ide1, 倒是你IDE占cpu太多了,hdparm -c1 /dev/hda ,再hdparm  -i /dev/hda看下,还有你lsmod把结果列出来把。还有你的驱动是intel下的吗?请更新驱动,应该就ok了。若是linux自带的就快UP到intel的驱动把
作者: jackylau    时间: 2005-10-18 16:59
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "platinum" 发表:

你们的 iptv 服务器的 CPU 负载高吗?
我的服务器 CPU 一直很高
或者网络里面有人捣乱的话,用 dos 工具去弄网关这台机器,一样也会 over。。。。

平常都是50%,都没问题
作者: yuguanglou    时间: 2005-10-18 20:26
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
wheel 说的应该没错
INTEL的E1000芯片比较好
应该是驱动的问题,下载最新的源代码编驱动吧
作者: bingosek    时间: 2005-10-18 20:34
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
[quote]原帖由 "wheel"]watchdog是软件狗阿,它是在设备或程序不正常时reboot这设备/程序的,网卡的软狗是监测驱动的情况的,检测到错误为方式tx huang来做的强制reset.软件狗就起动了可见、缓冲区不够大是造成watchdog起动的结果,他在缓?.........[/quote 发表:

这个倒是值得尝试的方法
另外你可以到交换机相应的段口看看statistic,有没有什么异常
作者: 南非蜘蛛    时间: 2005-10-18 22:16
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
BSD版以前讨论过,linux的原理一样

好的解决方案就是
确认机器瓶颈,什么流量堵死了网卡
升级e1000的驱动到最新
作者: bingosek    时间: 2005-10-18 23:08
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
如果检查流量没有什么异常,更新驱动也没有什么效果的话,试试改变一下驱动参数,参考:
http://www.intel.com/support/network/sb/cs-009209.htm
其中有一段:
This value delays the generation of receive interrupts in units of 1.024 microseconds. Receive interrupt reduction can improve CPU efficiency if properly tuned for specific network traffic. Increasing this value adds extra latency to frame reception and can end up decreasing the throughput of TCP traffic. If the system is reporting dropped receives, this value may be set too high, causing the driver to run out of available receive descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang (stop transmitting) under certain network conditions. If this occurs a NETDEV WATCHDOG message is logged in the system event log. In addition, the controller is automatically reset, restoring the network connection. To eliminate the potential for the hang ensure that RxIntDelay is set to zero.

减少RxIntDelay的值会增加cpu负载
作者: ippen    时间: 2005-10-19 01:34
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
尝试将网卡和交换机都指定为100M 全双工,不要让它们自动协商,以前碰见过类似的问题,指定就好了.
作者: wheel    时间: 2005-10-19 09:56
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
modprobe e1000 RxDescriptors=80,128
减少RxIntDelay的值会增加cpu负载,是值得的,还有这机器的IDE控制器的驱动好象也不是很好,能去下个厂家的驱动会减少不少CPU复载.
再把这文件
/etc/sysconfig/network-scripts/ifcfg-eth<x>;
加MTU = 9000
还有执行下
echo 7 >; /proc/sys/net/ipv4/tcp_retries2
echo 30 >; /proc/sys/net/ipv4/tcp_fin_timeout
echo 1024 >; /proc/sys/dev/rtc/max-user-freq
echo "99" >;/proc/sys/vm/swappiness
echo "using_tcq:32" >; /proc/ide/hda/setting
优化下TCP的连接时间,
作者: 我不是来捣乱的    时间: 2005-10-19 11:26
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
platinum   LZ 有结果了吗?想知道问题的解决方式。
谢谢!!
作者: platinum    时间: 2005-10-19 11:31
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
工作比较忙,还没来得及试,等测试完后我会告诉大家结果
作者: wheel    时间: 2005-10-19 17:40
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
下新驱动了吗?升级内核了吗?
作者: simonlm    时间: 2005-10-21 10:16
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
bcm和intel的网卡在linux下用默认的驱动时都有问题。bcm的使用tg3的驱动,需要换掉。intel的也一样。用默认的驱动时就会造成上述现像。严重时死机。
作者: x718    时间: 2005-10-21 10:20
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
看看是不是有IP衝突阿?
作者: ycfei    时间: 2005-10-23 01:14
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
关注中。。。。。。。。。。
作者: bingosek    时间: 2005-10-23 08:35
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
[quote]原帖由 "simonlm"]bcm和intel的网卡在linux下用默认的驱动时都有问题。bcm的使用tg3的驱动,需要换掉。intel的也一样。用默认的驱动时就会造成上述现像。严重时死机。[/quote 发表:

bcm用tg3驱动我在linux(rhas 2.1)做nas的环境下用过,负载很重,一天到晚拷贝语音数据,没有什么问题,只是有些报错
intel的e1000我也在oracle backup server上用过,负载没有上面重,但数据也不少了,好像也没有什么错误,用的是centos 4.1
作者: platinum    时间: 2005-10-23 09:00
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "bingosek" 发表:

bcm用tg3驱动我在linux(rhas 2.1)做nas的环境下用过,负载很重,一天到晚拷贝语音数据,没有什么问题,只是有些报错

负载重不重要看 pps,而不是 bps
作者: bingosek    时间: 2005-10-23 09:13
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "platinum" 发表:

负载重不重要看 pps,而不是 bps

pps如果是在局域网传输来说是无干紧要的,恐怕没有多少服务器上的文件是小于MTU的吧
作者: platinum    时间: 2005-10-23 09:18
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "bingosek" 发表:

pps如果是在局域网传输来说是无干紧要的,恐怕没有多少服务器上的文件是小于MTU的吧

为什么说 pps 在局域网中无关紧要?
服务器上的文件与 MTU 又有什么关系?
作者: bingosek    时间: 2005-10-23 09:36
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "platinum" 发表:

为什么说 pps 在局域网中无关紧要?
服务器上的文件与 MTU 又有什么关系?

局域网上主要的流量是文件传输,服务器中的文件都比较大,数据传输时每个包的字节数都很大,也就是说文件传输时小包的情况很少,只有在传送很多特别小的文件时才会出现很多小包的情况。交换机在绝大部分情况下不会有繁重的包头分析情况出现。所以衡量局域网的负载使用bps代替pps。可以参考一下交换引擎和背板带宽的参数,一般都是Gbps或Mbps为单位。
WAN的情况就不同,由于受到WAN上线路MTU和windows的限制(特别是比较远的线路,为了保证传输的质量,MTU和windows一般都会设置得比较小),每个packet比较小,路由器会花大量的cpu资源在包头分析上(另外路由器强调路由功能也必然会花费大量资源在包头上),所以,wan上衡量路由器的路由能力是用Mpps或kpps来衡量的
作者: colddawn    时间: 2005-10-23 09:44
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
理论上应该是大包比较多,不过要是碰到个中了毒的狂连你的端口的,就全都是64的syn了。
作者: platinum    时间: 2005-10-23 09:50
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
用于文件传输的话,协议设计的时候就尽量都用大包来转发数据,这样才能减小 pps
可否想过,同样的 bps,当每个 packet 的 size 越小的时候,pps 就越大,当 pps 越大的时候,负载就越高

比如,一个提供下载的 WEB 服务器,与一个很简单的静态页面的 WEB 服务器相比,平均 pps 就差好几倍

我的环境与你的不同,不是用来传输文件的,我的网络中平均包大小只有 300 bytes,平均 pps 是你的 4 倍以上

pps如果是在局域网传输来说是无干紧要的,恐怕没有多少服务器上的文件是小于MTU的吧

这样说是错的
1、局域网传输数据(不是狭义的指“文件传输”)也可以很轻易的使 pps 增高
2、包的大小是看传输数据量的,可以把数据分到 n 个小包中,也可以写入一个大包中,要看编程者的意图
作者: bingosek    时间: 2005-10-23 10:43
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "platinum" 发表:

于文件传输的话,协议设计的时候就尽量都用大包来转发数据,这样才能减小 pps

这个要看你是在lan还是wan上传输,wan上传输看重的是通信的质量,就传统的WAN而言(不含光纤链路),干扰是最大的敌人,是干扰制约了远程通信的速率,而小包是保证通信质量一种有效手段,干扰越大,包越少越好。所以文件在wan上传输不是包越大越好

可否想过,同样的 bps,当每个 packet 的 size 越小的时候,pps 就越大,当 pps 越大的时候,负载就越高

从字面上的理解是这样的,但bps是衡量二层交换能力的参数,pps是衡量三层路由能力的参数,两者是衡量不同的东西,所以比较起来没有什么意义

比如,一个提供下载的 WEB 服务器,与一个很简单的静态页面的 WEB 服务器相比,平均 pps 就差好几倍
我的环境与你的不同,不是用来传输文件的,我的网络中平均包大小只有 300 bytes,平均 pps 是你的 4 倍以上

这个对于局域网来说,有什么区别吗?交换机无需过多地分析web服务器发出数据包三层包头,只在接口处理器地cam表查询后转发

1、局域网传输数据(不是狭义的指“文件传输”)也可以很轻易的使 pps 增高
2、包的大小是看传输数据量的,可以把数据分到 n 个小包中,也可以写入一个大包中,要看编程者的意图

pps对于局域网二层传输来说根本没有影响,因为二层来说只是简单查询一下包头就转发了;对于三层来说,虽然也是用pps衡量路由模块的路由能力,但对于现在性能已经很高的交换机来说,由于无需做太多三层功能,就可以无需经过cpu处理(或同类的包只经过一次cpu处理,看厂家的实现机制)在接口转发,相对于wan来说,已经相当接近于线性转发,所以用pps来看待局域网的三层能力意义已经是不大了

[/quote]
作者: bingosek    时间: 2005-10-23 10:47
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
[quote]原帖由 "colddawn"]理论上应该是大包比较多,不过要是碰到个中了毒的狂连你的端口的,就全都是64的syn了。[/quote 发表:

这个对于局域网来说问题不是很大,这么多的小包对局域网三层来说不会太大问题,死的是出口和服务器,这是因为出口多数死的是NAT,服务器死的是高层处理能力不足。
作者: platinum    时间: 2005-10-23 10:57
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
网卡处理每一个 packet 都要占用中断,而百兆网卡,1400 字节以上大包跑满才不过几千
但如果让 64 字节的小包跑到 50M,pps 也要远比上面说的大的多,负载也要大的多

我坚持我的看法,网卡的负载要看 pps,而不是 bps
作者: bingosek    时间: 2005-10-23 11:19
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
原帖由 "platinum" 发表:
网卡处理每一个 packet 都要占用中断,而百兆网卡,1400 字节以上大包跑满才不过几千
但如果让 64 字节的小包跑到 50M,pps 也要远比上面说的大的多,负载也要大的多

我坚持我的看法,网卡的负载要看 pps,而不?.........

那么我想问一下,那么大量的64字节的小包发生时,网卡所占的cpu资源能有多少呢?
中断多不一定消耗资源,没有什么东西比linux timer的中断多了吧

我个人认为:
pps主要是衡量三层的能力,如果你服务器上开个nat,那么nat制约你包处理能力,那么吞吐量应该由pps来衡量。但这种情况并不是你网卡和局域网制约的,而是你机器对三层包头处理要求变高了(做nat),cpu资源成为瓶颈造成的
作者: platinum    时间: 2005-10-23 11:37
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
要看 P/E 值,不同的网卡 P/E 值不同,对 CPU 的消耗也不同
另外,我说的是网卡对 CPU 造成的负载,而不是服务器中的服务程序对 CPU 造成的负载
作者: duketang    时间: 2005-10-24 22:15
标题: 负载过大时,e1000_watchdog 反复 UP、DOWN 的问题
最后解决没有?我这边也出现这种问题 一模一样
作者: 忽悠2008    时间: 2005-10-31 15:25
楼上说的有道理
作者: LEOD    时间: 2005-10-31 18:24
这个贴子停有意思的,哈哈!
作者: Solaris12    时间: 2005-11-04 14:37
标题: 回复 1楼 platinum 的帖子
intel 的1000兆网卡驱动一般会检测错误并且自动reset芯片,以前我遇到过因为网卡驱动有bug,在小包64字节测试中,网卡反复reset,因此,建议你考虑升级驱动试试.
作者: linuxunix1    时间: 2005-11-04 15:25
我这里的机器也是intel的1000M卡,流量如果大了,机器上的两个网卡都down了.还是dell的啊,系统是rhas4
作者: mirnshi    时间: 2005-11-13 22:49
原帖由 platinum 于 2005-10-23 10:57 发表
网卡处理每一个 packet 都要占用中断,而百兆网卡,1400 字节以上大包跑满才不过几千
但如果让 64 字节的小包跑到 50M,pps 也要远比上面说的大的多,负载也要大的多

我坚持我的看法,网卡的负载要看 pps,而 ...


没错,一般情况下,每收到一个包,都会有一个中断产生。网卡上讨论bps没有意义。进入网卡都变成数据包了。
百兆打满,64小包量不过148K,千兆就是1480K左右,如果在队列满之前,包被处理掉了,就没有什么问题,否则就会丢包。现在CPU的处理速度,处理148K的包,很轻松的。千兆就需要掂量掂量了,包都收下来没有问题,继续处理就会有问题。收包的速度一般都是比发包速度快的。
作者: platinum    时间: 2005-11-13 22:59
可能找到问题的正确解决办法了

在内核中发现这样一个参数
[ *] Intel(R) PRO/1000 Gigabit Ethernet support
[ ]   Use Rx Polling (NAPI)

其具体描述如下
CONFIG_E1000_NAP
    NAPI is a new driver API designed to reduce CPU and interrupt load
when the driver is receiving lots of packets from the card. It is
still somewhat experimental and thus not yet enabled by default.
    If your estimated Rx load is 10kpps or more, or if the card will be
deployed on potentially unfriendly networks (e.g. in a firewall),
then say Y here.
    See Documentation/networking/NAPI_HOWTO.txt for more
information.
    If in doubt, say N.                    

[ 本帖最后由 platinum 于 2005-11-13 23:02 编辑 ]
作者: flea    时间: 2005-11-14 11:38
提示: 作者被禁止或删除 内容自动屏蔽
作者: richwu    时间: 2005-11-28 16:04
标题: 千兆网卡的问题
一些千兆网卡的确会遇到这样的问题,两种方法解决:
用ethtool -K eth0 tso off,可以解决问题, 或者升级系统内核。
作者: wheel    时间: 2005-12-06 16:20
用厂家的驱动一般都可以解决的。
作者: edwardbj4302    时间: 2005-12-06 16:58
换个 2.6 + 的 OS 测试, 2.6 + 内核支持 e1000
作者: platinum    时间: 2005-12-07 15:07
很遗憾的,换成了最新的 e1000 驱动,也仍然出现同样的问题,另外,和 NAPI 好像无关
还有,我没有启用 tso 模式(因为不支持)

不知道该怎么办了。。。
作者: llzqq    时间: 2005-12-07 18:32
不知道该怎么办了。。。


换别的牌子的网卡
作者: 我    时间: 2005-12-08 09:10
可以提供同样的测试环境(硬件)。e1000

02:02.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
(rev 01)

btw: 可能是楼主的小学同学。
作者: platinum    时间: 2005-12-08 11:21
原帖由 于 2005-12-8 09:10 发表
可以提供同样的测试环境(硬件)。e1000

02:02.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
(rev 01)

btw: 可能是楼主的小学同学。

什么意思?没有看懂。。。
还有,可能是我小学同学?
作者: wheel    时间: 2005-12-08 12:41
是用最新的内核和最新的驱动了吗?
作者: 我    时间: 2005-12-08 16:28
看楼主是否需要这样的环境测试,我有你的msn。
需要的话跟你联系。
作者: platinum    时间: 2005-12-08 22:43
原帖由 wheel 于 2005-12-8 12:41 发表
是用最新的内核和最新的驱动了吗?

是,最新的了。。。
作者: platinum    时间: 2005-12-08 22:44
原帖由 于 2005-12-8 16:28 发表
看楼主是否需要这样的环境测试,我有你的msn。
需要的话跟你联系。

sorry,我的 msn 人太多,可能对不上号了,请告知
作者: wj98127    时间: 2005-12-09 10:32
我们这也有一台服务器是这种情况.不过出现的情况少.也不知道为什么会出现.我们像这样的的服务器有几百台.只有这台出出问题.驱动应该都系统自带的..比较这台机器负载大的机器也很多.也没有过 这样的问题.因为跑重要服务一直 没有敢弄.打算换个网线试试.建议楼主也换个线试试.
作者: platinum    时间: 2005-12-09 12:40
原帖由 wj98127 于 2005-12-9 10:32 发表
我们这也有一台服务器是这种情况.不过出现的情况少.也不知道为什么会出现.我们像这样的的服务器有几百台.只有这台出出问题.驱动应该都系统自带的..比较这台机器负载大的机器也很多.也没有过 这样的问题.因为跑重要 ...

谢谢你的 idea,网卡(同型号的)、网线、驱动、主板,这些我都换过了,依然问题依旧
通过查看 e1000 驱动的源代码,发现这个 up、down 的动作是驱动里面实现的
不明白 watch_dog 的原理,不知道驱动里面为什么要 down 掉网卡再 up。。。。
作者: china7530    时间: 2005-12-10 14:32
出现watchdog应该和硬件有关系,我在sun U5上曾碰见过,不过当时我换了台工作站,不包括硬盘。我认为是电源有问题,方便的话换个电源。 china7530@126.com
作者: yuguanglou    时间: 2005-12-11 00:28
按照E1000驱动里面,编译驱动模块的时候记得吧 NAPI 参数加上 这样就支持NAPI 可能是这个问题哟

make CFLAGS_EXTRA=-DE1000_NAPI

还有其他的

ACPI enable may cause Dual Port PRO/1000 Adapters to fail
=========================================================

If ACPI is turned on in the kernel, dual port adapters may not work.
This is due to a limitation in ACPI. Currently, this affects all new
versions of SuSE.
作者: platinum    时间: 2005-12-11 21:26
原帖由 yuguanglou 于 2005-12-11 00:28 发表
按照E1000驱动里面,编译驱动模块的时候记得吧 NAPI 参数加上 这样就支持NAPI 可能是这个问题哟

make CFLAGS_EXTRA=-DE1000_NAPI

还有其他的

ACPI enable may cause Dual Port PRO/1000 Adapters to fa ...

恩,已经加了,依然无效
而且还发现一个奇怪的现象
如果一直不登录服务器操作,一般就不会出现这样的情况
如果登录到服务器上执行一些消耗 CPU 的或者定制防火墙规则的时候,很容易出现这样的现象(瞬间高负载)
作者: jardon_zhao    时间: 2005-12-21 10:47
以前我们单位也有类似的情况,使网线质量不过关,或者switch的端口有问题,换了就好了
作者: llzqq    时间: 2005-12-21 14:03
在交换机上强制降速为100M怎样
作者: zhangjiakouzf    时间: 2005-12-21 18:22
想请叫一些问题。
我现在维护的一台服务器,上面也是intel的e1000,硬件是2个 Intel Corp. 82540EM Gigabit Ethernet Controller,系统rhel3,全部默认驱动,并对网卡进行了桥接(bridge),修改了桥的代码,来处理流过的数据,也出现网卡不断重起的情况,并且不定时出现kernel panic 错误,不明白为什么,因为在测试系统上面一切都正常呀,现在不明原因,不只是不是和楼主所说的现象有关,还有,服务器的load非常的小。
各位大侠,有和建议都说说!

本人QQ-是19948441,欢迎随时联系

[ 本帖最后由 zhangjiakouzf 于 2005-12-21 18:31 编辑 ]
作者: shugor    时间: 2006-01-05 11:33
标题: 我的现象并不是由于红驱动引起的
大家好,看了这么多帖子,我描述一下我的环境: 两台同样的机器做loadbalance  负载基本一样,基中一台出现这种现象,另一台不会出现,一般出现这种报错时基本都会有一个大文件(27.9M)在被下载并且中断,没下载成功。就会出现一些这样的报错,但另一台也会出现大文件下载,并不会出现这种情况。两台机器配置一模一样。网卡除了IP地址不同外其他都一样,由此可见不是驱动的原因,我的OS采用redhat as4,内核为2.6.9的
驱动采用系统自带。
cat /proc/interrupts
           CPU0       CPU1      
  0:  424838397  425364998    IO-APIC-edge  timer
  8:          1          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
14:    3784167    3861062    IO-APIC-edge  ide0
169:          0          0   IO-APIC-level  uhci_hcd
177:          0          0   IO-APIC-level  uhci_hcd
185:          0          0   IO-APIC-level  uhci_hcd
201:  199864558          0   IO-APIC-level  eth0
209:         10     425021   IO-APIC-level  eth1
217:     656062     665751   IO-APIC-level  aic79xx
225:         30          0   IO-APIC-level  aic79xx
NMI:          0          0
LOC:  850274234  850274234
ERR:          0
MIS:          0
我的还没解决,准备换一个网线试试,机房离的原,不太方便

[ 本帖最后由 shugor 于 2006-1-5 11:35 编辑 ]
作者: hongzjx    时间: 2006-01-05 12:08
楼主的网内不会是有人中了木马等病毒了吧
作者: platinum    时间: 2006-01-05 12:39
原帖由 hongzjx 于 2006-1-5 12:08 发表
楼主的网内不会是有人中了木马等病毒了吧

我刚才 tcpdump 试了一下,只要一抓包就 DOWN/UP 了
我的网络吞吐量很大,大概有几十 Mbps,P4 的 CPU,两个 82546 的千兆网卡,平时 CPU 有 90% 左右
平时还好,只要一抓包就 DOWN/UP,但如果换到 10Mbps 的网络环境中就没事了,不知为何

我感觉,好像当网络负载过重、CPU 负载过高,处理不过来的时候,再突然施加一些更大负载的东西就会立刻 DOWN/UP
这种现象仅有 Intel 网卡才出现,因为其他网卡的驱动里面根本就没有写进去 DOWN/UP 这个动作
作者: hongzjx    时间: 2006-01-05 14:41
可否分析一下日志,查出可疑网内IP,再检查拥有该IP的机器。
我个人认为是网内机器中毒后向该服务器狂发数据包造成的!
作者: hongzjx    时间: 2006-01-05 14:42
现在这种病毒比较流行,而且还喜欢针对linux网关!
作者: sdtest12    时间: 2006-01-12 14:44
标题: 问题解决了么?
问题解决了么?
同样的问题,谁有解决方案
作者: attiseve    时间: 2006-01-12 20:10
我的intel82544千兆电口网卡也有类似问题。2.6.9的内核。外接100M交换机。
eth1      Link encap:Ethernet  HWaddr 00:10C:76:78:37  
          inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::210:dcff:fe76:7837/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11113882 errors:911 dropped:1822 overruns:911 frame:0
          TX packets:11708850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3561917028 (3.3 GiB)  TX bytes:2825257092 (2.6 GiB)
          Base address:0xa000 Memory:e4000000-e4020000
===========================================================
dmesg:
===========================================================
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
NETDEV WATCHDOG: eth1: transmit timed out
e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
NETDEV WATCHDOG: eth1: transmit timed out

我的系统负载并不大。可能是千兆驱动有问题吧。
我的千兆光纤网卡就一点问题也没有。
作者: attiseve    时间: 2006-01-12 20:11
再有,我想问问:
Base address:0xa000 Memory:e4000000-e4020000
这个东西是什么意思?只有千兆网卡的才有,百兆没有。
作者: lushy    时间: 2006-03-07 00:04
今天我也碰到了这个问题
作者: ycfei    时间: 2006-06-08 12:20
我也碰到了。同样的问题。
作者: cctcc    时间: 2006-09-01 16:15
遇到同样的问题,
DELL 的 PowerEdge 1800

装的Linux AS4 2.6.9内核。
kernel: Intel(R) PRO/1000 Network Driver - version 5.3.19-k2-NAPI
kernel: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

网卡不定时就会DOWN,只能让机房重启服务器,没有办法!!!
作者: cctcc    时间: 2006-09-01 16:17
Aug 25 16:01:01 localhost crond(pam_unix)[7311]: session opened for user root by (uid=0)
Aug 25 16:01:01 localhost crond(pam_unix)[7311]: session closed for user root
Aug 25 16:02:19 localhost kernel: e1000: eth0: e1000_watchdog: NIC Link is Down
Aug 25 16:05:01 localhost crond(pam_unix)[7321]: session opened for user root by (uid=0)
Aug 25 16:05:01 localhost crond(pam_unix)[7321]: session closed for user root
作者: peixubin    时间: 2006-11-27 08:52
问题处理得怎么样了?
作者: platinum    时间: 2006-11-27 14:16
原因是负载过大时,e1000 驱动里面的 watchdog 无法获取完整的时间片来“喂狗”,导致网卡驱动断开网络
优化服务器之后问题解决
作者: peixubin    时间: 2006-11-27 17:25
能说一下作了哪些优化吗?
作者: 我爱钓鱼    时间: 2006-11-28 17:18
原帖由 platinum 于 2006-11-27 14:16 发表
原因是负载过大时,e1000 驱动里面的 watchdog 无法获取完整的时间片来“喂狗”,导致网卡驱动断开网络
优化服务器之后问题解决


解决了?有没有遇到Down后不能Up的现象?




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2