Module Name: src
Committed By: msaitoh
Date: Mon Jun 4 02:42:23 UTC 2018
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixv.c
Log Message:
Don't call ixgbe_rearm_queues() in ixgbe_local_timer1().
ixgbe_enable_queue() and ixgbe_disable_queue() try to enable/disable queue
interrupt safely. It has the internal counter. When a queue's MSI-X is
received, ixgbe_msix_que() is called (IPL_NET). This function disable the
queue's interrupt by ixgbe_disable_queue() and issues an softint.
ixgbe_handle() queue is called by the softint (IPL_SOFTNET), process TX, RX
and call ixgbe_enable_queue() at the end.
ixgbe_local_timer1() is a callout and run always on CPU 0 (IPL_SOFTCLOCK).
When ixgbe_rearm_queues() called, an MSI-X interrupt is issued for a specific
queue. It may not CPU 0. If this interrupt's ixgbe_msix_que() is called and
sofint_schedule() is called before the last sofint's softint_execute() is not
called, the softint_schedule() fails because of SOFTINT_PENDING. It result
in breaking ixgbe_{enable,disable}_queue()'s internal counter.
ixgbe_local_timer1() is written not to call ixgbe_rearm_queues() if
the interrupt is disabled, but it's called because of unknown bug or a race.
One solution to avoid this problem is to not to use the internal counter,
but it's little difficult. Another solution is stop using
ixgbe_rearm_queues() at all. Essentially, ixgbe_rearm_queues() is not
required (it was added in ixgbe.c rev. 1.43 (2016/12/01)).
ixgbe_rearm_queues() helps for lost interrupt problem but I've never seen it
other than ixgbe_rearm_queues() problem.
XXX pullup-8.
To generate a diff of this commit:
cvs rdiff -u -r1.159 -r1.160 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.103 -r1.104 src/sys/dev/pci/ixgbe/ixv.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
