From owner-freebsd-isdn Fri Nov 26 16: 4: 0 1999 Delivered-To: freebsd-isdn@freebsd.org Received: from shrewd.knigma.org (shrewd.demon.co.uk [212.229.151.45]) by hub.freebsd.org (Postfix) with ESMTP id 3F44A14DBA for ; Fri, 26 Nov 1999 16:03:41 -0800 (PST) (envelope-from markk@knigma.org) Received: from lap.knigma.org (lap.knigma.org [10.128.148.202]) by shrewd.knigma.org (8.9.3/8.9.3) with SMTP id AAA01229 for ; Sat, 27 Nov 1999 00:03:46 GMT (envelope-from markk@knigma.org) Message-ID: Date: Sat, 27 Nov 1999 00:03:18 +0000 To: freebsd-isdn@freebsd.org From: Mark Knight Subject: Re: Panic caused by mbuf exhaustion in i4b with AVM PCI References: <199911262012.VAA14737@peedub.muc.de> In-Reply-To: <199911262012.VAA14737@peedub.muc.de> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 4.02 U Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199911262012.VAA14737@peedub.muc.de>, Gary Jennejohn writes >Hmm, it looks like the HSCX isn't being deactivated. Can you try this patch >and report back ? > >===================================================================== >*** i4b_avm_fritz_pci.c Fri Nov 26 20:51:05 1999 >--- i4b_avm_fritz_pci.c.orig Fri Nov 26 20:48:55 1999 The buffer overruns in my earlier logs appear to be a function of the logging being enabled and my ageing Pentium 90 struggling to keep up. Apart from the obvious typo preventing your patch from compiling (brackets required around the logging macro), this has definitely improved things! With a single incoming call, with the caller clearing down, netstat -m now shows mbuf usage returning to the original level, and staying there. If BSD clears down this is also fine, as before. In my delight I've now taken the destruction test a stage further: If I make two incoming calls, both of which are answered and receive the outgoing message, even if I allow i4b to clear each call after the outbound message, I get back to a state of run away mbuf allocation and impending panic. This time, it's much harder to restore stability, although this can be done with about 3 or 4 incoming calls in rapid succession. I've tried setting isdndebug to record this new scenario, but my machine just can't service the interrupts quickly enough. Thanks for your patch - a major leap forward in that a single wrong number won't crash my box :) -- Mark Knight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message