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?
-Brian