From owner-freebsd-alpha Fri May 10 12:53:12 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id E408237B400; Fri, 10 May 2002 12:53:05 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA19965; Fri, 10 May 2002 15:53:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g4AJqZF80380; Fri, 10 May 2002 15:52:35 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15580.9475.2695.221222@grasshopper.cs.duke.edu> Date: Fri, 10 May 2002 15:52:35 -0400 (EDT) To: Alan Cox Cc: alpha@FreeBSD.ORG, jeff@FreeBSD.ORG Subject: Re: gcc3 & alpha kernels In-Reply-To: <20020510194133.GA13871@cs.rice.edu> References: <20020510194133.GA13871@cs.rice.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alan Cox writes: > > I do NOT know if this was the fault of gcc3, but it smells like it. > > According to nm, this address is in _vm_object_allocate(). A few > > other times, it locked with an address in what looked like mlock(). > > A few days ago Jeff Robertson had a problem in this neighborhood > on alpha triggered by an atomic_cmpset_int() that I had introduced > in _vm_object_allocate(). He resolved with the following change > to src/sys/alpha/include/atomic.h: > > Revision 1.12 / (download) - annotate - [select for diffs], Wed May 8 05:19:56 2002 UTC (2 days, 13 hours ago) by jeff > Branch: MAIN > CVS Tags: HEAD > Changes since 1.11: +2 -1 lines > Diff to previous 1.11 (colored) > > zapnot the signed bits in atomic_cmpset_32. Previously this did not work with > negative values because the original value was sign extended but the compared > value was not. > > If I'm not mistaken, prior to this change, he locked up > in _vm_object_allocate() much as Andrew described. Did Jeff see a lockup at boot? Or was this on a running system? FWIW, building with the older compile fixes the problem, so perhaps the new compiler is somehow botching the atomic inlines. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message