Re: 8.2-PRERELEASE: live deadlock,

Hello, Kostik.
You wrote 8 =FF=ED=E2=E0=F0=FF 2011 =E3., 22:02:32:

> There is some weird backtrace at the pid 20, what is g_raid5 ?
  It is geom_raid5, with two threads -- working one and one for
 processing finished bios.

> If I am guessing right, this creature has a classic deadlock when=20
> bio processing requires memory allocation. It seems that tid 100079
  tid 100079 sleep in waiting for some data in queue.

> is sleeping not even due to the free page shortage, but due to address
> space exhaustion. As result, read/write requests are stalled.
  tid 100078 sleep in malloc(). But geom_raid5 never ever allocate
 more than 128MiB of memory and it is 64bit system with huge amount of
 kmem_size/kmem_size_max...

  How could I explore allocation (like vmstat -m) from kdb to be sure,
it doesn't allocated more?

  And, if it is "classic deadlock" is here any "classical" solution to
it?

  Really, I'm maintainer of geom_raid5 now, so I need fix this
deadlock, but I don't really understand, why does it occur? I've
hit panic with "kernel memory exhausted" symptoms when module allocate
too much, but not deadlock :(

> Then, syncer is blocked waiting for some physical buffer (look at tid
> 100075), owning the vnode lock. Other processes also wait for the
> locked buffers, etc.

> So my belief is that this is plain driver (g_raid5, whatever is it)
> i/o loss. Try the same load without it.
  I can not, because all data is on this GEOM :)

--=20
// Black Lion AKA Lev Serebryakov <lev@serebryakov.spb.ru>

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"