When using msix interrupt model (e.g. 82574L chip), all interrupts excepted E1000_ICR_RXQ0, E1000_ICR_RXQ1, E1000_ICR_TXQ0, E1000_ICR_TXQ1 are handled by the em_msix_link() function. Currently, this function only checks for E1000_ICR_LSC: https://svnweb.freebsd.org/base/releng/10.1/sys/dev/e1000/if_em.c?view=markup#l1615 Hence when an E1000_ICR_RXO interrupt occurs, it's cleared (because of ICR reading), but adapter->rx_overruns is *not* incremented. This may hide a chip hang (bug #199174).
I'm deep into the 82574L now. I'll take this for review.
Index: if_em.c =================================================================== --- if_em.c (revision 282317) +++ if_em.c (working copy) @@ -1609,6 +1609,9 @@ ++adapter->link_irq; reg_icr = E1000_READ_REG(&adapter->hw, E1000_ICR); + if (reg_icr & E1000_ICR_RXO) + adapter->rx_overruns++; + if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { adapter->hw.mac.get_link_status = 1; em_handle_link(adapter, 0); Should DTRT
(In reply to Sean Bruno from comment #2) I think so. Also, nice catch, David. This *may* explain a behavior when we were setting a bunch of missed_packets on RX side with very less rx_overruns reported.
A commit references this bug: Author: sbruno Date: Fri May 22 17:01:44 UTC 2015 New revision: 283290 URL: https://svnweb.freebsd.org/changeset/base/283290 Log: Bump rx_overruns when indicated by the ICR mask. PR: 199716 MFC after: 3 days Sponsored by: Limelight Networks Changes: head/sys/dev/e1000/if_em.c
A commit references this bug: Author: sbruno Date: Mon May 25 00:30:27 UTC 2015 New revision: 283504 URL: https://svnweb.freebsd.org/changeset/base/283504 Log: MFC r283290 Bump rx_overruns when indicated by the ICR mask. PR: 199716 Sponsored by: Limelight Networks Changes: _U stable/10/ stable/10/sys/dev/e1000/if_em.c