From eugen@eg.sd.rdtc.ru  Thu Sep 27 11:07:39 2012
Return-Path: <eugen@eg.sd.rdtc.ru>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 31C1C106566C;
	Thu, 27 Sep 2012 11:07:39 +0000 (UTC)
	(envelope-from eugen@eg.sd.rdtc.ru)
Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5])
	by mx1.freebsd.org (Postfix) with ESMTP id 4C8918FC15;
	Thu, 27 Sep 2012 11:07:37 +0000 (UTC)
Received: from eg.sd.rdtc.ru (localhost [127.0.0.1])
	by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q8RB7YXJ010637;
	Thu, 27 Sep 2012 18:07:34 +0700 (NOVT)
	(envelope-from eugen@eg.sd.rdtc.ru)
Received: (from eugen@localhost)
	by eg.sd.rdtc.ru (8.14.5/8.14.5/Submit) id q8RB7TKg010636;
	Thu, 27 Sep 2012 18:07:29 +0700 (NOVT)
	(envelope-from eugen)
Message-Id: <201209271107.q8RB7TKg010636@eg.sd.rdtc.ru>
Date: Thu, 27 Sep 2012 18:07:29 +0700 (NOVT)
From: Eugene Grosbein <egrosbein@rdtc.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc: qa@freebsd.org, jfv@freebsd.org
Subject: [panic] [igb] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         172113
>Category:       kern
>Synopsis:       [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-net
>State:          patched
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Sep 27 11:10:09 UTC 2012
>Closed-Date:    
>Last-Modified:  Fri Sep 27 09:01:57 UTC 2013
>Originator:     Eugene Grosbein
>Release:        FreeBSD 9.1-RC1 amd64
>Organization:
RDTC JSC
>Environment:
System: FreeBSD 9.1-RC1

>Description:
	
	We have got SuperMicro-based server (X8DTU-6+ motherboard),
	with CPU having 12 cores (with hyperthreadng that's 24 CPUs).
	
	We downloaded 9.1-RC1 installation CD and tried to boot it.
	It panices during igb(4) driver init:

http://www.grosbein.net/img/crash-91rc.png

	This is 100% repeatable.

>How-To-Repeat:

	See above.
>Fix:

	Workaround is to disable MSI-X in /boot/loader.conf:

hw.pci.enable_msix=0

	This allows us to boot installation CD and install the system.

	I've found this problem is pretty old and should have been fixed
	over a year ago in 9.0 but it wasn't.

	I've found patch by David G. Lawrence in that thread:
	http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063963.html

	The patch needed some corrections to be applied to 9.1-RC1,
	so I've corrected it and it solved the problem.
	Here is version for 9.1-RC1:

--- sys/dev/e1000/if_igb.c.orig	2012-09-27 14:57:22.000000000 +0700
+++ sys/dev/e1000/if_igb.c	2012-09-27 15:04:35.000000000 +0700
@@ -1328,9 +1328,6 @@
 	/* Don't lose promiscuous settings */
 	igb_set_promisc(adapter);
 
-	ifp->if_drv_flags |= IFF_DRV_RUNNING;
-	ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
-
 	callout_reset(&adapter->timer, hz, igb_local_timer, adapter);
 	e1000_clear_hw_cntrs_base_generic(&adapter->hw);
 
@@ -1356,6 +1353,9 @@
 	/* Set Energy Efficient Ethernet */
 	if (adapter->hw.phy.media_type == e1000_media_type_copper)
 		e1000_set_eee_i350(&adapter->hw);
+
+	ifp->if_drv_flags |= IFF_DRV_RUNNING;
+	ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
 }
 
 static void
@@ -1570,6 +1570,11 @@
 	E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims);
 	++que->irqs;
 
+	if (!(adapter->ifp->if_drv_flags & IFF_DRV_RUNNING)) {
+		return;
+	}
+	more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL);
+
 	IGB_TX_LOCK(txr);
 	igb_txeof(txr);
 #if __FreeBSD_version >= 800000
@@ -1583,8 +1588,6 @@
 #endif
 	IGB_TX_UNLOCK(txr);
 
