Re: alpha LOCKDEBUG hang

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Feb 21, 2008 at 01:33:41AM +0000, Andrew Doran wrote:

> On Thu, Feb 21, 2008 at 12:02:39AM +0100, Anders Hjalmarsson wrote:
> 
> > As mentined by Michael L. Hitch some weeks ago on port-alpha,
> > Alpha LOCKDEBUG kernels hang early during boot.
> > 
> > I have looked a bit at it, and now I know what the problem is:
> > The kernel main() calls uvm_init() earlyin the boot process.
> > uvm_init in turn calls uvm_page_init(),
> > which on alpha calls VM_MDPAGE_INIT() once per page.
> > Now the bad part: VM_MDPAGE_INIT calls mutex_init, which, after
> > consuming the pre-allocated lockdebug memory in ld_prime,
> > calls lockdebug_more, which calls kmem_zalloc. Unfortunately kmem_init
> > has not been called at that time, and everything gets totally broken.
> > 
> > I worked around it by increasing LD_BATCH_SHIFT in subr_lockdebug.c
> > to 14 which is enough for my 64Meg test machine, and it went multiuser
> > and paniced on login, just as a non-LOCKDEBUG kernel (It is a DEC 3000,
> > and there are some locking problems with the zs tty driver).
> > 
> > So the basic problem is that it tries to make too many mutex_init() before
> > it can allocate memory for lockdebug info for them, and that the lockdebug
> > code happily tries to allocate memory before the allocator is initialized.
> 
> A simple solution would be to use a hash of locks instead of allocating one
> kmutex_t per vm_page. Something similar to this:
> 
>       http://nxr.netbsd.org/source/xref/sys/arch/x86/x86/pmap.c#430
> 
> I'll have a look when I get a chance.

Should be fixed with pmap.c revision 1.232.

Andrew