Date: Tue, 15 Apr 2008 17:52:54 -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: <48054DE6.10508@freebsd.org> In-Reply-To: <E42FE735-C13E-44F8-A333-7F103E332C7E@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> <48053E46.4090700@freebsd.org> <E42FE735-C13E-44F8-A333-7F103E332C7E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marcel, >> 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. Can you send the code snippet that you're using to set up the stack ? I can desk-check that, and then use it for my testing so we have the exact same setup. > 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? No. If the primary hash didn't work, the system wouldn't work at all. For a long time there was a bug in the calculation of the secondary hash, but that has been fixed for a while now. Overflow of the secondary hash isn't handled at the moment, but since no-one has hit the panic, it isn't really a problem (yet). later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48054DE6.10508>