8.2-PRERELEASE: live deadlock, almost all processes in "pfault" state

Kostik Belousov kostikbel at gmail.com
Sat Jan 8 19:02:36 UTC 2011


On Sat, Jan 08, 2011 at 09:44:57PM +0300, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
> 
>  I've added `transmission' BitTorrent client to my home server and now
> it deadlocks easily (after about 1 hour of intensive download and
> seeding). This server is upgraded from 7.x and last time I've run
> transmission on 7.x system without any problems.
> 
>  I have home partition on geom_raid5 device, so I can not exclude this
> third-party module from experiments.
> 
>  My home filsystem has 32KiB block and all other filesystems (/, /var,
> /tmp, /usr) has standard 16KiB block sizes. I know, that 7.x system
> had (has?) deadlock when 16KiB and 64KiB file systems are mixed up on
> one system, but I never experienced deadlocks with 16KiB and 32KiB
> mixture.
> 
>  All filesystems (Except root) is SU, but no gjournal so SU_J patch
> are in use.
> 
>  Same BitTorrent client on same filesystem, but accessed via NFS (from
> other host), doesn't cause deadlock and works rock-stable for days.
> 
>  I've built kernel with all debug options, waited for deadlock and
> collect all information, mentioned in Developer's Handbook / Debugging
> Deadlocks.
> 
>  Capture from debug session is attached, together with kernel config
> and dmesg from rebooting.
> 
>  As I can easily reproduce this deadlock, I could provide any
> additional information from kernel debugger, if needed.
> 
> System:   FreeBSD 8.2-PRERELEASE
> cvsup:    2011-01-08 00:41:24 MSK (GTM+3) time
> Platform: amd64
There is some weird backtrace at the pid 20, what is g_raid5 ?

If I am guessing right, this creature has a classic deadlock when 
bio processing requires memory allocation. It seems that tid 100079
is sleeping not even due to the free page shortage, but due to address
space exhaustion. As result, read/write requests are stalled.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110108/213322f5/attachment.pgp


More information about the freebsd-stable mailing list