> On Fri, Jan 11, 2008 at 03:33:05PM -0800, Marc Tooley wrote:
>
>> I'll double-check the actual filesystem type (v1 or v2.. I think it was
>> newfs -o time -O 2) tonight, as it's paused again.
>
> Looks like you are using softdep - I fixed a problem yesterday that could
> have caused this. Can you please update your kernel sources and try again?

You are correct; good guess.

/dev/wd0a on / type ffs (local)
/dev/wd0e on /usr type ffs (soft dependencies, local)
/dev/wd0f on /v type ffs (soft dependencies, local)
/dev/raid0e on /v2 type ffs (soft dependencies, local)
kernfs on /kern type kernfs (local)

... I am using softdep. And I'm using ffsv2:

history | grep -i newfs
  7973  newfs -O 2 -o time /dev/raid0e

I have rsync'd and updated my sources as of a change you made:

/src/sys/ufs/ffs/ffs_softdep.c:1.106

"Initialize caches at IPL_SOFTBIO (not IPL_NONE) so that we are 
allocating from kmem_map."

.. I'm hoping that's the fix you're talking about. I've built a fresh 
kernel, installed it, and after monitoring a build.sh for 
approximately ten minutes, found it doing the same thing. This time it 
appeared to be triggered by my execution in another terminal:

sync;sync;sync

Now it's been frozen for about five minutes. I wouldn't think a 2GB 
mem machine would generate that kind of complete pause.

Breaking into the kernel debugger nets me..

A bunch of active processes that appear stuck in vm_map again. I had 
to reboot the machine. I stripped out softdep from the mount options 
in fstab and am trying again...

... and getting much, much further. Lots of disk activity, lots of 
processes, I've restarted all the standard system daemons again, 
everything.

Well, at least I have a working system again! Thanks for the hint. If 
you need more testing, or if it looks like I managed to build a kernel 
without your fix in it, please let me know.

-Marc