DragonFly BSD
DragonFly bugs List (threaded) for 2010-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Constant crashes on x86_64 with UFS

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 21 Nov 2010 11:38:35 -0800 (PST)

:On the VM that I provide for Justin to make bulk builds I am getting 
:constant panics after I enabled swapcache.
:#15 0xffffffff804fec9c in ffs_realloccg (ip=0xffffffe00096e698, 
:lbprev=<value optimized out>, bpref=8, osize=4096, nsize=5120,
:     cred=0xffffffe000886900, bpp=0xffffffe02e4157f0) at 
:Kernel is
:DragonFly df64pkgbuilder.lan.net 2.9-DEVELOPMENT DragonFly 
:v2.9.0.116.ge61a8-DEVELOPMENT #0: Fri Nov  5 06:38:41 CET 2010 
:root@df64pkgbuilder.lan.net:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64
:Anyone seen this before?

    Hmm.  I haven't seen it before but I can see how it can happen.
    b_bio2 is being used by the vn_cache_strategy code (swapcache).

    UFS/FFS is assuming that *ALL* file bread()s ultimately dive into the
    UFS/FFS stategy code and properly populate b_bio2 for the drill-down
    to the disk device, but if it gets bypassed by the swapcache that will
    not happen.  Instead, b_bio2 is populated by the swapcache and the
    value will have nothing to do with the underlying disk device.

    The bug is actually in swapcache.  The solution is for swapcache to
    set bio_offset to NOOFFSET, but it is a bit of a hack to make it do

    The reason this problem doesn't occur with HAMMER is due to a fluke.
    HAMMER does a test for HAMMER_ZONE_LARGE_DATA before believing a
    cached bio_offset and, of course, that is one huge 64-bit offset and
    swapcache is never able to set an offset that large.

    Please try this patch:

	fetch http://apollo.backplane.com/DFlyMisc/swap03.patch

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]