[head tinderbox] failure on sparc64/sun4v
rwatson at FreeBSD.org
Wed Jun 3 20:06:08 UTC 2009
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:
>> 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)
>> #define PCPU_MD_FIELDS_PAD 3
>> 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
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
University of Cambridge
More information about the freebsd-sparc64