Project

General

Profile

Actions
Copy link

Bug #1916

open

Constant crashes on x86_64 with UFS

Added by lentferj almost 15 years ago. Updated almost 15 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
6.4
Start date:
Due date:
% Done:

0%

Estimated time:

Description

On the VM that I provide for Justin to make bulk builds I am getting
constant panics after I enabled swapcache.

#14 0xffffffff8035d01f in panic (fmt=0xffffffff80685d46 "ffs_realloccg:
bad blockno") at /usr/src/sys/kern/kern_shutdown.c:785
#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
#16 0xffffffff804ff338 in ffs_balloc (ap=0xffffffe02e415838) at
/usr/src/sys/vfs/ufs/ffs_balloc.c:183
#17 0xffffffff803cece0 in vop_balloc (ops=0xffffffe007fcea80,
vp=0xffffffe02e58b400, startoffset=<value optimized out>, size=<value
optimized out>,
cred=<value optimized out>, flags=<value optimized out>,
bpp=0xffffffe02e415918) at /usr/src/sys/kern/vfs_vopops.c:936
#18 0xffffffff8050abba in ffs_write (ap=0xffffffe02e415958) at
/usr/src/sys/vfs/ufs/ufs_readwrite.c:348
#19 0xffffffff803cf738 in vop_write (ops=0xffffffe007fcea80,
vp=0xffffffe02e58b400, uio=<value optimized out>, ioflag=<value
optimized out>,
cred=<value optimized out>) at /usr/src/sys/kern/vfs_vopops.c:427
#20 0xffffffff803cdb7b in vn_write (fp=0xffffffe00ab7d4a8,
uio=0xffffffe02e415ad8, cred=0xffffffe000886900, flags=<value optimized
out>)
at /usr/src/sys/kern/vfs_vnops.c:724
#21 0xffffffff803871ef in dofilewrite (fd=6, auio=0xffffffe02e415ad8,
flags=0, res=0xffffffe02e415b48) at /usr/src/sys/sys/file2.h:72

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
:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

Anyone seen this before?

Jan

Actions
Copy link
 #1

Updated by dillon almost 15 years ago

: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
::/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 
                    &lt;&gt;
Actions
Copy link

Also available in: Atom PDF