From owner-cvs-all@FreeBSD.ORG Sat Mar 20 21:34:08 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C361D16A4CE; Sat, 20 Mar 2004 21:34:08 -0800 (PST) Received: from mail008.syd.optusnet.com.au (mail008.syd.optusnet.com.au [211.29.132.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id D63DB43D2D; Sat, 20 Mar 2004 21:34:05 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i2L5Y3d05985; Sun, 21 Mar 2004 16:34:03 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i2L5Y2Na047836; Sun, 21 Mar 2004 16:34:02 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i2L5Y2bL047835; Sun, 21 Mar 2004 16:34:02 +1100 (EST) (envelope-from peter) Date: Sun, 21 Mar 2004 16:34:02 +1100 From: Peter Jeremy To: Bill Paul Message-ID: <20040321053402.GA47807@server.vk2pj.dyndns.org> References: <20040321022537.3910216A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040321022537.3910216A4CF@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/compat/ndis kern_ndis.c ndis_var.h ntoskrnl_var.h subr_ndis.c subr_ntoskrnl.c src/sys/dev/if_ndi X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2004 05:34:09 -0000 On Sat, Mar 20, 2004 at 06:25:37PM -0800, Bill Paul wrote: >It's possible I've misdiagnosed this problem and there's something >else afoot. All I know is that KSTACK_PAGES=8 makes it work on my >test box. Increasing KSTACK_GUARD_PAGES may help ensure that an under-dimensioned kernel stack size blows up correctly (though this will mean tweaking /sys/i386/include/param.h directly because it's not a configurable parameter). As another suggestion: I presume the kernel stack is pre-zeroed. If so, it would be not overly complex to have a task (user or kernel) that regularly checked how much stack was used for each stack and flagged ones that were excessively deep - which would give you an idea of the actual usage. Peter