]> git.baikalelectronics.ru Git - kernel.git/commit
e1000e: Avoid receiver overrun interrupt bursts
authorBenjamin Poirier <bpoirier@suse.com>
Fri, 21 Jul 2017 18:36:27 +0000 (11:36 -0700)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tue, 10 Oct 2017 15:59:22 +0000 (08:59 -0700)
commit7787cd116c7568afc299cc7a25a30381215e3e58
treec265d20fdd70ad107988e68001e632ef895a960b
parent0816c8e2c8c5f4b1da0acdbd9a7598e0c24fad73
e1000e: Avoid receiver overrun interrupt bursts

When e1000e_poll() is not fast enough to keep up with incoming traffic, the
adapter (when operating in msix mode) raises the Other interrupt to signal
Receiver Overrun.

This is a double problem because 1) at the moment e1000_msix_other()
assumes that it is only called in case of Link Status Change and 2) if the
condition persists, the interrupt is repeatedly raised again in quick
succession.

Ideally we would configure the Other interrupt to not be raised in case of
receiver overrun but this doesn't seem possible on this adapter. Instead,
we handle the first part of the problem by reverting to the practice of
reading ICR in the other interrupt handler, like before commit 93410865bad2
("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
61297a6676ba ("e1000e: Fix msi-x interrupt automask") which cleared IAME
from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
anymore. We handle the second part of the problem by not re-enabling the
Other interrupt right away when there is overrun. Instead, we wait until
traffic subsides, napi polling mode is exited and interrupts are
re-enabled.

Reported-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Fixes: 93410865bad2 ("e1000e: Do not read ICR in Other interrupt")
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/e1000e/defines.h
drivers/net/ethernet/intel/e1000e/netdev.c