From nobody@FreeBSD.org  Fri May 30 10:39:06 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 4C8161065671
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 30 May 2008 10:39:06 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 344798FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 30 May 2008 10:39:06 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m4UAbN7M050985
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 30 May 2008 10:37:23 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m4UAbNWV050984;
	Fri, 30 May 2008 10:37:23 GMT
	(envelope-from nobody)
Message-Id: <200805301037.m4UAbNWV050984@www.freebsd.org>
Date: Fri, 30 May 2008 10:37:23 GMT
From: Mikle Davidkin <skylord@linkline.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         124127
>Category:       kern
>Synopsis:       [msk] watchdog timeout (missed Tx interrupts) -- recovering
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 30 10:40:05 UTC 2008
>Closed-Date:    Wed Mar 03 18:23:02 UTC 2010
>Last-Modified:  Wed Mar 03 18:23:02 UTC 2010
>Originator:     Mikle Davidkin
>Release:        7.0-STABLE
>Organization:
>Environment:
FreeBSD fserver3.linkline.ru 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed May 28 17:52:29 MSD 2008     root@fserver3.linkline.ru:/usr/obj/usr/src/sys/skykernel  amd64

>Description:
After few minutes of FTP transfer (speed is about 3Mb/s), msk gets down - "ifconfig down/up" and cable unplugging/plugging don't help to recover it. There are continuously showing messages on console:

May 30 14:16:56 fserver3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering
May 30 14:17:06 fserver3 kernel: msk0: watchdog timeout
May 30 14:17:06 fserver3 kernel: msk0: link state changed to DOWN
May 30 14:17:10 fserver3 kernel: msk0: link state changed to UP
May 30 14:17:50 fserver3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering
May 30 14:18:27 fserver3 last message repeated 3 times
May 30 14:18:51 fserver3 last message repeated 2 times
May 30 14:19:00 fserver3 kernel: msk0: link state changed to DOWN
May 30 14:19:04 fserver3 kernel: msk0: link state changed to UP
May 30 14:19:13 fserver3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering
May 30 14:19:20 fserver3 kernel: msk0: link state changed to DOWN
May 30 14:19:25 fserver3 kernel: msk0: link state changed to UP
May 30 14:19:45 fserver3 kernel: msk0: watchdog timeout (missed Tx interrupts) -- recovering
May 30 14:20:33 fserver3 kernel: msk0: link state changed to DOWN


Tried on fresh STABLE (28 may), but the same behaviour is on 7.0-release and i386 kernel.
My system is ECS A740GM-M motherboard with Athlon 64 X2 4800+ (I've tried on other systems - there was the same symptoms...) and PCI-E D-Link DGE-560T network card. Here is hardware info:

dmesg message:
================
mskc0: <D-Link 560T Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci2
mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfe9fc000
mskc0: MSI count : 2
mskc0: attempting to allocate 2 MSI vectors (2 supported)
msi: routing MSI IRQ 256 to vector 50
msi: routing MSI IRQ 257 to vector 51
mskc0: using IRQs 256-257 for MSI
mskc0: RAM buffer size : 48KB
mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff)
mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff)
msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x01> on mskc0
msk0: bpf attached
msk0: Ethernet address: 00:00:5a:9e:b3:ea
miibus0: <MII bus> on msk0
e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto
mskc0: [MPSAFE]
mskc0: [FILTER]
================


pciconf -lv:
================
mskc0@pci0:2:0:0:       class=0x020000 card=0x4b001186 chip=0x4b001186 rev=0x11 hdr=0x00
    vendor     = 'D-Link System Inc'
    device     = 'DGE-560T PCIe Gigabit Ethernet Adapter'
    class      = network
    subclass   = ethernet
================


I'll be glad to assist and test any patches related to my problem... Thanks in advance!
>How-To-Repeat:
Boot with D-Link DGE-560T and try to download something...
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: remko 
Responsible-Changed-When: Fri May 30 14:35:51 UTC 2008 
Responsible-Changed-Why:  
Reassign to networking team. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124127 

From: sam <samflanker@gmail.com>
To: bug-followup@FreeBSD.org,  skylord@linkline.ru
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
Date: Thu, 31 Jul 2008 16:00:19 +0400

 -----------------------------------------------
 Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx 
 interrupts) -- recovering
 Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx 
 interrupts) -- recovering
 -----------------------------------------------
 
 -----------------------------------------------
 Jul  29 23:18:28 moon3 kernel: mskc0: <Marvell Yukon 88E8050 Gigabit 
 Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device 
 0.0 on pci2
 Jul  29 23:18:28 moon3 kernel: msk0: <Marvell Technology Group Ltd. 
 Yukon EC Id 0xb6 Rev 0x02> on mskc0
 
 Jul  29 23:18:28 moon3 kernel: miibus0: <MII bus> on msk0
 -----------------------------------------------
 
 -----------------------------------------------
 FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 
 15:00:14 MSD 2008     root@moon3:/usr/src/sys/i386/compile/MOON3  i386
 -----------------------------------------------
 
 I confirm this problem.
 
 /Vladimir Ermakov
 

