Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Jul 1999 08:12:52 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Alan Cox <alc@cs.rice.edu>, Stephen McKay <syssgm@detir.qld.gov.au>, Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-current@freebsd.org
Subject:   Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
Message-ID:  <Pine.BSF.4.05.9907110809140.43222-100000@herring.nlsystems.com>
In-Reply-To: <199907102141.OAA58697@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907110809140.43222-100000>