kern/40538: LOCKDEBUG kernel "spin out" on NetBSD/amd64

[mjf%phlog.console-pimps.org@localhost]

>Number:         40538
>Category:       kern
>Synopsis:       LOCKDEBUG panic _kernel_lock: spinout
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 02 16:05:00 +0000 2009
>Originator:     Matt Fleming
>Release:        NetBSD 5.99.7
>Organization:
        
>Environment:
        
        
System: NetBSD phlog.console-pimps.org 5.99.7 NetBSD 5.99.7 (GENERIC) #0: Sat 
Jan 31 20:38:29 GMT 2009 
mjf%phlog.console-pimps.org@localhost:/home/mjf/src/NetBSD/clean/amd64/obj/sys/arch/amd64/compile/GENERIC
 amd64
Architecture: x86_64
Machine: amd64
>Description:
        Booting a quad-core AMD64 machine with LOCKDEBUG turned on causes
        the machine to panic during autoconf. The panic message reads,

        "Kernel lock error: _kernel_lock: spinout"

        The lock is held by CPU 1: lwp 0xffff8000559667e0 (config)
        Last held by CPU 0: lwp 0xffff800055966bc0"

        exclusive holds: 1      (0 shared)
        exclusive wanted: 3     (0 shared)

        CPU 0 backtrace:
        uvm_pglist_add + 0x65
        uvm_pglistalloc + 0x64b
        _bus_dmamem_alloc_range + 0x4c
        _bus_dmamem_alloc + 0x49
        _bus_dma_alloc_bouncebuf + 0x6a
        _bus_dmamap_create + 0x182
        usb_block_allocmem + 0x1bf
        usb_allocmem + 0x9f
        ohci_allocmem + 0x2d
        usbd_transfer + 0x7d
        usbd_do_request_flags_pipe + 0xcb
        usbd_do_request_flags + 0x25
        usbd_get_desc + 0x34
        usbd_new_device + 0x181
        usbd_doattach + 0xcc
        config_interrupts_thread + 0x2d

        CPU 1 backtrace:
        breakpoint + 0x5
        panic + 0x249
        lockdebug_abort1 + 0xd3
        _kernel_lock + 0x171

        CPU 2 backtrace:
        x86_pause + 0x2
        _kernel_lock + 0x12d

        CPU 3 backtrace:
        x86_pause + 0x2

>How-To-Repeat:
        
>Fix:
        Funnily enough, disabling the azalia(4) device seems to avoid this
        panic. Though quite how that driver causes this bug to appear I'm
        not sure but the panic does appear after the device has been probed.

>Unformatted: