Re: kern/38375: LOCKDEBUG panic with 4.99.58 SMP kernels

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

The following reply was made to PR kern/38375; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/38375: LOCKDEBUG panic with 4.99.58 SMP kernels
Date: Sun, 6 Apr 2008 13:43:38 +0100

 On Sun, Apr 06, 2008 at 11:40:00AM +0000, he%NetBSD.org@localhost wrote:
 
 > login: Kernel lock error: _kernel_unlock: assertion failed: nlocks <= 0
 > 
 > lock address : 0x00000000018d3a00 type     :               spin
 > shared holds :                  0 exclusive:                  1
 > shares wanted:                  0 exclusive:                  0
 > current cpu  :                  3 last held:                  2
 > current lwp  : 0x0000000010d57180 last held: 0x000000000f9ea3a0
 > last locked  : 0x000000000132f3d0 unlocked : 0x000000000143e380
 > initialized  : 0x00000000012b1800
 > curcpu holds :                  0 wanted by: 000000000000000000
 > 
 > panic: LOCKDEBUG
 > Stopped in pid 465.1 (systat) at        netbsd:cpu_Debugger+0x4:        nop
 > db{3}: trace
 > lockdebug_abort1(18eb928, 18eb928, 151c730, 1686530, 1, 1) at 
 > netbsd:lockdebug_abort1+0x7c
 > lockdebug_abort(18d3a00, 181b280, 151c730, 1686530, 1f4, 10ca6a90) at 
 > netbsd:lockdebug_abort+0x7c
 > _kernel_unlock(1, 0, 0, fffffff, 18d3800, 10d57180) at 
 > netbsd:_kernel_unlock+0x78
 > cdev_read(0, 10e27bf0, 0, badcafe, badcafe, badcafe) at netbsd:cdev_read+0x60
 > spec_read(10e27a48, 1346228, 151cc00, 10d57180, 10b1d9e0, badcafe) at 
 > netbsd:spec_read+0x1e0
 > ufsspec_read(10e27a48, 10001, badcafe, 0, 0, 0) at netbsd:ufsspec_read+0x48
 > VOP_READ(10b1d9e0, 10e27bf0, 0, 10f9d0c0, b8, 17) at netbsd:VOP_READ+0x6c
 > vn_read(10fa0700, 10fa0700, 10e27bf0, 10f9d0c0, 1, 23e400) at 
 > netbsd:vn_read+0x88
 > dofileread(16, 10fa0700, 262000, 10000, 0, 1) at netbsd:dofileread+0x60
 > sys_read(0, 10e27dc0, 10e27e00, 10e24000, 9600, 798) at netbsd:sys_read+0x60
 > syscall_plain(10e27ed0, 3, 40d39594, 44e, 40d39594, 800) at 
 > netbsd:syscall_plain+0x12c
 > ?(0, 262000, 10000, badcafe, badcafe, badcafe) at 0x10093e4
 > db{3}: x/i 0x00000000012b1800
 > netbsd:main+0x20:       call            netbsd:kernel_lock_init
 
 It appears that cdev_read() is unlocking after calling into a device driver.
 If the first argument is to be believed (0) then it's reading from the
 console device, so it makes sense that it would be acquiring/releasing the
 kernel_lock.
 
 > db{3}: x/i 0x000000000132f3d0
 > netbsd:do_sys_sendmsg+0x2f0:    call            netbsd:_kernel_lock
 > db{3}: x/i 0x000000000143e380
 > netbsd:intr_biglock_wrapper+0x20:       call            netbsd:_kernel_unlock
 
 The last locked / unlocked addresses shown here don't pair up in any
 meaningful way, which is very unusual. Is the sparc console driver
 playing any tricks with kernel_lock? I'd doubt it...
 
 Andrew