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