From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 4 03:26:22 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 6CA9C1065670; Thu, 4 Jun 2009 03:26:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 119BE8FC15; Thu, 4 Jun 2009 03:26:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=kmbRGkKw9GitWXfA3Z7SogtG+eNtymOIW8v3Oow0N7GISobsQhJbjNdHQaZ/2UXzGHWnwhTMMjAUtpk2ztKC0hZnz+HGoOJyd0WhjdTJfNPtZqd2PeCjiuQ/3T+zh0klpWeEPe3f2jHAEy21smZhUvDEF0pcNTNexQBicF0PQVo=; Received: from phoenix.codelabs.ru (ppp85-141-161-25.pppoe.mtu-net.ru [85.141.161.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MC3au-0000Ch-Rq; Thu, 04 Jun 2009 07:26:21 +0400 Date: Thu, 4 Jun 2009 07:26:17 +0400 From: Eygene Ryabinkin To: Marius Strobl Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603194453.GA43137@alchemy.franken.de> Sender: rea-fbsd@codelabs.ru Cc: kmacy@freebsd.org, sparc64@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , khb@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:26:23 -0000 Marius, good day. First, thanks for committing the fix. Wed, Jun 03, 2009 at 09:44:53PM +0200, Marius Strobl wrote: > On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > 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. > > If it actually becomes negative the build should break again, > which IMO is sufficient protection. Yes, "protection" is here. But it will break the build again and that's a bit uncomfortable. > > The attached patch should fix this (although I have no sun4v to test > > on, so take it with a grain of salt). > > I think this is overengineered, especially if not also > adjusting the padding for other macros which may change the > size of both MD and MI parts of struct pcpu. Hmm, don't fully understand about "other macros". Could you, please, provide an example? > > 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? > > It's just not taken into account but AFAICT also dead code. Yes, seems like so. John, may be we can eliminate the only reference to KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be unused (grep'ped -CURRENT sources). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ #