Messages in this thread | | | From | Robert Olsson <> | Date | Tue, 18 Jun 2002 19:07:38 +0200 | Subject | NAPI eepro100 bug fixed |
| |
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/
| |