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

From: Frank Kardel <Frank.Kardel@Acrys.COM>
To: Chuck Silvers <chuq@chuq.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/30401: NFS/vnode lockup
Date: Tue, 04 Oct 2005 14:37:42 +0200

 This is a multi-part message in MIME format.
 --------------030801000506050807080306
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Hi Chuck !
 
 Ok - got the lockup again now with: options  UVM_PAGE_TRKOWN.
 
 Want the dump (+netbsd.gdb 8-) ?
 
 Frank
 
 Chuck Silvers wrote:
 
 >On Wed, Aug 24, 2005 at 10:52:32AM +0200, Frank Kardel wrote:
 >  
 >
 >>>ok, I got it.  in this dump several nfsd threads are waiting to get a page lock
 >>>but we don't track who holds such locks by default.  could you trying building
 >>> 
 >>>      
 >>>
 >>good - that pretty much matches my findings from the bug. So it seems I
 >>am not
 >>completely off.
 >>I will build a new kernel tonight (europe). Will the performance impact
 >>be significant ?
 >>    
 >>
 >
 >it should be negligible.
 >
 >
 >  
 >
 >>We might have to wait a bit as there are currently not many people
 >>banging in the system
 >>and it seems be be a race condition leading to that hang.
 >>The sad part is that about 3/4 of a year ago some change made the core dump
 >>go from quite fast (several MB/sec) to dead slow. Now it take around 45
 >>minutes
 >>the get the 2G core dump - no fun to wait, but I must then.
 >>    
 >>
 >
 >hmm, we should fix that too.  the dump-writing code issues many small I/Os
 >(one page each for i386) and that hasn't changed in a long time.  maybe
 >the disk used to have write-back caching enabled and now it doesn't?
 >did you change this setting in your disks or switch disks about that point?
 >
 >you could also try increasing BYTES_PER_DUMP in i386/machdep.c to 65536.
 >
 >(you probably don't want to spend a lot of time testing the performance
 >of the crashdump code, though :-))
 >
 >-Chuck
 >
 >  
 >
 
 
 -- 
 ***********Confidentiality/Limited Liability Statement***************
 
 This email and its contents do not constitute a commitment by Acrys Consult.
 This message is confidential and may contain privileged information. The
 information contained in this communication is intended solely for the use
 of the individual or entity to whom it is addressed and others authorized to
 receive it. It may contain confidential or legally privileged information. If
 you are not the intended recipient you are hereby notified that any disclosure,
 copying, distribution or taking any action in reliance on the contents of this
 information is strictly prohibited and may be unlawful. If you have received
 this communication in error, please notify us immediately by responding to
 this email and then deleting it from your system. As reliability of the
 Internet cannot be guaranteed, we are neither liable for proper nor complete
 transmission of this or any other such communications.
 
 
 --------------030801000506050807080306
 Content-Type: text/x-vcard; charset=utf-8;
  name="Frank.Kardel.vcf"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="Frank.Kardel.vcf"
 
 begin:vcard
 fn:Dr.-Ing. Frank Kardel
 n:Kardel;Frank
 org:Acrys Consult GmbH & Co. KG
 adr;dom:;;Untermainkai 30;Frankfurt am Main;;60329
 email;internet:Frank.Kardel@Acrys.COM
 title:Managing Partner
 tel;work:+49.69.244506-0
 tel;fax:+49.69.244506-50
 note;quoted-printable:Distributed Systems=0D=0A=
 	Architecture (Applications and Distributed Systems)=0D=0A=
 	Unix (Architecture, Scripting, Philosophy, Troubleshooting, Kernel)=0D=0A=
 	Protocol- and Interface-Design (Data Abstractions, Process Handling)=0D=0A=
 	Open Source (Applications, Development)=0D=0A=
 	Robust Production (Reliable Operations)
 x-mozilla-html:FALSE
 url:http://www.acrys.com
 version:2.1
 end:vcard
 
 
 --------------030801000506050807080306--