V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
fuxkcsdn
V2EX  ›  服务器

真·这可能是独此一家的网络无法连接的古怪问题了!

  •  
  •   fuxkcsdn · 2013-06-06 14:53:21 +08:00 · 3524 次点击
    这是一个创建于 4217 天前的主题,其中的信息可能已经有所发展或是发生改变。
    有一台windows服务器,配置如下
    Intel E3-1245 v2
    A-DATA DDR3 1333 8G * 2
    Gigabyte GA-H77M-D3H(集成Atheros 8161 GbE网卡)
    Plextor M5P 128G (System)
    WD RE4 1T HDD * 2 (RAID1)
    OS: Windows Multipoint Server 2012(基于Windows Server 2012)

    遇到的问题
    联网调试该服务器时,局域网正常。关机时,局域网全掉线...
    此时,局域网内2台Debian 6服务器(一台DNS+DHCP服务器,一台网关服务器),全部显示
    eth0 reset adapter
    而DHCP服务器那台还会显示
    =============================================
    May 29 18:53:22 files kernel: [6222073.816020] ------------[ cut here ]------------
    May 29 18:53:22 files kernel: [6222073.816026] WARNING: at /build/buildd-linux-2.6_2.6.32-46-amd64-_ApuPc/linux-2.6-2.6.32/debian/build/source_amd64_none/net/sched/sch_generic.c:261 dev_watchdog+0xe2/0x194()
    May 29 18:53:22 files kernel: [6222073.816029] Hardware name: S3210SH
    May 29 18:53:22 files kernel: [6222073.816030] NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
    May 29 18:53:22 files kernel: [6222073.816031] Modules linked in: nls_utf8 cifs ext3 jbd raid10 loop md_mod snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr evdev psmouse button serio_raw processor i2c_i801 i2c_core i3200_edac edac_core ext4 mbcache jbd2 crc16 sg sr_mod cdrom sd_mod crc_t10dif uhci_hcd ahci e1000 libata floppy scsi_mod thermal thermal_sys ehci_hcd usbcore nls_base e1000e [last unloaded: scsi_wait_scan]
    May 29 18:53:22 files kernel: [6222073.816057] Pid: 0, comm: swapper Tainted: G M 2.6.32-5-amd64 #1
    May 29 18:53:22 files kernel: [6222073.816058] Call Trace:
    May 29 18:53:22 files kernel: [6222073.816060] <IRQ> [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
    May 29 18:53:22 files kernel: [6222073.816064] [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
    May 29 18:53:22 files kernel: [6222073.816067] [<ffffffff8104df38>] ? warn_slowpath_common+0x77/0xa3
    May 29 18:53:22 files kernel: [6222073.816071] [<ffffffff8119c4d8>] ? swiotlb_map_page+0x0/0xc4
    May 29 18:53:22 files kernel: [6222073.816073] [<ffffffff812631f8>] ? dev_watchdog+0x0/0x194
    May 29 18:53:22 files kernel: [6222073.816076] [<ffffffff8104dfc0>] ? warn_slowpath_fmt+0x51/0x59
    May 29 18:53:22 files kernel: [6222073.816082] [<ffffffffa000fe5c>] ? e1000_alloc_rx_buffers+0xce/0x16a [e1000e]
    May 29 18:53:22 files kernel: [6222073.816087] [<ffffffffa00101d1>] ? e1000_clean_rx_irq+0x274/0x2b2 [e1000e]
    May 29 18:53:22 files kernel: [6222073.816090] [<ffffffff81297429>] ? icmp_rcv+0x1f2/0x220
    May 29 18:53:22 files kernel: [6222073.816092] [<ffffffff812631cc>] ? netif_tx_lock+0x3d/0x69
    May 29 18:53:22 files kernel: [6222073.816095] [<ffffffff8124dff8>] ? netdev_drivername+0x3b/0x40
    May 29 18:53:22 files kernel: [6222073.816097] [<ffffffff812632da>] ? dev_watchdog+0xe2/0x194
    May 29 18:53:22 files kernel: [6222073.816100] [<ffffffff810168f3>] ? read_tsc+0xa/0x20
    May 29 18:53:22 files kernel: [6222073.816103] [<ffffffff8106bb5e>] ? timekeeping_get_ns+0xe/0x2e
    May 29 18:53:22 files kernel: [6222073.816107] [<ffffffff8105a6c7>] ? run_timer_softirq+0x1c9/0x268
    May 29 18:53:22 files kernel: [6222073.816109] [<ffffffff81069397>] ? sched_clock_local+0x13/0x74
    May 29 18:53:22 files kernel: [6222073.816113] [<ffffffff81053d73>] ? __do_softirq+0xdd/0x1a6
    May 29 18:53:22 files kernel: [6222073.816115] [<ffffffff8102462a>] ? lapic_next_event+0x18/0x1d
    May 29 18:53:22 files kernel: [6222073.816118] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
    May 29 18:53:22 files kernel: [6222073.816120] [<ffffffff8101322b>] ? do_softirq+0x3f/0x7c
    May 29 18:53:22 files kernel: [6222073.816122] [<ffffffff81053be3>] ? irq_exit+0x36/0x76
    May 29 18:53:22 files kernel: [6222073.816125] [<ffffffff810250f8>] ? smp_apic_timer_interrupt+0x87/0x95
    May 29 18:53:22 files kernel: [6222073.816127] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
    May 29 18:53:22 files kernel: [6222073.816128] <EOI> [<ffffffff810176a4>] ? mwait_idle+0x72/0x7d
    May 29 18:53:22 files kernel: [6222073.816132] [<ffffffff81017654>] ? mwait_idle+0x22/0x7d
    May 29 18:53:22 files kernel: [6222073.816135] [<ffffffff8100fe97>] ? cpu_idle+0xa2/0xda
    May 29 18:53:22 files kernel: [6222073.816138] [<ffffffff8151c140>] ? early_idt_handler+0x0/0x71
    May 29 18:53:22 files kernel: [6222073.816140] [<ffffffff8151ccdd>] ? start_kernel+0x3dc/0x3e8
    May 29 18:53:22 files kernel: [6222073.816142] [<ffffffff8151c3b7>] ? x86_64_start_kernel+0xf9/0x106
    May 29 18:53:22 files kernel: [6222073.816144] ---[ end trace e03e537b8e7b946b ]---
    May 29 18:53:22 files kernel: [6222073.816149] e1000e 0000:00:19.0: eth1: Reset adapter
    May 29 18:53:23 files kernel: [6222074.132891] e1000e 0000:00:19.0: eth1: Reset adapter
    May 29 18:53:25 files kernel: [6222076.690348] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
    May 29 18:53:53 files kernel: [6222104.780274] e1000e 0000:00:19.0: eth1: Detected Hardware Unit Hang:
    May 29 18:53:53 files kernel: [6222104.780275] TDH <c5>
    May 29 18:53:53 files kernel: [6222104.780276] TDT <cb>
    May 29 18:53:53 files kernel: [6222104.780276] next_to_use <cb>
    May 29 18:53:53 files kernel: [6222104.780277] next_to_clean <c5>
    May 29 18:53:53 files kernel: [6222104.780277] buffer_info[next_to_clean]:
    May 29 18:53:53 files kernel: [6222104.780278] time_stamp <15cb64b60>
    May 29 18:53:53 files kernel: [6222104.780279] next_to_watch <c5>
    May 29 18:53:53 files kernel: [6222104.780279] jiffies <15cb64d3b>
    May 29 18:53:53 files kernel: [6222104.780280] next_to_watch.status <0>
    May 29 18:53:53 files kernel: [6222104.780280] MAC Status <80283>
    May 29 18:53:53 files kernel: [6222104.780281] PHY Status <792d>
    May 29 18:53:53 files kernel: [6222104.780282] PHY 1000BASE-T Status <3800>
    May 29 18:53:53 files kernel: [6222104.780282] PHY Extended Status <3000>
    May 29 18:53:53 files kernel: [6222104.780283] PCI Status <10>
    =============================================
    起初看到这日志,想说是网卡坏了,反正有2个集成网卡,换个呗,换完后,也确实正常了...一天...第二天,在调试那台windows服务器差不多后,关机,没半分钟,同事打来电话说上不了网了。
    看了下DHCP服务器,又开始提示eth0 reset adapter了...这...2个网卡同时坏掉的几率太低了吧...开始怀疑局域网有人中毒导致的。

    经过排查,既然是这台已关机的windows服务器导致的...拔掉网线,局域网马上正常。插上网线,等个10+秒,全网断线。测试了几次,确定真的是该服务器导致的。

    但是...关机情况下,插上网线,局域网全部掉线,然后启动该服务器,局域网正常了...这...病毒不可能那么厉害吧...

    把网线接到其他电脑,关机测试、开机测试都没遇到这问题,另一台电脑,主板与该服务器同一型号,只是CPU不一样(i5 2100),同样的测试也是正常的,并没遇到这问题...
    4 条回复    1970-01-01 08:00:00 +08:00
    maoyipeng
        1
    maoyipeng  
       2013-06-17 12:06:58 +08:00 via iPad
    可能是各种屏蔽问题
    sNullp
        2
    sNullp  
       2013-06-17 12:20:24 +08:00
    估计是服务器的电源问题,没有接地什么的。
    GordianZ
        3
    GordianZ  
    MOD
       2013-06-17 12:24:54 +08:00
    同楼上,应该是电源或者网卡坏了.
    Ansen
        4
    Ansen  
       2013-06-17 12:35:57 +08:00
    关机情况下,插上网线,局域网全部掉线,然后启动该服务器,局域网正常了
    试试在服务器断电 情况下插上网线,应该不会掉线吧。。。
    应该是网卡问题。
    没遇到过这种情况,猜的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6027 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 02:06 · PVG 10:06 · LAX 18:06 · JFK 21:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.