Re: alpha LOCKDEBUG hang

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

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.

Thanks,
Andrew