Date: Tue, 15 Apr 2008 16:46:14 -0700 From: Peter Grehan <grehan@freebsd.org> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] Message-ID: <48053E46.4090700@freebsd.org> In-Reply-To: <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org> <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com>
index | next in thread | previous in thread | raw e-mail
Hi Marcel, > the not mapping means that the CPU couldn't find the > translation in its TLB nor in the hash table. The exception code treats > this as a kernel stack overflow. Are you sure it isn't a genuine stack overflow ? You may be able to tell by bumping the size of tmpstk on a non-kstack0 boot and see how far up it's been used. The stack mappings are put into the hash table, and a panic will be issues if it can't be placed into the primary or secondary buckets. >> Stack *overflow* exception handling may be busted, but that is a >> challenging problem to get right. > > The logic currently assumes that there's never a DSI trap for the kernel > stack. This simply is an invalid assumption. As above, it is, since wired mappings are never kicked out of their hash bucket. >>> Also, with process address space limited to 2G >> >> Where's that limitation ? If so, that's a bug: it should be 4G. > > vmparam.h: #define VM_MAXUSER_ADDRESS 0x7ffff000 Ah yes, that's an easy one to fix :) later, Peter.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48053E46.4090700>