Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled

[YongHyeon PYUN]

On Sun, Oct 30, 2011 at 12:27:14PM +0330, Hooman Fazaeli wrote:
> 
> I finally managed to re-produce an affect similar to Jason's case. It
> may not be the exact same issue, but it is a serious problem and must
> be addressed.
> 
> 1. Push out packet on em/igb with high rate.
> 2. Disconnect cable and wait for a few seconds. "netstat -ind" shows that
>    Drops are increasing.
> 3. Re-connect the cable. Both sides of like re-negotiate and the links 
> comes up.
> 4. But ..., no packets is ever transmitted again and Drops still increasing!
> 
> This is because em/lem/igb and some other interfaces (i.e., bce) have
> a check at the very beginning of their _start function
> which checks link status and immediately returns if it is inactive.
> This behavior causes if_snd to fills up in step 2 and when this happens,
> IFQ_HANDOFF never calls if_start again, even when the link becomes
> active again.
> 
> A cable unplug is not necessary to trigger the issue. Any temporary
> link loss (e.i., during re-negotiation) can potentially lead to
> aforementioned problem.
> 
> IMHO, this is not a driver issue and the real fix would be to change
> IFQ_HANDOFF to call if_start when the queue is full.
> 

It would be normal not to call IFQ_HANDOFF when driver queue is
full since it would be waste of time to invoke driver TX routine
again.  If driver fails to send queued frames again when it
re-established a link it sounds like a driver bug.  Of course,
there is a problem here as driver can send queued frames without
knowing how much time the frame queued in TX queue. Depending on
application this behavior may or may not useful.

> Jason, If you are interested, I can prepare a patch for you
> to address this issue in if_em and see if it helps.
>