From owner-freebsd-current@FreeBSD.ORG Wed Nov 29 22:53:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7D4E16A403; Wed, 29 Nov 2006 22:53:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8673C43D7F; Wed, 29 Nov 2006 22:51:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kATMpEIX071905; Wed, 29 Nov 2006 15:51:19 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <456E0EDA.60603@samsco.org> Date: Wed, 29 Nov 2006 15:51:06 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: John Birrell References: <45622068.2050705@student.tue.nl> <200611291204.03716.jhb@freebsd.org> <20061129223221.GA359@what-creek.com> <456E0C66.4060404@samsco.org> <20061129225025.GA584@what-creek.com> In-Reply-To: <20061129225025.GA584@what-creek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Rene Ladan , jb@freebsd.org, freebsd-current@freebsd.org Subject: Re: calcru-triggered panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 22:53:27 -0000 John Birrell wrote: > On Wed, Nov 29, 2006 at 03:40:38PM -0700, Scott Long wrote: >> It's probably less of an issue now that it used to be, since I/O is >> decoupled through GEOM threads. In 4.x, you could have a stack that >> went from the syscall, through VFS, UFS, the block layer, CAM, and >> finally the device driver. When I was working on RAIDFrame, adding >> just a couple hundred bytes of stack usage would cause it to blow out. >> But as I said, it might not be as much of an issue now. > > Is it possible to check how deep the stack is and avoid using a stack > buffer if too deep? > > -- > John Birrell I don't know how to do it in a platform-independent way. For i386, I'd check %esp and see if it's getting close to a 2x page boundary. Scott