FreeBSD on MPC8349 (e300 core)

[Peter Grehan]

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.