From owner-freebsd-bugs Fri Jan 7 0: 0:17 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id EDAA2154D5 for ; Fri, 7 Jan 2000 00:00:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA88146; Fri, 7 Jan 2000 00:00:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Fri, 7 Jan 2000 00:00:02 -0800 (PST) Message-Id: <200001070800.AAA88146@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bosko Milekic Subject: Re: kern/10872: Panic in soreceive() due to NULL mbuf pointer Reply-To: Bosko Milekic Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/10872; it has been noted by GNATS. From: Bosko Milekic To: Terry Kennedy Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/10872: Panic in soreceive() due to NULL mbuf pointer Date: Fri, 7 Jan 2000 02:57:51 -0500 (EST) On Fri, 7 Jan 2000, Terry Kennedy wrote: > I can say that the tulip_rx_intr() crash was in a MCLGET macro, and that >a netstat -m on the various crash dumps all showed an apparently impossible >mbuf usage - something like "1700/1600 mbufs in use" - however, in other >*BSD's, I've found that the assorted *stat programs sometimes get confused >between the running kernel values and the ones in the crash dump. Perhaps >this is enough of a hint, though. Hmmm, judging from your original post, I thought that what you were receiving in tulip_rx_intr() was a page fault? In any case, at the time this was occuring, `netstat -m' could display `peak' for mbuf _clusters_ greater than the actual `max.' However, this has been changed and now the limit of possible mclusters allocated from the pool is capped at exactly to what it was tuned for. Considering all this, a fair assumption would be that the tulip_rx_intr() panic was a side-effect of an mbuf shortage. Hopefully, you will no longer obtain this particular panic. As for the sbdrop() issue, that, I believe, is a whole other story. I think, at this point, that the problem is fairly isolated in the uipc_socket2.c code, and has not-so-much to do with the fxp driver, in particular, but that it occurs more as a `side-effect' of some timing-related issue. I'd prefer to keep searching until I figure it out before claiming anything, though. The biggest problem that I have at this end is that due to lack of hardware, I cannot reproduce it. Thanks for your input! Bosko. -- Bosko Milekic Email: bmilekic@dsuper.net WWW: http://pages.infinit.net/bmilekic/ -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message