Re: kern/37993: panic: lockmgr: locking against myself (netbsd-4.0_STABLE)

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

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

From: "Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Andrew Doran <ad%netbsd.org@localhost>
Subject: Re: kern/37993: panic: lockmgr: locking against myself 
(netbsd-4.0_STABLE)
Date: Fri, 29 Feb 2008 12:05:56 -0500

 On 28-Feb-08, at 6:15 PM, Andrew Doran wrote:
 >
 >
 >  This one is a design defect in the SA thread implementation and is  
 > fixed in
 >  current with 1:1 threads.
 
 By "design flaw" are you suggesting that a work-around fix is not  
 really possible in netbsd-4?
 
 Is there any way to estimate the potential frequency of this kind of  
 problem?
 
 Could this be manifesting itself in other strange ways too?
 
 
 Could the other pmap problem you mentioned be manifesting itself in  
 other strange ways?
 
 
 Yesterday I finally managed to eliminate one more possible variable  
 as one of the causes of strange problems on my Dell PE2650, or at  
 least I did as far as is possible at the current time.  I updated the  
 BIOS from A09 to A21, which apparently included new firmware for some  
 variants of the Xeon processors I'm running.  (For the record the MS- 
 DOS variant of the flash update program is too big to run on a  
 default DOS-6.22 boot floppy environment, but three CD coasters later  
 I finally discovered that it works fine with DOS-5.00)
 
 However the symptoms all remain.  Two problems that I have not yet  
 reported anywhere include apparent resource starvation during runs of  
 "build.sh", but which are not detected or reported in any other way,  
 including vfork() failures and pipe() failures (Too many open files  
 in system).  The strange messages mentioned in kern/38019 also still  
 appear on the console.
 
 In other words this system running netbsd 4.0_STABLE is nowhere near  
 stable enough for true production use.  I'm going to have to go back  
 to 3.0 or earlier if I'm going to get some fixes into place at  
 customer sites.
 
 -- 
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>