Date: Thu, 10 Jul 2008 08:39:49 -0700 From: Peter Grehan <grehan@freebsd.org> To: Marek Woloszyn <Marek.Woloszyn@comp-css.pl> Cc: freebsd-ppc@freebsd.org Subject: Re: FreeBSD on MPC8349 (e300 core) Message-ID: <48762D45.7050405@freebsd.org> In-Reply-To: <4884777a784ee096.4875f596@comp.waw.pl> References: <4884777a784ee096.4875f596@comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Marek, > the PTE usage distribution in PTEG table is still non-uniform. For > normal PTEG table size the secondary hash bucket hits PTEGs that are > already filled by the primary hash bucket and then we get a panic. The G3/G4 pmap code has been stable for a while now. The fact that it took a number of years to find the pteg secondary-hash index issue indicated that the hash was working well and spreading entries well enough that the primary buckets were rarely overflowing. One avenue to look into is to make sure your TLB miss handler is functionally correct. If it's generating an incorrect value (or even a poor hash), that may result in entries not being spread well enough. > It's a panic. I've attached three example backtraces from sh, tail > and pkill. They have all appeared during the boot process. We have > many more core dumps from various system tools, but they are all > similar to these. Suddenly a pointer points to 0x0 or an index in a > table is invalid. Maybe something in the kernel overwrites user pages > or maps a wrong page for a process? One way to debug these type of problems is to put some code in the kernel's trap handler to validate the virt/phys translation that caused the problem is the same as that described in the faulting process's vm data structures. later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48762D45.7050405>