From owner-freebsd-hackers Thu May 27 12:29: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 9E2941599B for ; Thu, 27 May 1999 12:29:00 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA01660; Thu, 27 May 1999 12:26:12 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199905271926.MAA01660@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dennis Cc: hackers@freebsd.org Subject: Re: mbuf stuff In-reply-to: Your message of "Thu, 27 May 1999 11:39:11 EDT." <199905271642.MAA03346@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 May 1999 12:26:12 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. > 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. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message