From: "Alexey Pelykh" <alexey.pelykh@gmail.com>
To: bug-followup@FreeBSD.org, skylord@linkline.ru
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Mon, 25 Aug 2008 15:01:09 +0300

 Also, DLink 560T. Same problem. NIC freezes on workloads at > 3.0Mbytes/sec
 dmesg | grep "msk"
 mskc0: <D-Link 560T Gigabit Ethernet> port 0xd800-0xd8ff mem
 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 
 miibus0: <MII bus> on msk0
 mskc0: [ITHREAD]
 mskc0: <D-Link 560T Gigabit Ethernet> port 0xd800-0xd8ff mem
 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 
 miibus0: <MII bus> on msk0
 mskc0: [ITHREAD]
 mskc0: <D-Link 560T Gigabit Ethernet> port 0xd800-0xd8ff mem
 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 
 miibus0: <MII bus> on msk0
 mskc0: [FILTER]
 msk0: link state changed to UP
 
 pciconf -lv
 mskc0@pci0:1:0:0:       class=0x020000 card=0x4b001186 chip=0x4b001186
 rev=0x13 hdr=0x00
     vendor     = 'D-Link System Inc'
     device     = 'DGE-560T PCIe Gigabit Ethernet Adapter'
     class      = network
     subclass   = ethernet
 
 uname -a:
 FreeBSD taburetka 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #17: Sun Aug
 10 01:10:09 EEST 2008
 root@taburetka:/usr/obj/usr/src/sys/taburetka_7_0.2008-25-07  i386

From: Duckhawk <archi.kun@gmail.com>
To: bug-followup@FreeBSD.org, skylord@linkline.ru
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Date: Sun, 22 Feb 2009 12:26:51 +0500

 --001636c5a26744f2de04637ccfc6
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 also, same problem. D-Link DGE-560T
 
 %uname -a
 FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009
 duckhawk@:/usr/obj/usr/src/sys/GENERIC  i386
 
 %dmesg | grep "msk"
 mskc0: <D-Link 560T Gigabit Ethernet> port 0x7000-0x70ff mem
 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 msk0: Ethernet address: 00:1b:11:79:53:eb
 miibus0: <MII bus> on msk0
 mskc0: [FILTER]
 
 %pciconf -lv
 mskc0@pci0:1:0:0:       class=0x020000 card=0x4b001186 chip=0x4b001186
 rev=0x13 hdr=0x00
     vendor     = 'D-Link System Inc'
     device     = 'DGE-560T PCIe Gigabit Ethernet Adapter'
     class      = network
     subclass   = ethernet
 
 --001636c5a26744f2de04637ccfc6
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 also, same problem. D-Link DGE-560T<br><br>%uname -a<br>FreeBSD&nbsp; 7.1-S=
 TABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009&nbsp;&nbsp;&nbsp=
 ;&nbsp; duckhawk@:/usr/obj/usr/src/sys/GENERIC&nbsp; i386<br><br>%dmesg | g=
 rep &quot;msk&quot;<br>mskc0: &lt;D-Link 560T Gigabit Ethernet&gt; port 0x7=
 000-0x70ff mem 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1<br>
 msk0: &lt;Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02&gt; on ms=
 kc0<br>msk0: Ethernet address: 00:1b:11:79:53:eb<br>miibus0: &lt;MII bus&gt=
 ; on msk0<br>mskc0: [FILTER]<br><br>%pciconf -lv<br>mskc0@pci0:1:0:0:&nbsp;=
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class=3D0x020000 card=3D0x4b001186 chip=3D0x=
 4b001186 rev=3D0x13 hdr=3D0x00<br>
 &nbsp;&nbsp;&nbsp; vendor&nbsp;&nbsp;&nbsp;&nbsp; =3D &#39;D-Link System In=
 c&#39;<br>&nbsp;&nbsp;&nbsp; device&nbsp;&nbsp;&nbsp;&nbsp; =3D &#39;DGE-56=
 0T PCIe Gigabit Ethernet Adapter&#39;<br>&nbsp;&nbsp;&nbsp; class&nbsp;&nbs=
 p;&nbsp;&nbsp;&nbsp; =3D network<br>&nbsp;&nbsp;&nbsp; subclass&nbsp;&nbsp;=
  =3D ethernet<br>
 
 --001636c5a26744f2de04637ccfc6--

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Duckhawk <archi.kun@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Fri, 19 Jun 2009 09:43:05 +0900

 --47eKBCiAZYFK5l32
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote:
 > The following reply was made to PR kern/124127; it has been noted by GNATS.
 > 
 > From: Duckhawk <archi.kun@gmail.com>
 > To: bug-followup@FreeBSD.org, skylord@linkline.ru
 > Cc:  
 > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
 > 	recovering
 > Date: Sun, 22 Feb 2009 12:26:51 +0500
 > 
 >  --001636c5a26744f2de04637ccfc6
 >  Content-Type: text/plain; charset=ISO-8859-1
 >  Content-Transfer-Encoding: 7bit
 >  
 >  also, same problem. D-Link DGE-560T
 >  
 >  %uname -a
 >  FreeBSD  7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009
 >  duckhawk@:/usr/obj/usr/src/sys/GENERIC  i386
 >  
 >  %dmesg | grep "msk"
 >  mskc0: <D-Link 560T Gigabit Ethernet> port 0x7000-0x70ff mem
 >  0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1
 >  msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 >  msk0: Ethernet address: 00:1b:11:79:53:eb
 >  miibus0: <MII bus> on msk0
 >  mskc0: [FILTER]
 >  
 >  %pciconf -lv
 >  mskc0@pci0:1:0:0:       class=0x020000 card=0x4b001186 chip=0x4b001186
 >  rev=0x13 hdr=0x00
 >      vendor     = 'D-Link System Inc'
 >      device     = 'DGE-560T PCIe Gigabit Ethernet Adapter'
 >      class      = network
 >      subclass   = ethernet
 
 Please try the following patch.
 
 --47eKBCiAZYFK5l32
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="msk.EC.patch"
 
 Index: sys/dev/msk/if_msk.c
 ===================================================================
 --- sys/dev/msk/if_msk.c	(revision 194467)
 +++ sys/dev/msk/if_msk.c	(working copy)
 @@ -1387,27 +1387,26 @@
  	CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
  	/* Set the status list last index. */
  	CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
 -	if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
 -	    sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
 -		/* WA for dev. #4.3 */
 -		CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
 -		/* WA for dev. #4.18 */
 -		CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
 -		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
 -	} else {
 -		CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
 -		CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 -		if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
 -		    sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
 -			CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
 -		else
 -			CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
 -		CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
 -	}
  	/*
 -	 * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
 +	 * XXX
 +	 * Interrupt moderation and coalescing frames should be
 +	 * controllable with sysctl variables or loader tunables
 +	 * but the relationship between status updates and
 +	 * interrupt moderation are not clear to me. Some hardware
 +	 * revisions seem to very sensitive to these parameters
 +	 * and could be resulted in poor performance as well as 
 +	 * non-working situation if improper values were chosen.
  	 */
 +	CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
 +	CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 +	if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
 +	    sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
 +		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
 +	else
 +		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
  	CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
 +	CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
 +	CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
  
  	/* Enable status unit. */
  	CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
 
 --47eKBCiAZYFK5l32--

