Date: Thu, 27 May 1999 10:20:58 -0700 From: "Justin C. Walker" <justin@apple.com> To: hackers@freebsd.org Subject: Re: mbuf stuff Message-ID: <199905271721.KAA02035@walker3.apple.com>
next in thread | raw e-mail | index | archive | help
> From: Dennis <dennis@etinc.com> > Date: 1999-05-27 09:43:09 -0700 > To: hackers@FreeBSD.ORG > Subject: mbuf stuff > > 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? > > 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? This may be already clear, but just in case: m_get has an argument (nowait) to tell the allocater whether it's ok to sleep to wait for buffers in a low-memory situation. When called from interrupt level, the call can't sleep, so you have to set 'nowait' to M_DONTWAIT. This means that you *have* to deal with a null return in this case. In your specific case, rtalloc() calls rtalloc1(), which raises the processor priority to splnet (I'm looking at a 3.1 source base). You can interrupt rtalloc() without harm. I do wonder why you're always in that routine when this occurs, but I can't provide any illumination there. How frequently does this occur? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-------------------------------------*-------------------------------* 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?199905271721.KAA02035>