Date: Fri, 10 May 2002 20:48:37 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: obrien@FreeBSD.ORG, alpha@FreeBSD.ORG, Jeff Roberson <jroberson@chesapeake.net>, alc@FreeBSD.org Subject: Re: gcc3 & alpha kernels Message-ID: <XFMail.20020510204837.jhb@FreeBSD.org> In-Reply-To: <15580.13914.162169.930227@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-May-2002 Andrew Gallatin wrote:
>
> Jeff Roberson writes:
> > On Fri, 10 May 2002, Andrew Gallatin wrote:
> >
> > >
> > > Alan Cox writes:
> > > > >
> > > > > Did Jeff see a lockup at boot? Or was this on a running system?
> > > >
> > > > I believe it was at boot time. I can't swear to that, however.
> > > >
> > >
> > > Thanks.. that's the same as me. It would seem that the new compiler
> > > is botching the atomic inlines then.
> > >
> > > Hmm.. According to the disassembly, it looks like the correct
> > > sequences are there, though..
> > >
> > > Drew
> > >
> >
> > It was at boot time. I believe that this was the first time we ever did
> > negative atomic ints on alpha. This was with the old compiler as well. I
> > haven't looked at the gcc3 output.
> >
> > When I looked at the assembly it was pretty clear that the inline wasn't
> > written to support non sign extended values. If you change the prototype
> > the signed int everything works as expected though.
>
Bah, I sent another reply already with more detail. It turns out to be a bug
in the C code and people shooting their feet off trying to be too fancy with
atomic ops.
In the diff I posted earlier there was this questionable section:
- : 22 76 20 48 zapnot t0,0x3,t1
: 21 76 20 48 zapnot t0,0x3,t0
- : 01 04 21 42 addq a1,t0,t0
+ : 22 f6 21 48 zapnot t0,0xf,t1
+ : 01 04 31 40 addq t0,a1,t0
: 01 f0 23 44 and t0,0x1f,t0
: 00 00 83 a8 ldl_l t3,0(t2)
: 24 f6 81 48 zapnot t3,0xf,t3
: a4 05 82 40 cmpeq t3,t1,t3
- : 04 00 80 e4 beq t3,124 <_vm_object_allocate+0xbc>
+ : 04 00 80 e4 beq t3,168 <_vm_object_allocate+0xc8>
This is the first atomic_cmpset_int() loop. The problem is that when
we copy t0 to t1, we zapnot more bits. The reason is that t1 is a short,
not an int. The reason for that is that for some weird reason,
object->pg_color is a u_short even though next_index and incr are ints. So
gcc currectly converts the unsigned short value in object->pg_color to an
int for atomic_cmpset_int() and if next_index has wrapped we are screwed.
One fix would be to cast object->pg_color to an int for this call but that
still has wrapping issues. A better fix is probably to stop microptimizing
struct vm_object and use a int for pg_color. I suggest that all the atomic
ops buried in the vm code be checked very carefully for these types of
short/int mismatches as well as any int/long mismatches and the like.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020510204837.jhb>