kernel stacks [eas: Re: G5 Bridge-mode MMU]

Peter Grehan grehan at freebsd.org
Tue Apr 15 23:47:21 UTC 2008


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.




More information about the freebsd-ppc mailing list