From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 18:55:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5938106566B; Mon, 10 Aug 2009 18:55:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 34F238FC21; Mon, 10 Aug 2009 18:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CF56541C713; Mon, 10 Aug 2009 20:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id dan2118ycF3Z; Mon, 10 Aug 2009 20:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id F1E1841C712; Mon, 10 Aug 2009 20:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 82DED4448EC; Mon, 10 Aug 2009 18:50:41 +0000 (UTC) Date: Mon, 10 Aug 2009 18:50:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: <20090810181027.E93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:55:08 -0000 On Mon, 10 Aug 2009, Robert Watson wrote: > > On Mon, 10 Aug 2009, Julian Elischer wrote: > >>> One possible workaround would be to force the __start_ symbol and the >>> section to be equally aligned and thus on the same address using linker >>> scripts. The drawbacks are that we need to touch the fragile linker >>> scripts for each of the sections we add and for all architectures >>> individually. As the enforcement of alignment would be at a different >>> place to the actual set creation, putting the alignment in might be easily >>> forgotten. >> >> personally I'd see if there is a way to align the section on a page >> boundary.. > > I'm not sure it matters for the master copy, but I believe some (if not all) > architecture MD parts already allocate the per-CPU data areas as > page-aligned, and we extend the master copy out to a page boundary. That > said, it would be worth checking on a run-time kernel to make sure it works > out that way in practice. db> show dpcpu_off dpcpu_off[ 0] = 0x42b100 (+ DPCPU_START = 0xffffffff81002000: aligned) dpcpu_off[ 1] = 0xffffff807f44e100 (+ DPCPU_START = 0xffffff8000025000: aligned) dpcpu_off[ 2] = 0xffffff807f455100 (+ DPCPU_START = 0xffffff800002c000: aligned) dpcpu_off[ 3] = 0xffffff807f45c100 (+ DPCPU_START = 0xffffff8000033000: aligned) dpcpu_off[ 4] = 0xffffff807f463100 (+ DPCPU_START = 0xffffff800003a000: aligned) dpcpu_off[ 5] = 0xffffff807f46a100 (+ DPCPU_START = 0xffffff8000041000: aligned) dpcpu_off[ 6] = 0xffffff807f471100 (+ DPCPU_START = 0xffffff8000048000: aligned) dpcpu_off[ 7] = 0xffffff807f478100 (+ DPCPU_START = 0xffffff800004f000: aligned) Note: you don't have that ddb command. I added that last week to my kernel for debugging. But that's nothing I wouldn't have expected as we are using kmem_alloc() for dpcpu. The more intersting thing would be to see what malloc does for vnet, even if we are memeory multiple of page sizes. An updated show vnets gives: db> show vnets vnet = 0xffffff0005c4ab00 ... vnet_data_mem = 0xffffff8000b00000 vnet_data_base = 0xffffff807ff81f80 vnet = 0xffffff0005c278c0 ... vnet_data_mem = 0xffffff8000ab8000 vnet_data_base = 0xffffff807ff39f80 vnet = 0xffffff0001633dc0 ... vnet_data_mem = 0xffffff8000226000 vnet_data_base = 0xffffff807f6a7f80 So looking at vnet_data_mem this looks good as well:) /bz -- Bjoern A. Zeeb The greatest risk is not taking one.