From: Pyun YongHyeon <pyunyh@gmail.com>
To: sam <samflanker@gmail.com>
Cc: yongari@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Fri, 19 Jun 2009 09:40:46 +0900

 --pQhZXvAqiZgbeUkD
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote:
 > -----------------------------------------------
 > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx 
 > interrupts) -- recovering
 > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx 
 > interrupts) -- recovering
 > -----------------------------------------------
 > 
 > -----------------------------------------------
 > Jul  29 23:18:28 moon3 kernel: mskc0: <Marvell Yukon 88E8050 Gigabit 
 > Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device 
 > 0.0 on pci2
 > Jul  29 23:18:28 moon3 kernel: msk0: <Marvell Technology Group Ltd. 
 > Yukon EC Id 0xb6 Rev 0x02> on mskc0
 > 
 > Jul  29 23:18:28 moon3 kernel: miibus0: <MII bus> on msk0
 > -----------------------------------------------
 > 
 > -----------------------------------------------
 > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27 
 > 15:00:14 MSD 2008     root@moon3:/usr/src/sys/i386/compile/MOON3  i386
 > -----------------------------------------------
 > 
 > I confirm this problem.
 > 
 > /Vladimir Ermakov
 > 
 > 
 
 Would you try attached patch and let me know hot it goes?
 
 --pQhZXvAqiZgbeUkD
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="msk.EC.patch"
 
 Index: sys/dev/msk/if_msk.c
 ===================================================================
 --- sys/dev/msk/if_msk.c	(revision 194467)
 +++ sys/dev/msk/if_msk.c	(working copy)
 @@ -1387,27 +1387,26 @@
  	CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
  	/* Set the status list last index. */
  	CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
 -	if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
 -	    sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
 -		/* WA for dev. #4.3 */
 -		CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
 -		/* WA for dev. #4.18 */
 -		CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
 -		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
 -	} else {
 -		CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
 -		CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 -		if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
 -		    sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
 -			CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
 -		else
 -			CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
 -		CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
 -	}
  	/*
 -	 * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
 +	 * XXX
 +	 * Interrupt moderation and coalescing frames should be
 +	 * controllable with sysctl variables or loader tunables
 +	 * but the relationship between status updates and
 +	 * interrupt moderation are not clear to me. Some hardware
 +	 * revisions seem to very sensitive to these parameters
 +	 * and could be resulted in poor performance as well as 
 +	 * non-working situation if improper values were chosen.
  	 */
 +	CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
 +	CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 +	if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
 +	    sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
 +		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
 +	else
 +		CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
  	CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
 +	CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
 +	CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
  
  	/* Enable status unit. */
  	CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
 
 --pQhZXvAqiZgbeUkD--

From: "Dmitry A.Deineka" <ddeineka@gmail.com>
To: bug-followup@freebsd.org
Cc: Pyun YongHyeon <pyunyh@gmail.com>
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
Date: Wed, 01 Jul 2009 15:59:22 +0300

 Hi,
 
 have same problem, motherboard Asus P5K-VM with marvell yukon onboard:
 mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem 
 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on 
 mskc0
 msk0: Ethernet address: 00:1e:8c:5e:f8:92
 
 
 Problem confirmed with FreeBSD 7.x, now installed 8.0-CURRENT-200906 
 with the same problem (and the same msk driver, as I see in source).
 
 Patch from Pyun YongHyeon in this PR applied, but it not fix problem. 
 Downloading large file by ftp from another server causes following:
 
 Jul  1 15:43:58 msktest kernel: msk0: watchdog timeout
 Jul  1 15:43:58 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:44:00 msktest kernel: msk0: link state changed to UP
 Jul  1 15:44:38 msktest kernel: msk0: watchdog timeout
 Jul  1 15:44:38 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:44:40 msktest kernel: msk0: link state changed to UP
 Jul  1 15:45:03 msktest kernel: msk0: watchdog timeout
 Jul  1 15:45:03 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:45:05 msktest kernel: msk0: link state changed to UP
 Jul  1 15:45:28 msktest kernel: msk0: watchdog timeout
 Jul  1 15:45:28 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:45:30 msktest kernel: msk0: link state changed to UP
 Jul  1 15:46:07 msktest kernel: msk0: watchdog timeout
 Jul  1 15:46:07 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:46:09 msktest kernel: msk0: link state changed to UP
 Jul  1 15:46:24 msktest kernel: msk0: watchdog timeout
 Jul  1 15:46:24 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:46:26 msktest kernel: msk0: link state changed to UP
 Jul  1 15:47:07 msktest kernel: msk0: watchdog timeout
 Jul  1 15:47:07 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:47:09 msktest kernel: msk0: link state changed to UP
 Jul  1 15:48:33 msktest kernel: msk0: watchdog timeout
 Jul  1 15:48:33 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:48:35 msktest kernel: msk0: link state changed to UP
 
 
 Hope this helps.
 
 With best regards,
    Dmitry

From: Andrew Bliznak <andriko.b@gmail.com>
To: bug-followup@FreeBSD.org, skylord@linkline.ru
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Date: Mon, 6 Jul 2009 13:20:12 +0300

 Same problem with Asus P5BV-C/4L in production.
 
 I found desktop with Asus P5LD2 MB and use it for experimental setup.
 Three host is same gig switch, msk0 configured with vlans and
 ipforwarding
 For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 hosts on different vlans.
 7.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 ifconfig -vlanhwtag  to run without input errors,
 after 30 minutes card locked,  down/up interface not help, need to reboot.
 Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 little lover forwarding rate.
 After, boot again freebsd, run test. Hmm, test run ok...
 Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend...

From: Pyun YongHyeon <pyunyh@gmail.com>
To: "Dmitry A.Deineka" <ddeineka@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 8 Jul 2009 13:58:02 +0900

 On Wed, Jul 01, 2009 at 03:59:22PM +0300, Dmitry A.Deineka wrote:
 > Hi,
 > 
 > have same problem, motherboard Asus P5K-VM with marvell yukon onboard:
 > mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem 
 > 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1
 > msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on 
 > mskc0
 > msk0: Ethernet address: 00:1e:8c:5e:f8:92
 > 
 > 
 > Problem confirmed with FreeBSD 7.x, now installed 8.0-CURRENT-200906 
 > with the same problem (and the same msk driver, as I see in source).
 > 
 > Patch from Pyun YongHyeon in this PR applied, but it not fix problem. 
 > Downloading large file by ftp from another server causes following:
 > 
 > Jul  1 15:43:58 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:43:58 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:44:00 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:44:38 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:44:38 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:44:40 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:45:03 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:45:03 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:45:05 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:45:28 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:45:28 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:45:30 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:46:07 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:46:07 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:46:09 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:46:24 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:46:24 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:46:26 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:47:07 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:47:07 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:47:09 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:48:33 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:48:33 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:48:35 msktest kernel: msk0: link state changed to UP
 > 
 > 
 > Hope this helps.
 > 
 
 I guess you're suffering from difference issues. Support for Yukon
 Ultra was known to be unstable. I had tried hard to address the
 issue but lack of the hardware was major bottle-neck.
 
 Original submitter' hardware is not Yukon Ultra and looks like some
 timing issues related with interrupt level timer, Tx threshold. It
 would be great if original submitter can test previous patch.
 
 > With best regards,
 >   Dmitry

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Andrew Bliznak <andriko.b@gmail.com>
Cc: bug-followup@FreeBSD.org, skylord@linkline.ru
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 8 Jul 2009 14:03:58 +0900

 On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote:
 > The following reply was made to PR kern/124127; it has been noted by GNATS.
 > 
 > From: Andrew Bliznak <andriko.b@gmail.com>
 > To: bug-followup@FreeBSD.org, skylord@linkline.ru
 > Cc:  
 > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
 > 	recovering
 > Date: Mon, 6 Jul 2009 13:20:12 +0300
 > 
 >  Same problem with Asus P5BV-C/4L in production.
 >  
 
 Show me dmesg output (msk(4) and e1000phy(4) part) to see what
 controller you have. Due to the diverse Yukon controllers and their
 silicon bugs for each revision it's really hard to tell you're
 seeing the same issue of this PR. Please show me more information.
 
 >  I found desktop with Asus P5LD2 MB and use it for experimental setup.
 >  Three host is same gig switch, msk0 configured with vlans and
 >  ipforwarding
 >  For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 >  hosts on different vlans.
 >  7.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 >  ifconfig -vlanhwtag  to run without input errors,
 >  after 30 minutes card locked,  down/up interface not help, need to reboot.
 
 Need to know which controller you have.
 
 >  Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 >  little lover forwarding rate.
 >  After, boot again freebsd, run test. Hmm, test run ok...
 >  Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend...
 
 This confuse me. So you don't see issues any more?

