From owner-freebsd-amd64@FreeBSD.ORG Wed Aug 30 19:48:26 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2280416A4DA; Wed, 30 Aug 2006 19:48:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E04F43D5F; Wed, 30 Aug 2006 19:48:15 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k7UJmExT032507; Wed, 30 Aug 2006 12:48:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k7UJmE9L032506; Wed, 30 Aug 2006 12:48:14 -0700 (PDT) (envelope-from sgk) Date: Wed, 30 Aug 2006 12:48:14 -0700 From: Steve Kargl To: John Baldwin Message-ID: <20060830194814.GA32136@troutmask.apl.washington.edu> References: <200608151701.46724.jhb@freebsd.org> <200608301404.53834.jhb@freebsd.org> <20060830190944.GA2146@troutmask.apl.washington.edu> <200608301524.55149.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608301524.55149.jhb@freebsd.org> User-Agent: Mutt/1.4.2.2i Cc: amd64@freebsd.org Subject: Re: FINALLY! Re: linux32 breakage in current.. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 19:48:26 -0000 On Wed, Aug 30, 2006 at 03:24:54PM -0400, John Baldwin wrote: > > You have to use ktrace -i because bash forks children and the last one gets a > SIG11 from a child process that dies and kills the parent. Still, I've > stared at these before and been none the wiser. However, it doesn't make > _any_ sense that the cvsup changes you mentioned fix it and the patch > doesn't, because the patch does the _same_ thing. > The cvsup timestamps are 5 minutes apart for the good and bad kernels. If this is a memory alignment issue, then your patch would need to replicate the old alignment. That is, this is similar to the old Fortran issue that a simple debugging print statement can suddenly make code work because an array in memory has moved and stepping off the end of the array doesn't touch already used memory. I wonder if memguard might help. I'll go read up of this. -- Steve