> From: Dennis <den...@etinc.com> > Date: 1999-05-27 09:43:09 -0700 > To: hack...@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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
