Date: Thu, 25 Nov 1999 22:36:45 +0000 From: Mark Knight <markk@knigma.org> To: freebsd-isdn@freebsd.org Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI Message-ID: <GplAgPA9nbP4Ewz2@knigma.org> In-Reply-To: <199911252210.XAA12659@peedub.muc.de> References: <KokTwDA5oaP4EwCV@knigma.org> <199911252210.XAA12659@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199911252210.XAA12659@peedub.muc.de>, Gary Jennejohn <garyj@peedub.muc.de> writes >Are you using the code in -current or one of the releases ? Makes a >difference. cvsup'd current from Saturday morning. >Can you a) increase the size of the message buffer in your config file >(options MSGBUF_SIZE=81920, for example) b) turn on ALL the >trace in the kernel with isdndebug c) cause the panic to happen again >and get a crash dump ? I'll give this a go. >It would also be good if you could run isdntrace in parallel so that >there's some correlation between the kernel messages and the trace times. I did include that in my earlier post - in case you missed it... >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. I've tried killing the user land daemon and the growth continues. Latest finding. Once the run-away has started, another incoming call allowed to complete with FreeBSD performing the clear down results in all mbufs being freed and stability returning. -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?GplAgPA9nbP4Ewz2>