summaryrefslogtreecommitdiff
path: root/fs/mount.h
diff options
context:
space:
mode:
authorBenjamin Poirier <bpoirier@suse.com>2017-07-21 11:36:27 -0700
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2017-10-10 08:59:22 -0700
commit4aea7a5c5e940c1723add439f4088844cd26196d (patch)
treec265d20fdd70ad107988e68001e632ef895a960b /fs/mount.h
parent19110cfbb34d4af0cdfe14cd243f3b09dc95b013 (diff)
downloadlinux-4aea7a5c5e940c1723add439f4088844cd26196d.tar.gz
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 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac68e5 ("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: 16ecba59bc33 ("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>
Diffstat (limited to 'fs/mount.h')
0 files changed, 0 insertions, 0 deletions