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

From: Sean Davis <dive-nb@endersgame.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/32266: deadlocks with 3.99.13/i386
Date: Thu, 8 Dec 2005 21:08:38 -0500

 On Thu, Dec 08, 2005 at 12:40:02AM +0000, Martin Husemann wrote:
 > The following reply was made to PR kern/32266; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 > 	netbsd-bugs@netbsd.org
 > Subject: Re: kern/32266: deadlocks with 3.99.13/i386
 > Date: Thu, 8 Dec 2005 01:35:22 +0100
 > 
 >  Could you try the same on a kernel with options LOCKDEBUG, DEBUG and DIAGNOSTIC
 >  defined?
 >  
 >  Martin
 >  
 
 Okay, tried it. The following message is scrolled on console non-stop, and
 the machine is totally unusable:
 
 pool_get(PR_WAITOK) with held simple_lock 0xcc6146d8 CPU 0 ../../../../kern/kern_lock.c:561
 
 Beyond that, I have no new information to report, but that seems signifigant,
 as these problems never happened until I went from 3.99.10 -> 3.99.13.
 
 I'm tempted to suspect that this is an issue regarding specific types of
 access (such as CVS) across drives on different controllers, as the
 repository resides on a wd1a on the onboard VT8237 SATA controller, and the
 build drive is on wd3a on a satalink card. cvs is the only app that's doing
 this, and so far (I haven't tested it very far, since I've been busy with
 work) cvs update at least seems to work fine when updating a source tree on
 the same controller (wd0a, /usr/src, which is on the same VT8237)
 
 -Sean