Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Feb 2011 10:24:16 +0300
From:      Lev Serebryakov <lev@FreeBSD.org>
To:        freebsd-stable@freebsd.org
Cc:        "Vogel, Jack" <jack.vogel@intel.com>
Subject:   em0: Watchdog timeout -- resetting
Message-ID:  <1481093142.20110201102416@serebryakov.spb.ru>

next in thread | raw e-mail | index | archive | help

Hello, Freebsd-stable.

  System is 8-STABLE (8.2-PRERELEASE) with very last e1000 driver
(cvsupped 27 Jan, last commits to e1000 were done 22 Jan).

  NIC is:

em0: <Intel(R) PRO/1000 Network Connection 7.1.9> port 0xdc00-0xdc1f mem 0xfea40000-0xfea5ffff,0xfea79000-0xfea79fff irq 20 at device 25.0 on pci0
em0: No MSI/MSIX using a Legacy IRQ
em0: [FILTER]

em0@pci0:0:25:0:        class=0x020000 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xfea40000, size 131072, enabled
    bar   [14] = type Memory, range 32, base 0xfea79000, size 4096, enabled
    bar   [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled

 It is on-board LAN on ASUS P5R-VM DO MoBo (Q35 chipset).

 I have these tunables in "/etc/loader.conf"

hw.em.rxd=4096
hw.em.txd=4096


 And these non-standard sysctls:

dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096

 Several times a day I got messages like this:

em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 1302, hw tdt = 1265
em0: TX(0) desc avail = 31,Next TX to Clean = 1296

em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 3999, hw tdt = 3959
em0: TX(0) desc avail = 31,Next TX to Clean = 3990

em0: Watchdog timeout -- resetting
em0: Queue(0) tdh = 1431, hw tdt = 1394
em0: TX(0) desc avail = 31,Next TX to Clean = 1425

  And all connections are reset. Before latest commits to driver
this system paniced in swi_clock. Now it works without panics, but
seems, that problem is not fixed completely.

-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481093142.20110201102416>