From owner-freebsd-ppc Tue Oct 1 5:56:48 2002 Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 618F637B401; Tue, 1 Oct 2002 05:56:47 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C14343E4A; Tue, 1 Oct 2002 05:56:46 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) 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 IAA18749; Tue, 1 Oct 2002 08:56:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g91CuFx10954; Tue, 1 Oct 2002 08:56:15 -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: <15769.39791.486131.152431@grasshopper.cs.duke.edu> Date: Tue, 1 Oct 2002 08:56:15 -0400 (EDT) To: Peter Grehan Cc: freebsd-ppc@freebsd.org Subject: Re: atomic.h vs atomic.s In-Reply-To: <3D98FD84.D523B8F@freebsd.org> References: <15768.30116.381592.891890@grasshopper.cs.duke.edu> <15768.62718.937391.963035@grasshopper.cs.duke.edu> <3D98FD84.D523B8F@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-ppc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Grehan writes: > Hi Drew, > > > OK, I've put sync's all over the atomic code and that didn't help. > > Maybe its a pmap problem. I notice that programs will > > occasionally abort, then run OK the second time I try them. > > Actually, I think it's a simple problem: the atomic_* routines don't > disable interrupts, so there's a window between the initial load > and the reservation. Isn't the lwarx instruction the first instruction in the atomic_* routines? From a brief read of MPCFPE32B.pdf, I thought that the reservation disappeared if the memory convered by the reservation is modified in any way. That's what I'd expect from an atomic op. This reminds me of the load_locked, store_conditional primatives available on alpha.. Are you saying that the lwarx instruction itself is not atomic wrt to interrupts? > I have had problems with this type of thing recently, most notably with the > value of td_intr_nesting_level going negative, which I worked around by > not re-enabling interrupts in the OpenPIC code. > > Does this sound plausible to you ? > > On the bright side, does this also mean that you have built a > kernel natively ? I haven't tried that yet :-) More or less.. I could compile about 20 files, then the machine would crash. Once I made it through all the .o's, I couldn't get a kernel to link without the machine falling over, so I gave up and used the cross compiler/linker that Mark Peek posted last year.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ppc" in the body of the message