Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: Eugene Grosbein egrosb...@rdtc.ru To: bug-follo...@freebsd.org Cc: Jack Vogel jfvo...@gmail.com, George Neville-Neil g...@freebsd.org, John Baldwin j...@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? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
I forward these mails for archives to easier track what was committed for this PR. -- Forwarded message -- From: Jack F Vogel j...@freebsd.org Date: 6 August 2013 22:00 Subject: svn commit: r254002 - head/sys/dev/e1000 To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Author: jfv Date: Tue Aug 6 18:00:53 2013 New Revision: 254002 URL: http://svnweb.freebsd.org/changeset/base/254002 Log: When the igb driver is static there are cases when early interrupts occur, resulting in a panic in refresh_mbufs, to prevent this add a check in the interrupt handler for DRV_RUNNING. MFC after: 1 day (critical for 9.2) Modified: head/sys/dev/e1000/if_igb.c Modified: head/sys/dev/e1000/if_igb.c == --- head/sys/dev/e1000/if_igb.c Tue Aug 6 17:22:06 2013(r254001) +++ head/sys/dev/e1000/if_igb.c Tue Aug 6 18:00:53 2013(r254002) @@ -1572,6 +1572,10 @@ igb_msix_que(void *arg) u32 newitr = 0; boolmore_rx; + /* Ignore spurious interrupts */ + if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0) + return; + E1000_WRITE_REG(adapter-hw, E1000_EIMC, que-eims); ++que-irqs; -- Forwarded message -- From: Jack F Vogel j...@freebsd.org Date: 7 August 2013 01:16 Subject: svn commit: r254009 - releng/9.2/sys/dev/e1000 To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-rel...@freebsd.org Author: jfv Date: Tue Aug 6 21:16:00 2013 New Revision: 254009 URL: http://svnweb.freebsd.org/changeset/base/254009 Log: When the igb driver is static there are cases when early interrupts occur, resulting in a panic in refresh_mbufs, to prevent this add a check to the interrupt handler for DRV_RUNNING. Approved by: re Modified: releng/9.2/sys/dev/e1000/if_igb.c Directory Properties: releng/9.2/sys/ (props changed) releng/9.2/sys/dev/ (props changed) releng/9.2/sys/dev/e1000/ (props changed) Modified: releng/9.2/sys/dev/e1000/if_igb.c == --- releng/9.2/sys/dev/e1000/if_igb.c Tue Aug 6 21:01:38 2013 (r254008) +++ releng/9.2/sys/dev/e1000/if_igb.c Tue Aug 6 21:16:00 2013 (r254009) @@ -1572,6 +1572,10 @@ igb_msix_que(void *arg) u32 newitr = 0; boolmore_rx; + /* Ignore spurious interrupts */ + if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0) + return; + E1000_WRITE_REG(adapter-hw, E1000_EIMC, que-eims); ++que-irqs; ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
Synopsis: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type 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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, egrosb...@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; boolmore_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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: Jack Vogel jfvo...@gmail.com Cc: George Neville-Neil g...@freebsd.org, bug-follo...@freebsd.org, egrosb...@rdtc.ru, j...@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 g...@freebsd.orgwrote: On Jan 19, 2013, at 23:26 , John Baldwin j...@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 0x104 eicr 0 ims 0 eims 0x8000 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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: George Neville-Neil g...@freebsd.org To: John Baldwin j...@freebsd.org Cc: bug-follo...@freebsd.org, egrosb...@rdtc.ru, j...@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 j...@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 0x104 eicr 0 ims 0 eims 0x8000 =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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: Jack Vogel jfvo...@gmail.com To: George Neville-Neil g...@freebsd.org Cc: John Baldwin j...@freebsd.org, bug-follo...@freebsd.org, egrosb...@rdtc.ru, j...@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 g...@freebsd.orgwrote: On Jan 19, 2013, at 23:26 , John Baldwin j...@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 0x104 eicr 0 ims 0 eims 0x8000 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 canbr= look into it, although if the one check stops the problem it may be a low = priority.brbrJackbrbrbrdiv class=3Dgmail_quoteOn Mon, Jan 21,= 2013 at 11:25 AM, George Neville-Neil span dir=3Dltrlt;a href=3Dmai= lto:g...@freebsd.org target=3D_blankg...@freebsd.org/agt;/span wrote= :br blockquote class=3Dgmail_quote style=3Dmargin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1exbr On Jan 19, 2013, at 23:26 , John Baldwin lt;j...@freebsd.orggt; wrote:br br gt; I was able to finally reproduce this panic today. =A0It seems to requi= rebr gt; a server configured for PXE but that receives no DHCP reply (andbr gt; possibly with the requisite SuperMicro X8 board). =A0I was able tobr 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= dedbr 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= hatbr gt; is not enabled in the interrupt mask (specifically LSC). =A0In fact, t= hebr 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 irq0br gt; igb0: interrupt on que 0: icr 0x104 eicr 0br gt; =A0 =A0 ims 0 eims 0x8000br gt;br gt; Hmmm. =A0 Nothing clears EIMS. =A0After some more debugging, I determi= nedbr 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
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, egrosb...@rdtc.ru Cc: j...@freebsd.org, George Neville-Neil g...@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 0x104 eicr 0 ims 0 eims 0x8000 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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: Andrew Filonov andrew.filo...@gmail.com To: bug-follo...@freebsd.org, egrosb...@rdtc.ru Cc: j...@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.brbrSimpliest workaround for me is brif_igb_load=quot;YESquot; in /boot/loader.confbrbrPatch, corrected for 8.3 includedbrbrbr --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-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
Old Synopsis: [panic] [igb] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type New Synopsis: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type 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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