-	more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL);
-
 	if (adapter->enable_aim == FALSE)
 		goto no_calc;
 	/*

	

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Oct 5 03:27:58 UTC 2012 
Responsible-Changed-Why:  
Over to maintainer(s). 

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

From: Andrew Filonov <andrew.filonov@gmail.com>
To: bug-followup@FreeBSD.org, egrosbein@rdtc.ru
Cc: jvf@freebsd.org
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in
 igb(4): m_getjcl: invalid cluster type
Date: Wed, 24 Oct 2012 14:49:41 +0400

 --000e0ce03f94006e2c04cccbd81d
 Content-Type: multipart/alternative; boundary=000e0ce03f94006e2504cccbd81b
 
 --000e0ce03f94006e2504cccbd81b
 Content-Type: text/plain; charset=ISO-8859-1
 
 We have same problem with HP DL160g6 servers with RELENG8.
 
 Simpliest workaround for me is
 if_igb_load="YES" in /boot/loader.conf
 
 Patch, corrected for 8.3 included
 
 --000e0ce03f94006e2504cccbd81b
 Content-Type: text/html; charset=ISO-8859-1
 
 We have same problem with HP DL160g6 servers with RELENG8.<br><br>Simpliest workaround for me is <br>if_igb_load=&quot;YES&quot; in /boot/loader.conf<br><br>Patch, corrected for 8.3 included<br><br><br>
 
 --000e0ce03f94006e2504cccbd81b--
 --000e0ce03f94006e2c04cccbd81d
 Content-Type: text/plain; charset=US-ASCII; name="igb-path-8.txt"
 Content-Disposition: attachment; filename="igb-path-8.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_h8obei320
 
 LS0tIHN5cy9kZXYvZTEwMDAvaWZfaWdiLmMub3JpZwkyMDEyLTEwLTA5IDIyOjAyOjA1LjAwMDAw
 MDAwMCArMDQwMAorKysgc3lzL2Rldi9lMTAwMC9pZl9pZ2IuYwkyMDEyLTEwLTI0IDE0OjMzOjEz
 LjAwMDAwMDAwMCArMDQwMApAQCAtMTMwNSw5ICsxMzA1LDYgQEAKIAkvKiBEb24ndCBsb3NlIHBy
 b21pc2N1b3VzIHNldHRpbmdzICovCiAJaWdiX3NldF9wcm9taXNjKGFkYXB0ZXIpOwogCi0JaWZw
 LT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9SVU5OSU5HOwotCWlmcC0+aWZfZHJ2X2ZsYWdzICY9
 IH5JRkZfRFJWX09BQ1RJVkU7Ci0KIAljYWxsb3V0X3Jlc2V0KCZhZGFwdGVyLT50aW1lciwgaHos
 IGlnYl9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAJZTEwMDBfY2xlYXJfaHdfY250cnNfYmFzZV9n
 ZW5lcmljKCZhZGFwdGVyLT5odyk7CiAKQEAgLTEzMzMsNiArMTMzMCw5IEBACiAJLyogU2V0IEVu
 ZXJneSBFZmZpY2llbnQgRXRoZXJuZXQgKi8KIAogCWUxMDAwX3NldF9lZWVfaTM1MCgmYWRhcHRl
 ci0+aHcpOworCisJaWZwLT5pZl9kcnZfZmxhZ3MgfD0gSUZGX0RSVl9SVU5OSU5HOworCWlmcC0+
 aWZfZHJ2X2ZsYWdzICY9IH5JRkZfRFJWX09BQ1RJVkU7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0x
 NTQ3LDYgKzE1NDcsMTEgQEAKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9F
 SU1DLCBxdWUtPmVpbXMpOwogCSsrcXVlLT5pcnFzOwogCisJaWYgKCEoYWRhcHRlci0+aWZwLT5p
 Zl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKSB7CisJCXJldHVybjsKKwl9CisJbW9yZV9y
 eCA9IGlnYl9yeGVvZihxdWUsIGFkYXB0ZXItPnJ4X3Byb2Nlc3NfbGltaXQsIE5VTEwpOworCiAJ
 SUdCX1RYX0xPQ0sodHhyKTsKIAlpZ2JfdHhlb2YodHhyKTsKICNpZiBfX0ZyZWVCU0RfdmVyc2lv
 biA+PSA4MDAwMDAKQEAgLTE1NjAsOCArMTU2NSw2IEBACiAjZW5kaWYKIAlJR0JfVFhfVU5MT0NL
 KHR4cik7CiAKLQltb3JlX3J4ID0gaWdiX3J4ZW9mKHF1ZSwgYWRhcHRlci0+cnhfcHJvY2Vzc19s
 aW1pdCwgTlVMTCk7Ci0KIAlpZiAoYWRhcHRlci0+ZW5hYmxlX2FpbSA9PSBGQUxTRSkKIAkJZ290
 byBub19jYWxjOwogCS8qCg==
 --000e0ce03f94006e2c04cccbd81d--

From: John Baldwin <jhb@FreeBSD.org>
To: bug-followup@FreeBSD.org, egrosbein@rdtc.ru
Cc: jfv@FreeBSD.org, George Neville-Neil <gnn@FreeBSD.org>
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in
 igb(4): m_getjcl: invalid cluster type
Date: Sat, 19 Jan 2013 23:26:17 -0500

 I was able to finally reproduce this panic today.  It seems to require
 a server configured for PXE but that receives no DHCP reply (and
 possibly with the requisite SuperMicro X8 board).  I was able to
 prevent the panic with a subset of the referenced patch by only adding
 the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of
 igb_msix_que().  The rest of the patch was unnecessary.  I also added
 some debugging to print out the ICR, EICR, IMS, and EIMS registers in
 this case.  It does look like the hardware is sending an interrupt that
 is not enabled in the interrupt mask (specifically LSC).  In fact, the
 82576 datasheet specifically mentions masking LSC until initialization
 is complete to avoid spurious interrupts during boot and AFAICT igb(4)
 does this since e1000_reset_hw() clears the interrupt mask via writes
 to IMC and doesn't re-enable interrupts until igb_init_locked() is
 invoked via 'ifconfig up'.  Here is my debug output:
 
 SMP: AP CPU #6 Launched!
 SMP: AP CPU #4 Launched!
 stray irq0
 igb0: interrupt on que 0: icr 0x1000004 eicr 0
      ims 0 eims 0x80000000
 
 Hmmm.   Nothing clears EIMS.  After some more debugging, I determined
 that e1000_reset_hw() always turns this bit in EIMS on, even if it is
 off before e1000_reset_hw() is called(!).  I added explicit calls to
 igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().
 This removes the 'stray irq0', but I still get a spurious interrupt
 during boot (albeit with eims 0).  I can use the IFF_DRV_RUNNING hack
 for now, but I think the real fix is something else.
 
 -- 
 John Baldwin

From: George Neville-Neil <gnn@FreeBSD.org>
To: John Baldwin <jhb@FreeBSD.org>
Cc: bug-followup@FreeBSD.org,
 egrosbein@rdtc.ru,
 jfv@FreeBSD.org
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
Date: Mon, 21 Jan 2013 14:25:00 -0500

 On Jan 19, 2013, at 23:26 , John Baldwin <jhb@FreeBSD.org> wrote:
 
 > I was able to finally reproduce this panic today.  It seems to require
 > a server configured for PXE but that receives no DHCP reply (and
 > possibly with the requisite SuperMicro X8 board).  I was able to
 > prevent the panic with a subset of the referenced patch by only adding
 > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of
 > igb_msix_que().  The rest of the patch was unnecessary.  I also added
 > some debugging to print out the ICR, EICR, IMS, and EIMS registers in
 > this case.  It does look like the hardware is sending an interrupt =
 that
 > is not enabled in the interrupt mask (specifically LSC).  In fact, the
 > 82576 datasheet specifically mentions masking LSC until initialization
 > is complete to avoid spurious interrupts during boot and AFAICT igb(4)
 > does this since e1000_reset_hw() clears the interrupt mask via writes
 > to IMC and doesn't re-enable interrupts until igb_init_locked() is
 > invoked via 'ifconfig up'.  Here is my debug output:
 >=20
 > SMP: AP CPU #6 Launched!
 > SMP: AP CPU #4 Launched!
 > stray irq0
 > igb0: interrupt on que 0: icr 0x1000004 eicr 0
 >     ims 0 eims 0x80000000
 >=20
 > Hmmm.   Nothing clears EIMS.  After some more debugging, I determined
 > that e1000_reset_hw() always turns this bit in EIMS on, even if it is
 > off before e1000_reset_hw() is called(!).  I added explicit calls to
 > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().
 > This removes the 'stray irq0', but I still get a spurious interrupt
 > during boot (albeit with eims 0).  I can use the IFF_DRV_RUNNING hack
 > for now, but I think the real fix is something else.
 >=20
 
 I think Jack will have to chime in on this one.  Do you think it's all =
 SM X8 boards
 or just the one we happen to have?  I wonder if Jack or Jeffrey (the =
 testing guy he works
 with) have access to the right board.
 
 Best,
 George
 
 

From: Jack Vogel <jfvogel@gmail.com>
To: George Neville-Neil <gnn@freebsd.org>
Cc: John Baldwin <jhb@freebsd.org>, bug-followup@freebsd.org, egrosbein@rdtc.ru, 
	jfv@freebsd.org
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in
 igb(4): m_getjcl: invalid cluster type
Date: Mon, 21 Jan 2013 12:28:40 -0800

 --f46d04339ce484676004d3d24e43
 Content-Type: text/plain; charset=ISO-8859-1
 
 Well, do you have a more complete designation of the motherboard? We can
 look into it, although if the one check stops the problem it may be a low
 priority.
 
 Jack
 
 
 On Mon, Jan 21, 2013 at 11:25 AM, George Neville-Neil <gnn@freebsd.org>wrote:
 
 >
 > On Jan 19, 2013, at 23:26 , John Baldwin <jhb@FreeBSD.org> wrote:
 >
 > > I was able to finally reproduce this panic today.  It seems to require
 > > a server configured for PXE but that receives no DHCP reply (and
 > > possibly with the requisite SuperMicro X8 board).  I was able to
 > > prevent the panic with a subset of the referenced patch by only adding
 > > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of
 > > igb_msix_que().  The rest of the patch was unnecessary.  I also added
 > > some debugging to print out the ICR, EICR, IMS, and EIMS registers in
 > > this case.  It does look like the hardware is sending an interrupt that
 > > is not enabled in the interrupt mask (specifically LSC).  In fact, the
 > > 82576 datasheet specifically mentions masking LSC until initialization
 > > is complete to avoid spurious interrupts during boot and AFAICT igb(4)
 > > does this since e1000_reset_hw() clears the interrupt mask via writes
 > > to IMC and doesn't re-enable interrupts until igb_init_locked() is
 > > invoked via 'ifconfig up'.  Here is my debug output:
 > >
 > > SMP: AP CPU #6 Launched!
 > > SMP: AP CPU #4 Launched!
 > > stray irq0
 > > igb0: interrupt on que 0: icr 0x1000004 eicr 0
 > >     ims 0 eims 0x80000000
 > >
 > > Hmmm.   Nothing clears EIMS.  After some more debugging, I determined
 > > that e1000_reset_hw() always turns this bit in EIMS on, even if it is
 > > off before e1000_reset_hw() is called(!).  I added explicit calls to
 > > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().
 > > This removes the 'stray irq0', but I still get a spurious interrupt
 > > during boot (albeit with eims 0).  I can use the IFF_DRV_RUNNING hack
 > > for now, but I think the real fix is something else.
 > >
 >
 > I think Jack will have to chime in on this one.  Do you think it's all SM
 > X8 boards
 > or just the one we happen to have?  I wonder if Jack or Jeffrey (the
 > testing guy he works
 > with) have access to the right board.
 >
 > Best,
 > George
 >
 >
 >
 
 --f46d04339ce484676004d3d24e43
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Well, do you have a more complete designation of the motherboard? We can<br=
 >look into it, although if the one check stops the problem it may be a low =
 priority.<br><br>Jack<br><br><br><div class=3D"gmail_quote">On Mon, Jan 21,=
  2013 at 11:25 AM, George Neville-Neil <span dir=3D"ltr">&lt;<a href=3D"mai=
 lto:gnn@freebsd.org" target=3D"_blank">gnn@freebsd.org</a>&gt;</span> wrote=
 :<br>
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex"><br>
 On Jan 19, 2013, at 23:26 , John Baldwin &lt;jhb@FreeBSD.org&gt; wrote:<br>
 <br>
 &gt; I was able to finally reproduce this panic today. =A0It seems to requi=
 re<br>
 &gt; a server configured for PXE but that receives no DHCP reply (and<br>
 &gt; possibly with the requisite SuperMicro X8 board). =A0I was able to<br>
 &gt; prevent the panic with a subset of the referenced patch by only adding=
 <br>
 &gt; the &#39;if_drv_flags &amp; IFF_DRV_RUNNING&#39; check to the start of=
 <br>
 &gt; igb_msix_que(). =A0The rest of the patch was unnecessary. =A0I also ad=
 ded<br>
 &gt; some debugging to print out the ICR, EICR, IMS, and EIMS registers in<=
 br>
 &gt; this case. =A0It does look like the hardware is sending an interrupt t=
 hat<br>
 &gt; is not enabled in the interrupt mask (specifically LSC). =A0In fact, t=
 he<br>
 &gt; 82576 datasheet specifically mentions masking LSC until initialization=
 <br>
 &gt; is complete to avoid spurious interrupts during boot and AFAICT igb(4)=
 <br>
 &gt; does this since e1000_reset_hw() clears the interrupt mask via writes<=
 br>
 &gt; to IMC and doesn&#39;t re-enable interrupts until igb_init_locked() is=
 <br>
 &gt; invoked via &#39;ifconfig up&#39;. =A0Here is my debug output:<br>
 &gt;<br>
 &gt; SMP: AP CPU #6 Launched!<br>
 &gt; SMP: AP CPU #4 Launched!<br>
 &gt; stray irq0<br>
 &gt; igb0: interrupt on que 0: icr 0x1000004 eicr 0<br>
 &gt; =A0 =A0 ims 0 eims 0x80000000<br>
 &gt;<br>
 &gt; Hmmm. =A0 Nothing clears EIMS. =A0After some more debugging, I determi=
 ned<br>
 &gt; that e1000_reset_hw() always turns this bit in EIMS on, even if it is<=
 br>
 &gt; off before e1000_reset_hw() is called(!). =A0I added explicit calls to=
 <br>
 &gt; igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().<=
 br>
 &gt; This removes the &#39;stray irq0&#39;, but I still get a spurious inte=
 rrupt<br>
 &gt; during boot (albeit with eims 0). =A0I can use the IFF_DRV_RUNNING hac=
 k<br>
 &gt; for now, but I think the real fix is something else.<br>
 &gt;<br>
 <br>
 I think Jack will have to chime in on this one. =A0Do you think it&#39;s al=
 l SM X8 boards<br>
 or just the one we happen to have? =A0I wonder if Jack or Jeffrey (the test=
 ing guy he works<br>
 with) have access to the right board.<br>
 <br>
 Best,<br>
 George<br>
 <br>
 <br>
 </blockquote></div><br>
 
 --f46d04339ce484676004d3d24e43--

From: John Baldwin <jhb@freebsd.org>
To: Jack Vogel <jfvogel@gmail.com>
Cc: "George Neville-Neil" <gnn@freebsd.org>,
 bug-followup@freebsd.org,
 egrosbein@rdtc.ru,
 jfv@freebsd.org
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
Date: Tue, 22 Jan 2013 12:09:32 -0500

 On Monday, January 21, 2013 3:28:40 pm Jack Vogel wrote:
 > Well, do you have a more complete designation of the motherboard? We can
 > look into it, although if the one check stops the problem it may be a low
 > priority.
 
 It is a SuperMicro X8DTU-F.
  
 > Jack
 > 
 > 
 > On Mon, Jan 21, 2013 at 11:25 AM, George Neville-Neil <gnn@freebsd.org>wrote:
 > 
 > >
 > > On Jan 19, 2013, at 23:26 , John Baldwin <jhb@FreeBSD.org> wrote:
 > >
 > > > I was able to finally reproduce this panic today.  It seems to require
 > > > a server configured for PXE but that receives no DHCP reply (and
 > > > possibly with the requisite SuperMicro X8 board).  I was able to
 > > > prevent the panic with a subset of the referenced patch by only adding
 > > > the 'if_drv_flags & IFF_DRV_RUNNING' check to the start of
 > > > igb_msix_que().  The rest of the patch was unnecessary.  I also added
 > > > some debugging to print out the ICR, EICR, IMS, and EIMS registers in
 > > > this case.  It does look like the hardware is sending an interrupt that
 > > > is not enabled in the interrupt mask (specifically LSC).  In fact, the
 > > > 82576 datasheet specifically mentions masking LSC until initialization
 > > > is complete to avoid spurious interrupts during boot and AFAICT igb(4)
 > > > does this since e1000_reset_hw() clears the interrupt mask via writes
 > > > to IMC and doesn't re-enable interrupts until igb_init_locked() is
 > > > invoked via 'ifconfig up'.  Here is my debug output:
 > > >
 > > > SMP: AP CPU #6 Launched!
 > > > SMP: AP CPU #4 Launched!
 > > > stray irq0
 > > > igb0: interrupt on que 0: icr 0x1000004 eicr 0
 > > >     ims 0 eims 0x80000000
 > > >
 > > > Hmmm.   Nothing clears EIMS.  After some more debugging, I determined
 > > > that e1000_reset_hw() always turns this bit in EIMS on, even if it is
 > > > off before e1000_reset_hw() is called(!).  I added explicit calls to
 > > > igb_disable_intr() to clear EIMS after each call to e1000_reset_hw().
 > > > This removes the 'stray irq0', but I still get a spurious interrupt
 > > > during boot (albeit with eims 0).  I can use the IFF_DRV_RUNNING hack
 > > > for now, but I think the real fix is something else.
 > > >
 > >
 > > I think Jack will have to chime in on this one.  Do you think it's all SM
 > > X8 boards
 > > or just the one we happen to have?  I wonder if Jack or Jeffrey (the
 > > testing guy he works
 > > with) have access to the right board.
 > >
 > > Best,
 > > George
 > >
 > >
 > >
 > 
 
 -- 
 John Baldwin

From: John Baldwin <jhb@freebsd.org>
To: bug-followup@freebsd.org,
 egrosbein@rdtc.ru
Cc:  
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
Date: Thu, 21 Feb 2013 17:12:55 -0500

 An update on this.  I think we should just use a workaround as this seems to 
 be specific to a certain set of motherboards.  This is the fix I'm using 
 locally:
 
 Index: if_igb.c
 ===================================================================
 --- if_igb.c    (revision 243732)
 +++ if_igb.c    (working copy)
 @@ -1522,6 +1522,15 @@
         u32             newitr = 0;
         bool            more_rx;
  
 +       /*
 +        * The onboard adapters on certain SuperMicro X8* boards
 +        * trigger a spurious interrupt during boot.  Since it
 +        * occurs before the interface is fully configured it
 +        * triggers a panic.  Ignore the interrupt instead.
 +        */
 +       if (!(adapter->ifp->if_drv_flags & IFF_DRV_RUNNING))
 +               return;
 +
         E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims);
         ++que->irqs;
 
 -- 
 John Baldwin

From: Eugene Grosbein <egrosbein@rdtc.ru>
To: bug-followup@FreeBSD.ORG
Cc: Jack Vogel <jfvogel@gmail.com>, George Neville-Neil <gnn@freebsd.org>,
        John Baldwin <jhb@freebsd.org>
Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in
 igb(4): m_getjcl: invalid cluster type
Date: Fri, 27 Sep 2013 15:31:58 +0700

 Hi!
 
 Audit-Trail of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 has more than enough patches to fix the problem.
 
 Would someone be so kind to commit one of them so 9.2-RELEASE
 won't be broken out-of-the-box for noted Supermicro's?
State-Changed-From-To: open->patched 
State-Changed-By: pluknet 
State-Changed-When: Fri Sep 27 09:00:31 UTC 2013 
State-Changed-Why:  
The fix committed to HEAD (r254002), stable/9 (r254003), releng/9.2 (r254009). 

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