Zhang Fuxin writes:
> My first NAPI eepro100 contains a subtle but fatal race,which will
> lead
> to lockup(of the whole machine here,but of ether interface for paul). This
> version should be ok, Paul, would you like to have a try? I've tested it
> in my
> will meet it,so it is listed here.
> /* disable interrupts here is necessary!
> * We need to ensure Rx/RxNobuf ints are disabled if in poll
> * flag is set. If interrupt comes bwteen netif_rx_complete
> * and enable_rx_and_rxnobuf_ints, the following will happen:
> * netif_rx_complete --> clear RX_SCHED flag
> * -> ints(e.g. TxDone)
> * speedo_interrupt
> * if (netif_rx_schedule_prep(dev))
> * disable_rx_and_rxnobuf_ints
> * return
> * <-
> * enable_rx_and_rxnobuf_ints
> * then we will have Rx&RxNoBuf ints enable while in polling!
> * it may lead to endless interrupts and effective lockup of
> * the whole machine.
> */
> spin_lock_irqsave(&sp->lock,flags);
> netif_rx_complete(dev);
> enable_rx_and_rxnobuf_ints(dev);
> spin_unlock_irqrestore(&sp->lock,flags);
Thanks!
Yes as far as I see this correct... and this race and others is mentioned
in NAPI_HOWTO.txt and yes the spinlock can help for the drivers that uses
this type interrupt acking. And tulip is a candidate for this as well. Let
see if it solves Paul's problem to start with.
Cheers.
--ro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:16 EST