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