Date: Thu, 27 May 1999 17:03:12 -0400 From: Dennis <dennis@etinc.com> To: Julian Elischer <julian@whistle.com> Cc: hackers@freebsd.org Subject: Re: mbuf stuff Message-ID: <199905272206.SAA04846@etinc.com> In-Reply-To: <Pine.BSF.3.95.990527145356.4104H-100000@current1.whistle.c om> References: <199905272140.RAA04730@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:57 PM 5/27/99 -0700, you wrote: > > >On Thu, 27 May 1999, Dennis wrote: > >> At 12:26 PM 5/27/99 -0700, you wrote: >> >> >> >> We've encountered a situation where mbuf allocations inside a device >> >> interrupt handler fails occasionally...and it always seems to happen when >> >> rtalloc() is interrupted. Is this due to some sort of locking (rtalloc is >> >> run at splnet())...should it perhaps be run at splimp() to avoid this >> problem? >> > >> >It sounds like your device's interrupt handler should be in the 'net' >> >mask; you certainly shouldn't be doing anything that manipulates mbufs >> >in a non-'net'-masked interrupt handler. >> >> Well how does one check/set this? > >Splnet is a 'soft interrupt' level. > >the device drivers should all use splimp() > >Soft interrupts are by definition held off while a hardware interrupt is >being processes, >however you may need to occasionally rais your spl level to splimp() >when you need to ensure that a hardware interrupt is held off. > >I believe the old 'net' keyword in config files implied splimp, rather >than splnet. > >julian > > >> >> > >> >> What other causes for mbuf failures might reasonably be expected? Is >> >> allocating mbufs at interrupt time something that wasnt expected in the >> >> original system design? >> > >> >The mbuf pool might be empty. > >You should always be ready to handle a mbuf allocation failure at the >lowest levels where you cannot sleep. The problem may be maomentary but as >you can't sleep() you can't wait for it to fix itself. This is easy to do, but the question is, I guess, what can be done to avoid it. Since most of the high speed drivers manipulate mbufs now, should the code that can cause mbuf allocation failures be at splimp()? Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905272206.SAA04846>