OK.  I can send all of those things.  If it happens again, I should get a 
dump which will have a stack trace.  
-thanks
-Brian
On Feb 9, 11:33am, Greg Oster wrote:
} Subject: Re: manifestations of Kern/11029 in NetBSD/i386 1.5R
} Brian Buhrow writes:
} > 	Hello folks.  I've just put up a new kernel on our 
} > machine with the monster raid of IDE disks.  This is with sources sucked
} > down yesterday.  If I run an fsck -n on the filesystem riding atop the raid
} > 5 system, I can freeze the kernel in the uvm_wait() routine in
} > uvm_pdaemon.c.  Unfortunately, I cannot do a lot of testing on this system,
} > as it takes an inordinate amount of time to parity check this raid after a
} > crash.  I hope someone can use this report to try and get to the bottom
} > of this bug, which seems fairly serious.  I'll attempt to get some stack
} > traces if it happens again, but I'm going to remove the offending commands
} > from the daily routine since I actually need to get work done with this
} > machine.  I have SOFTDEP enabled, UBC turned on, and all of the ffs
} > optimizations enabled, if this helps.  I suspect the problem is an
} > interaction between the fsck and the raid driver itself.  The machine has
} > 256MB of memory installed and a raid 5 disk array of 15 75GB EIDE disks
} > configured in the array.  Any ideas on how to eliminate this deadlock
} > condition?
} 
} Please supply:
} 1) cat /var/run/dmesg.boot
} 2) your raid config file
} 3) the disklabel from the raid set.
} 4) the disklabel from one of the components (assuming they are 
} all labelled the same way)
} 
} But without any sort of a stack trace (or a way to reproduce the problem)
} it's going to be pretty hard to figure out what's going wrong... 
} 
} Later...
} 
} Greg Oster
} 
} 
>-- End of excerpt from Greg Oster