From: Andrew Bliznak <andriko.b@gmail.com>
To: pyunyh@gmail.com
Cc: bug-followup@freebsd.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Date: Thu, 9 Jul 2009 14:48:12 +0300

 2009/7/8 Pyun YongHyeon <pyunyh@gmail.com>:
 > On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote:
 >> The following reply was made to PR kern/124127; it has been noted by GNA=
 TS.
 >>
 >> From: Andrew Bliznak <andriko.b@gmail.com>
 >> To: bug-followup@FreeBSD.org, skylord@linkline.ru
 >> Cc:
 >> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) =
 --
 >> =A0 =A0 =A0 recovering
 >> Date: Mon, 6 Jul 2009 13:20:12 +0300
 >>
 >> =A0Same problem with Asus P5BV-C/4L in production.
 >>
 >
 > Show me dmesg output (msk(4) and e1000phy(4) part) to see what
 > controller you have. Due to the diverse Yukon controllers and their
 > silicon bugs for each revision it's really hard to tell you're
 > seeing the same issue of this PR. Please show me more information.
 >
 
 mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem
 0xfbefc000-0xfbefffff irq 18 at device 0.0 on pci5
 msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on ms=
 kc0
 msk0: Ethernet address: 00:22:15:ef:02:06
 miibus0: <MII bus> on msk0
 e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
 e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX,=
  auto
 mskc0: [FILTER]
 
 Huh, yes, it's different problem, which bug number for this?
 
 >> =A0I found desktop with Asus P5LD2 MB and use it for experimental setup.
 >> =A0Three host is same gig switch, msk0 configured with vlans and
 >> =A0ipforwarding
 >> =A0For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 >> =A0hosts on different vlans.
 >> =A07.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 >> =A0ifconfig -vlanhwtag =A0to run without input errors,
 >> =A0after 30 minutes card locked, =A0down/up interface not help, need to =
 reboot.
 >
 > Need to know which controller you have.
 >
 
 mskc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xc800-0xc8ff mem
 0xcbffc000-0xcbffffff irq 19 at device 0.0 on pci2
 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xcbffc000
 mskc0: MSI count : 2
 mskc0: attempting to allocate 2 MSI vectors (2 supported)
 mskc0: using IRQs 256-257 for MSI
 mskc0: RAM buffer size : 48KB
 mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff)
 mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff)
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 msk0: bpf attached
 msk0: Ethernet address: 00:17:31:bd:1a:64
 miibus0: <MII bus> on msk0
 mskc0: [MPSAFE]
 mskc0: [FILTER]
 mskc0: Uncorrectable PCI Express error
 msk0: link state changed to UP
 
 
 >> =A0Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 >> =A0little lover forwarding rate.
 >> =A0After, boot again freebsd, run test. Hmm, test run ok...
 >> =A0Reboot with stock 7.2-REL GENERIC kernel. Box running well over weeke=
 nd...
 >
 > This confuse me. So you don't see issues any more?
 >
 
 Yes.
 
 I instaled 8.0-BETA1-amd64 on this box, rerun tests, all ok.
 Also try clear CMOS from BIOS - no change. Next, I reflash BIOS from disket=
 te
 and problem returns.
 Build new kernel with patch-2.diff, now test run ok.
 Rebuild kernel without patch, and this time msk works.
 Look like very strange HW, but patch obviously helped.

From: Mark Atkinson <atkin901@yahoo.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Mon, 19 Oct 2009 08:03:58 -0700 (PDT)

 I am also see this problem on the following, however this on -current
 built on Aug 25, 2009, so I'm updating to the latest to retest.
 
 watchdog timeout (missed Tx interrupts) -- recovering
 
 e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus0
 e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
 
 mskc0@pci0:2:0:0:       class=0x020000 card=0x81421043 chip=0x436211ab rev=0x15 hdr=0x00
     vendor     = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
     device     = 'Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller (88E8053)'
     class      = network
     subclass   = ethernet
 
 
 This is an ASUS P5GD2 Deluxe.
 
 Mark Atkinson
 atkin901@yahoo.com
 (!wired)?(coffee++):(wired);
 
 
 
       

