Date: Mon, 10 Aug 2009 18:50:41 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: reproducible panic in netisr Message-ID: <20090810181027.E93661@maildrop.int.zabbadoz.net> In-Reply-To: <alpine.BSF.2.00.0908101859260.36842@fledge.watson.org> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <alpine.BSF.2.00.0908060011490.59996@fledge.watson.org> <alpine.BSF.2.00.0908060834120.21318@thebighonker.lerctr.org> <alpine.BSF.2.00.0908061508520.62916@fledge.watson.org> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> <alpine.BSF.2.00.0908101859260.36842@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090810181027.E93661>