From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 3 20:06:06 2009 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1F610656C9; Wed, 3 Jun 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 22A4F8FC0A; Wed, 3 Jun 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B368F46B4C; Wed, 3 Jun 2009 16:06:05 -0400 (EDT) Date: Wed, 3 Jun 2009 21:06:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eygene Ryabinkin In-Reply-To: Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, marius@freebsd.org, sparc64@freebsd.org, FreeBSD Tinderbox , kmacy@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 20:06:08 -0000 On Wed, 3 Jun 2009, Eygene Ryabinkin wrote: >> This seems to be related to the recent NETISR changes, namely, the >> addition of the pc_netisr member to the struct pcpu: >> http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u >> >> I am not sure how large (void *) is on sun4v, but it seems to me >> that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > >> should be compensated for this change. Something like >> ----- >> #ifdef KTR >> #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) >> #else >> #define PCPU_MD_FIELDS_PAD 3 >> #endif >> ----- >> though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just > now we won't be able to reach this with the current definition for > PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative > and that's bad. > > The attached patch should fix this (although I have no sun4v to test on, so > take it with a grain of salt). > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts of > 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never > compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU > constant for sun4v (inexisting or defined everytime) or I am missing > something? Is there a reason not just to use __aligned(64) or the like on the first entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes from causing similar discomfort for the MD pcpu parts? Also, do we know why these alignment/sizing requirements exist for struct pcpu on sun4v but not other platforms? If this is about packing pcpu structures into properly aligned cache lines, again __aligned() might be the right approach to take... Robert N M Watson Computer Laboratory University of Cambridge