On Thu, May 16, 2024 at 01:41:22PM +0200, Burakov, Anatoly wrote:
> On 4/18/2024 3:53 PM, edwin.brosse...@6wind.com wrote:
> > From: Edwin Brossette <edwin.brosse...@6wind.com>
> >
> > Since link state may need some time to stabilize after a link state
> > change, we cannot update the link state right after one occurs. So link
> > state change interrupts (lsc) are handled after a delay. To do this, an
> > alarm to call a delayed handler is programmed. This delayed handler is
> > tasked with updating the link after a variable delay of one to four
> > seconds which should be enough time for the link state to become stable
> > again.
> >
> > However, a problem can occur with some models of network cards. For
> > example, ixgbe_mac_X550EM_x may trigger this interrupt twice because
> > another interrupt signal is received on the General Purpose Interrupt
> > pin SPD0, which has the same interrupt handler. In such a case, the
> > delayed interrupt handler would be programmed to be executed twice.
> >
> > Since we save the original interrupt mask value to restore it after the
> > delayed handler is done with its work, we end up overwritting its value
> > after the second alarm is programmed. Even worse: when restoring it the
> > first time, the saved original mask variable is reset to 0, so we end up
> > completely disabling all interrupts when trying to restore this mask
> > after the second time the delayed handler is executed.
> >
> > Add a check on the interrupt mask value when programming the alarm for
> > the delayed handler. If the bit for lsc interrupts is unset, it means an
> > alarm was already programmed for the delayed handler. In this case, skip
> > the alarm creation.
> >
> > Fixes: 9b667210700e ("net/ixgbe: fix blocked interrupts")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Edwin Brossette <edwin.brosse...@6wind.com>
> > ---
> Reviewed-by: Anatoly Burakov <anatoly.bura...@intel.com>
>
Applied to dpdk-next-net-intel
Thanks,
/Bruce