From: Mark Atkinson <atkin901@yahoo.com>
To: freebsd prs <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Sun, 25 Oct 2009 12:55:38 -0700 (PDT)

 After a week on a Oct 19th 2009 built kernel, I got
 hit with the watchdog again, so I applied the patch.
 
 The msk interface was non functional (came up but was
 unable to pass traffic) after applying the
 patch, so I booted back to the unpatched kernel.
 
 
  Mark Atkinson
 atkin901@yahoo.com
 (!wired)?(coffee++):(wired);
 
 
 
       

From: Mark Atkinson <atkin901@yahoo.com>
To: freebsd prs <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 28 Oct 2009 17:03:52 -0700 (PDT)

 =0A=0AOn the unpatched -current kernel, built=0A=0AFreeBSD hellfire.filamen=
 t.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon Oct 19 09:12:03 PDT 2009 =0A=
 =0AI recieved the following panic today related to this:=0A=0AFatal trap 12=
 : page fault while in kernel mode=0Acpuid =3D 0; apic id =3D 00=0Afault vir=
 tual address   =3D 0xdeadc10a=0Afault code              =3D supervisor read=
 , page not present=0Ainstruction pointer     =3D 0x20:0xc0987410=0Astack po=
 inter           =3D 0x28:0xd533dac0=0Aframe pointer           =3D 0x28:0xd5=
 33dae8=0Acode segment            =3D base 0x0, limit 0xfffff, type 0x1b=0A =
                        =3D DPL 0, pres 1, def32 1, gran 1=0Aprocessor eflag=
 s        =3D interrupt enabled, resume, IOPL =3D 0=0Acurrent process       =
   =3D 0 (mskc0 taskq)=0APhysical memory: 495 MB=0ADumping 132 MB: 117 101 8=
 5 69 53 37 21 5=0A=0AReading symbols from /boot/kernel/linux.ko...Reading s=
 ymbols from /boot/kernel/linux.ko.symbols...done.=0Adone.=0ALoaded symbols =
 for /boot/kernel/linux.ko=0A#0  0xc08907a9 in doadump () at /usr/src/sys/ke=
 rn/kern_shutdown.c:254=0A254     }=0A(kgdb) bt=0A#0  0xc08907a9 in doadump =
 () at /usr/src/sys/kern/kern_shutdown.c:254=0A#1  0xc04f7e37 in db_fncall (=
 dummy1=3D-1067299898, dummy2=3D0, dummy3=3D-718022488,=0A    dummy4=3D0xd53=
 3d898 "\200%t=C3") at /usr/src/sys/ddb/db_command.c:548=0A#2  0xc04f8214 in=
  db_command (last_cmdp=3D0xc0da059c, cmd_table=3D0x0, dopager=3D1)=0A    at=
  /usr/src/sys/ddb/db_command.c:445=0A#3  0xc04f8352 in db_command_loop () a=
 t /usr/src/sys/ddb/db_command.c:498=0A#4  0xc04fa05e in db_trap (type=3D12,=
  code=3D0) at /usr/src/sys/ddb/db_main.c:229=0A#5  0xc08bf2d2 in kdb_reente=
 r () at /usr/src/sys/kern/subr_kdb.c:398=0A#6  0xc0ba9b62 in trap_fatal (fr=
 ame=3D0x1, eva=3D3735929098)=0A    at /usr/src/sys/i386/i386/trap.c:938=0A#=
 7  0xc0baa483 in trap (frame=3D0xd533da80) at /usr/src/sys/i386/i386/trap.c=
 :339=0A#8  0xc0b8e4ab in Xlcall_syscall () at /usr/src/sys/i386/i386/except=
 ion.s:241=0A#9  0xc0987410 in in_lltable_lookup (llt=3D0xc39e1000, flags=3D=
 Variable "flags" is not available.=0A)=0A    at /usr/src/sys/netinet/in.c:1=
 380=0A#10 0xc0982470 in arpintr (m=3D0xc3baeb00) at /usr/src/sys/netinet/if=
 _ether.c:642=0A#11 0xc094227a in netisr_dispatch_src (proto=3D7, source=3D0=
 , m=3D0xc0de)=0A    at /usr/src/sys/net/netisr.c:932=0A#12 0xc09424dd in ne=
 tisr_unregister (nhp=3D0xc0de)=0A    at /usr/src/sys/net/netisr.c:583=0A#13=
  0xc093ac69 in ether_demux (ifp=3D0x0, m=3D0xc3baeb00)=0A    at /usr/src/sy=
 s/net/if_ethersubr.c:911=0A#14 0xc093b1ce in ether_output (ifp=3D0xc36ad400=
 , m=3D0xc3baeb00, dst=3D0xc0c55c27,=0A    ro=3D0x301010a) at /usr/src/sys/n=
 et/if_ethersubr.c:181=0A---Type <return> to continue, or q <return> to quit=
 ---=0A#15 0xc070b032 in msk_handle_events (sc=3D0xc3686c00)=0A    at /usr/s=
 rc/sys/dev/msk/if_msk.c:3048=0A#16 0xc070b828 in msk_int_task (arg=3D0xc368=
 6c00, pending=3D1)=0A    at /usr/src/sys/dev/msk/if_msk.c:3625=0A#17 0xc08c=
 ac8c in taskqueue_run (queue=3D0xc36bf380)=0A    at /usr/src/sys/kern/subr_=
 taskqueue.c:72=0A#18 0xc08cadcc in taskqueue_thread_loop (arg=3D0xc3686c8c)=
 =0A    at /usr/src/sys/kern/subr_taskqueue.c:90=0A#19 0xc0869271 in fork_ex=
 it (callout=3D0xc08cad67 <taskqueue_thread_loop+64>,=0A    arg=3D0xc3686c8c=
 , frame=3D0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854=0A#20 0xc0b8e520=
  in Xatpic_intr0 () at atpic_vector.s:62=0A#21 0x00000000 in ?? ()=0A=0A=0A=
       

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Mark Atkinson <atkin901@yahoo.com>
Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Thu, 29 Oct 2009 09:49:09 -0700

 On Thu, Oct 29, 2009 at 06:52:34AM -0700, Mark Atkinson wrote:
 > Wow, not sure what to blame for that charset nightmare.  Apologies.
 > Here's the original message:
 > 
 > On the unpatched -current kernel, built
 > 
 > FreeBSD hellfire.filament.org 9.0-CURRENT FreeBSD 9.0-CURRENT #14: Mon
 > Oct 19 09:12:03 PDT 2009
 > 
 > I recieved the following panic today related to this:
 > 
 > Fatal trap 12: page fault while in kernel mode
 > cpuid = 0; apic id = 00
 > fault virtual address  = 0xdeadc10a
 > fault code              = supervisor read, page not present
 > instruction pointer    = 0x20:0xc0987410
 > stack pointer          = 0x28:0xd533dac0
 > frame pointer          = 0x28:0xd533dae8
 > code segment            = base 0x0, limit 0xfffff, type 0x1b
 >                         = DPL 0, pres 1, def32 1, gran 1
 > processor eflags        = interrupt enabled, resume, IOPL = 0
 > current process        = 0 (mskc0 taskq)
 > Physical memory: 495 MB
 > Dumping 132 MB: 117 101 85 69 53 37 21 5
 > 
 > Reading symbols from /boot/kernel/linux.ko...Reading symbols from
 > /boot/kernel/linux.ko.symbols...done.
 > done.
 > Loaded symbols for /boot/kernel/linux.ko
 > #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
 > 254    }
 > (kgdb) bt
 > #0  0xc08907a9 in doadump () at /usr/src/sys/kern/kern_shutdown.c:254
 > #1  0xc04f7e37 in db_fncall (dummy1=-1067299898, dummy2=0,
 > dummy3=-718022488,
 >     dummy4=0xd533d898 "\200%t?") at /usr/src/sys/ddb/db_command.c:548
 > #2  0xc04f8214 in db_command (last_cmdp=0xc0da059c, cmd_table=0x0,
 > dopager=1)
 >     at /usr/src/sys/ddb/db_command.c:445
 > #3  0xc04f8352 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
 > #4  0xc04fa05e in db_trap (type=12, code=0) at
 > /usr/src/sys/ddb/db_main.c:229
 > #5  0xc08bf2d2 in kdb_reenter () at /usr/src/sys/kern/subr_kdb.c:398
 > #6  0xc0ba9b62 in trap_fatal (frame=0x1, eva=3735929098)
 >     at /usr/src/sys/i386/i386/trap.c:938
 > #7  0xc0baa483 in trap (frame=0xd533da80) at
 > /usr/src/sys/i386/i386/trap.c:339
 > #8  0xc0b8e4ab in Xlcall_syscall () at
 > /usr/src/sys/i386/i386/exception.s:241
 > #9  0xc0987410 in in_lltable_lookup (llt=0xc39e1000, flags=Variable
 > "flags" is not available.
 > )
 >     at /usr/src/sys/netinet/in.c:1380
 > #10 0xc0982470 in arpintr (m=0xc3baeb00) at
 > /usr/src/sys/netinet/if_ether.c:642
 > #11 0xc094227a in netisr_dispatch_src (proto=7, source=0, m=0xc0de)
 >     at /usr/src/sys/net/netisr.c:932
 > #12 0xc09424dd in netisr_unregister (nhp=0xc0de)
 >     at /usr/src/sys/net/netisr.c:583
 > #13 0xc093ac69 in ether_demux (ifp=0x0, m=0xc3baeb00)
 >     at /usr/src/sys/net/if_ethersubr.c:911
 > #14 0xc093b1ce in ether_output (ifp=0xc36ad400, m=0xc3baeb00,
 > dst=0xc0c55c27,
 >     ro=0x301010a) at /usr/src/sys/net/if_ethersubr.c:181
 > ---Type <return> to continue, or q <return> to quit---
 > #15 0xc070b032 in msk_handle_events (sc=0xc3686c00)
 >     at /usr/src/sys/dev/msk/if_msk.c:3048
 > #16 0xc070b828 in msk_int_task (arg=0xc3686c00, pending=1)
 >     at /usr/src/sys/dev/msk/if_msk.c:3625
 > #17 0xc08cac8c in taskqueue_run (queue=0xc36bf380)
 >     at /usr/src/sys/kern/subr_taskqueue.c:72
 > #18 0xc08cadcc in taskqueue_thread_loop (arg=0xc3686c8c)
 >     at /usr/src/sys/kern/subr_taskqueue.c:90
 > #19 0xc0869271 in fork_exit (callout=0xc08cad67 <taskqueue_thread_loop+64>,
 >     arg=0xc3686c8c, frame=0xd533dd38) at /usr/src/sys/kern/kern_fork.c:854
 > #20 0xc0b8e520 in Xatpic_intr0 () at atpic_vector.s:62
 > #21 0x00000000 in ?? ()
 > 
 
 I think it's not a bug of msk(4). Qin Li fixed the bug in arp code.
 See r198301.
 
 For watchdog timeout issues on 88E8053 controller, did you ever try
 disabling MSI? msk(4) was changed a lot since 7.0-RELEASE to
 support newer controllers and added several workarounds to address
 silicon bugs. So don't blindly apply experimental patches to your
 controller. 88E8053 also has a couple of hardware bugs but I guess
 msk(4) already incorporated required workarounds. So if you can
 reliably reproduce watchdog timeouts please let me know. 

