From owner-freebsd-hackers  Thu May 27  9:42:56 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from etinc.com (et-gw.etinc.com [207.252.1.2])
	by hub.freebsd.org (Postfix) with ESMTP id AC6981507D
	for <hackers@freebsd.org>; Thu, 27 May 1999 09:42:48 -0700 (PDT)
	(envelope-from dennis@etinc.com)
Received: from dbsys (dbsys.etinc.com [207.252.1.18])
	by etinc.com (8.9.3/8.9.3) with SMTP id MAA03346
	for <hackers@freebsd.org>; Thu, 27 May 1999 12:42:34 -0400 (EDT)
Message-Id: <199905271642.MAA03346@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 27 May 1999 11:39:11 -0400
To: hackers@freebsd.org
From: Dennis <dennis@etinc.com>
Subject: mbuf stuff
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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?

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?

Dennis


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message