From owner-freebsd-current Thu Nov 25 16:40:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 9EE4D14C8F; Thu, 25 Nov 1999 16:40:28 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id TAA01763; Thu, 25 Nov 1999 19:40:18 -0500 (EST) Date: Thu, 25 Nov 1999 19:40:17 -0500 (EST) From: Bosko Milekic To: Gary Jennejohn Cc: Mark Knight , freebsd-current@FreeBSD.ORG, freebsd-isdn@FreeBSD.ORG Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI In-Reply-To: <199911252210.XAA12659@peedub.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Nov 1999, Gary Jennejohn wrote: !>I can only guess, but it looks like the user-land process isn't told !>about the hangup and keeps sending packets down the line. The packets !>never go out (no connection), so the mbufs eventually run out. The !>raw interface evidently doesn't have the safety belts that the other !>interfaces (like ipr, isppp) have. Out of curiosity, is anything regarding the exhaustion of mb_map being logged to /var/log/messages ? If not, chances are that this is not directly related to an mbuf exhaustion -- the panic, that is, because if mb_map hasn't even been exhausted, then you still potentially have space to allocate from (this is the way it presently works) and the panic is unlikely to be related to an mbuf pointer being NULL and mis-treated. -- Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message