On Mon, Oct 15, 2007 at 10:26:29AM +0200, Henrik Brix Andersen wrote:
quoted text
> On Mon, Oct 08, 2007 at 07:18:10PM +0200, Claus Guttesen wrote:
> > > I was able to reproduce the panic by rsyncing big files and trying
> > > bonnie++ test suggested in this thread.
> > >
> > > Can you guys retry with this patch:
> > >
> > >         http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch
> > >
> > > It's a hack, yes, but allows to mitigate the problem quite well. I'm
> > > looking for a solution that can be used for 7.0 before we find a bett=
er
quoted text
> > > fix.
> >=20
> > Congrats Pawel! You made my server survive my rsync of 90 GB. :-)
> >=20
> > This is on same src as the one that required a reboot except for your
> > patch. So this fix does 'alleviate kmem_map too small' in my case.
>=20
> While we have come across the 'kmem_map too small' panics in the past,
> these are now solved - but our rsync processes still hang at random,
> just spinning the CPU. This is when running multiple rsyncs to the
> same zpool:
>=20
>   http://www.brixandersen.dk/tmp/zfs-rsync-debug.1.txt

This looks like VFS deadlock between process 42575 and 42585. You
debugging is really nice, but unfortunately there is no backtrace of
process 42575, so we don't know where and why it's stuck...

Can you next time take 'show lockedvnods', 'show alllocks' (as you did
this time), but also 'alltrace'?

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!