From owner-freebsd-current@FreeBSD.ORG Sat May 1 08:42:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77A1B16A4CE for ; Sat, 1 May 2004 08:42:46 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5650A43D2D for ; Sat, 1 May 2004 08:42:46 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 487A872DF1; Sat, 1 May 2004 08:42:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 450E472DBF for ; Sat, 1 May 2004 08:42:46 -0700 (PDT) Date: Sat, 1 May 2004 08:42:46 -0700 (PDT) From: Doug White To: current@freebsd.org In-Reply-To: <20040430135155.C67990@carver.gumbysoft.com> Message-ID: <20040501082529.C80212@carver.gumbysoft.com> References: <20040430135155.C67990@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: src/sys/vm/vm_init.c v1.43 hangs amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 01 May 2004 15:42:46 -0000 On Fri, 30 Apr 2004, Doug White wrote: > I've been having problems with adm64 hanging under load on my dual opteron > 244 machine. Its a HDAMA mainboard with 2GB RAM. The problems started > around April 8. I finally found some time this week to narrow down the > commit that causes the breakage; its rev 1.43 of src/sys/vm/vm_init.c. Update to this. 1. Peter and I kicked this around on IRC yesterday. He wasn't able to reproduce it with a separate program, at least immediately. We also did some math and the numbers involved aren't large enough to be overflowing. 2. Changing COPTFLAGS to '-O -frename-registers -pipe' from the default '-O2 -frename-registers -pipe' stops the crash. So it may be an O2-specific optimization bug. 3. Assigning the values to a local variable doesn't seem to affect things, although it allows for easier experimentation. Using this, I found that the parentheses around the multiplications affects the crash. First, I added these variables: vm_size_t nswbufsize; vm_size_t nbufsize; then later assigned them: nbufsize = (nbuf*BKVASIZE); nswbufsize = (nswbuf*MAXPHYS); and changed the size argument to kmem_suballoc() to use the variables instead of the expressions directly. This setup triggers the crash. Removing the parentheses from the variable assignments: nbufsize = nbuf*BKVASIZE; nswbufsize = nswbuf*MAXPHYS; stops the crash. So in the end, at -O2, (nswbuf*MAXPHYS) != nswbuf*MAXPHYS. Creepy, eh? I'll see if I can come up with a standalone test case to submit to the gcc folks. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org