From owner-freebsd-hackers Thu May 27 14:58:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7C9FF14C4E for ; Thu, 27 May 1999 14:58:15 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id OAA21252; Thu, 27 May 1999 14:58:01 -0700 (PDT) Date: Thu, 27 May 1999 14:57:59 -0700 (PDT) From: Julian Elischer To: Dennis Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: mbuf stuff In-Reply-To: <199905272140.RAA04730@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 one I figured out :-) > > Dennis > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message