From: Mark Atkinson <atkin901@yahoo.com>
To: pyunyh@gmail.com
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Thu, 29 Oct 2009 10:47:47 -0700 (PDT)

 ----- Original Message ----
 
 From: Pyun YongHyeon <pyunyh@gmail.com>
 Sent: Thu, October 29, 2009 9:49:09 AM
 Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
 
 >I think it's not a bug of msk(4). Qin Li fixed the bug in arp code.
 >See r198301.
 
 Thanks I saw the intr call in the trace and assumed wrong, the 'lltable'
 should have tipped me off.
 
 >For watchdog timeout issues on 88E8053 controller, did you ever try
 >disabling MSI? 
 
 I haven't tried that lately in -current, last time I did that msk did 
 not work at all.  Will retry and report back.
 
 > msk(4) was changed a lot since 7.0-RELEASE to
 >support newer controllers and added several workarounds to address
 >silicon bugs. So don't blindly apply experimental patches to your
 >controller.
 
 Yes, this box runs -current constantly, only recently did I have to 
 give up my dual Intel adapter and go back to using the on-board
 pci-e yukon, and thus re-experiencing this issue.
 
 > 88E8053 also has a couple of hardware bugs but I guess
 >msk(4) already incorporated required workarounds. So if you can
 >reliably reproduce watchdog timeouts please let me know. 
 
 It still repros on -current, hence me trying out the experimental
 patches in the PR and reporting back.   As I reported in this PR
 earlier I could still hit the watchdog after a week of runtime, but
 as of now I don't have a reliable repro.
 
 BTW thanks for all your hard work on hardware NIC support.  Very
 much appreciated.
 
 
 
       
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Sat Feb 27 01:19:28 UTC 2010 
State-Changed-Why:  
I bought DGE-560T and I can't reproduce this on CURRENT. Becasue 
there were a lot of changes since May 2008, would please try latest 
msk(4)? 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Sat Feb 27 01:19:28 UTC 2010 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124127 

From: Mikle Davidkin <me@skylord.ru>
To: <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
Date: Mon, 01 Mar 2010 14:27:11 +0300

 On Sat, 27 Feb 2010 01:20:12 GMT, yongari@FreeBSD.org wrote:
 > Synopsis: [msk] watchdog timeout (missed Tx interrupts) -- recovering
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: yongari
 > State-Changed-When: Sat Feb 27 01:19:28 UTC 2010
 > State-Changed-Why: 
 > I bought DGE-560T and I can't reproduce this on CURRENT. Becasue
 > there were a lot of changes since May 2008, would please try latest
 > msk(4)?
 
 Sorry, i have no DGE-560T now and can't try lastest code in near future.
 :-(
 Maybe, you can close these bug as outdated. I'll submit the new one if
 needed and when possible.
 
 
State-Changed-From-To: feedback->closed 
State-Changed-By: yongari 
State-Changed-When: Wed Mar 3 18:22:10 UTC 2010 
State-Changed-Why:  
Submitter no longer have access to the hardware and I couldn't 
reproduce the issue on recent FreeBSD with the same hardware. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124127 
>Unformatted:
