Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Nov 2006 06:29:55 -0500
From:      Randall Stewart <rrs@cisco.com>
To:        Peter Jeremy <peterjeremy@optushome.com.au>
Cc:        FreeBSD Tinderbox <tinderbox@freebsd.org>, Kip Macy <kip.macy@gmail.com>, John Birrell <jb@what-creek.com>, current@freebsd.org, sparc64@freebsd.org
Subject:   Re: [head tinderbox] failure on sparc64/sun4v
Message-ID:  <454C79B3.9080609@cisco.com>
In-Reply-To: <20061104110644.GE854@turion.vk2pj.dyndns.org>
References:  <20061104060421.6145773068@freebsd-current.sentex.ca>	<20061104070047.GA98215@what-creek.com>	<b1fa29170611032346x5803847esad273b1965cbddcd@mail.gmail.com> <20061104110644.GE854@turion.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> On Fri, 2006-Nov-03 23:46:27 -0800, Kip Macy wrote:
> 
>>Sparc64 only supports CAS on 4 and 8 byte quantities. The only
>>operation it support on 16 bytes is load.
> 
> 
> The '16' in 'atomic_add_16' is bits.  Few RISC architectures can
> support atomic operations (or primitives to build atomic ops) on
> anything other than their native word side and 32 bits.
> 
> The problem is that SCTP is using a 16-bit refcnt and trying to
> manipulate it atomically.  This is problematic on anything except i386
> and amd64.  The easiest solution seems to be to change refcnt to an
> [u]int - though I'm not sure what other impacts this may have.
> 
Ahh... cool..

I have been wondering if I should not just waste a few
more bytes and move all 16 bit counts that we play
with atomically to 32 bit..

I will do so.. it will make life easier for all concerned :-)

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454C79B3.9080609>