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

From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: ad@netbsd.org
Cc: mrg@eterna.com.au, gnats-bugs@NetBSD.org
Subject: Re: PR/32962
Date: Fri,  3 Nov 2006 18:40:25 +0900 (JST)

 > Hi,
 > 
 > On Fri, Nov 03, 2006 at 01:06:40AM +0900, YAMAMOTO Takashi wrote:
 > 
 > > > --- kern/kern_lwp.c	1 Nov 2006 10:17:58 -0000	1.48
 > > > +++ kern/kern_lwp.c	1 Nov 2006 19:06:26 -0000
 > > 
 > > i don't think this makes differences.
 > 
 > The only things I would count on the sched_lock to protect reliably at the
 > moment are the run queues. We need the kernel_lock to do sleep or wakeup.
 
 i thought wakeup was safe without kernel_lock.
 
 > > > --- kern/kern_synch.c	1 Nov 2006 10:17:58 -0000	1.171
 > > > +++ kern/kern_synch.c	1 Nov 2006 19:06:29 -0000
 > >
 > > why do you want to keep spl at splsched?
 > 
 > At this point, the LWP is on a sleep queue but is in the LSONPROC state.
 > Lowering the SPL may allow device interrupts in, which may cause wakeup() to
 > be called. If the wakeup() happens against the same sleep queue, this will
 > trigger a DIAGNOSTIC asssertion because the LWP is on the queue, but is
 > marked as ONPROC. We need the kernel lock held to stop other CPUs from
 > calling wakeup() and triggering the same problem in the MP case.
 
 isn't it better to fix the assertion instead?
 
 > > [mi_switch]
 > > 
 > > is it necessary?
 > > the code in question was out of kernel_lock even before the recent changes.
 > 
 > Definitely. There is a substantial amount of work on the newlock2 branch
 > aimed at addressing the above problems. 
 
 ok, thanks for explainations.
 
 YAMAMOTO Takashi