Date: Tue, 15 Apr 2008 17:42:40 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: grehan@freebsd.org Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] Message-ID: <E42FE735-C13E-44F8-A333-7F103E332C7E@mac.com> In-Reply-To: <48053E46.4090700@freebsd.org> 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> <48053E46.4090700@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 15, 2008, at 4:46 PM, Peter Grehan wrote: > 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 ? Positive. The panic happens after 4KB of stack has been used. > 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 backtrace also shows that. From inner-most to out-most function in the backtrace the stack pointers are roughly 4KB apart. > 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. Hmm, It looks like you're right. Odd... Is it possible that the hash computation we use is not one used by the CPU so that we end up adding PTE where the CPU isn't looking? I'll have to dig deeper, I guess... -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E42FE735-C13E-44F8-A333-7F103E332C7E>