NAPI eepro100 bug fixed

[Robert Olsson]

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