Date: Fri, 18 Oct 2002 14:05:34 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Petri Helenius <pete@he.iki.fi> Cc: Jim McGrath <jimmcgra@bellatlantic.net>, Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018140534.A84731@carp.icir.org> In-Reply-To: <017201c276e8$58e4b8f0$3500080a@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 11:53:00PM %2B0300 References: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net> <00b001c276ba$1533dbf0$3500080a@PHE> <20021018103825.B82982@carp.icir.org> <017201c276e8$58e4b8f0$3500080a@PHE>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 18, 2002 at 11:53:00PM +0300, Petri Helenius wrote: > > In special cases, the error induced by having interrupts blocked > > causes errors which are much larger than polling alone. > > Which conditions block interrupts for longer than, say, a millisecond? changes in link status in several ethernet drivers will cause their interrupt service routine (ISR) to loop polling for some event. A similar thing used to happen in the xl driver when fetching statistics, once per second (hopefully fixed now). Even in "normal" condition, the ISR for a network card has to loop around the status bit until no interrupts are pending, and because (typically) the receive ring is replenished while you process it, and packets come in without explicitly requesting them, there is no upper bound on how long you will loop. I wouldn't be surprised if there were other drivers doing busy-wait cycles in the interrupt service routine, because sometimes the driver detects an error condition and calls some generic routine to reinitialize the hardware, but that routine has been written for use at attach time, not at runtime. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021018140534.A84731>