Re: Constant crashes on x86_64 with UFS

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 
:/usr/src/sys/vfs/ufs/ffs_alloc.c:230
:...
:
: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?
:
:Jan

    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
    that.

    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

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>