From owner-freebsd-current Sun Jul 11 0:12:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 8979014C20 for ; Sun, 11 Jul 1999 00:12:43 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA09652; Sun, 11 Jul 1999 08:12:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 11 Jul 1999 08:12:52 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: Alan Cox , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <199907102141.OAA58697@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999, Matthew Dillon wrote: > > The supposedly atomic functions in i386/include/atomic.h are not > as atomic as was previously thought :-): > > #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) > > I looked at that kinda funny. But C doesn't guarentee a RMW opcode > for a "+=" !!!. Alan found an example showing a load, add, and > separate store by disassembling the kernel. An interrupt occuring in > the middle of that sequence would lead to the reported problems. > > I'm pretty sure this is the problem causing the "objtrm" lockups. I've > submitted a patch to Alan to make those atomic_*() functions inline > assembly. > > There also appear to be a number of mistakes in some of the inline > assembly already laying around -- some of it appears to specify output > arguments for RMW instructions without also indicating to the compiler > that those are input arguments as well, leading to bogus optimizations > by the C compiler. The 'setbits' function is the one Alan found > inadvertantly while we were trying to figure out why my first iteration > didn't work. heh heh. Alan will fix the setbits inline. > > It wouldn't hurt if someone with more assembly experience could audit > all of the inline assembly present in the source base. > > I am re-running the 16MB/make -j5 buildworld test to see if this has > really fixed the problem. What a nightmare. This must be due to egcs compiling things differently from gcc 2.7.1. I should have guessed when people started talking about objtrm (I spent many unhappy hours looking for objtrm bugs on the alpha) but my attention was elsewhere. Before I fixed this stuff for the alpha, the += expressions were scattered all over the source tree. At least you get to fix the macro :-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message