Re: ext2fs panic with Dfly 1.5.2

[Csaba Henk <csaba.henk@xxxxxxx>]

On 2006-04-04, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
>     All right.  I have no idea whether EXT2 still works after all the surgery
>     I just did, but its worth a try.

It keeps ending up in "getblk: vnode %p has no object!" panics. For some
reason, many of the "vinitvmio(vp);" calls in ufs have been omitted from
ext2.

Eg., this one:

#11 0xc02ad1c2 in panic (fmt=0xc053de24 "getblk: vnode %p has no object!") at /usr/dispatch/src/sys/kern/kern_shutdown.c:677
#12 0xc02e65dd in getblk (vp=0xd4a019b0, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_bio.c:2157
#13 0xc02e41c7 in bread (vp=0xd4a019b0, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_bio.c:599
#14 0xd4a2ff7d in ext2_blkatoff (vp=0xd4a019b0, offset=0, res=0x0, bpp=0xd4ae3958)
    at /usr/dispatch/src/sys/vfs/gnu/ext2fs/ext2_subr.c:84
#15 0xd4a2ee6a in ext2_lookup (ap=0xc050f8fc) at /usr/dispatch/src/sys/vfs/gnu/ext2fs/ext2_lookup.c:373
#16 0xc03006b6 in vop_old_lookup (ops=0xc050f8fc, dvp=0x12, vpp=0x12, cnp=0x12) at /usr/dispatch/src/sys/kern/vfs_vopops.c:335
#17 0xc02ed604 in vop_compat_nresolve (ap=0xd4ae3a08) at /usr/dispatch/src/sys/kern/vfs_default.c:230
#18 0xc02ed4f6 in vop_defaultop (ap=0xc050f8fc) at /usr/dispatch/src/sys/kern/vfs_default.c:155
#19 0xc030120c in vop_nresolve (ops=0xc050f8fc, ncp=0x12, cred=0x12) at /usr/dispatch/src/sys/kern/vfs_vopops.c:1181
#20 0xc02ea99a in cache_resolve (ncp=0xd4a55298, cred=0xd25bbb98) at /usr/dispatch/src/sys/kern/vfs_cache.c:2017
#21 0xc02f32b9 in nlookup (nd=0xd4ae3bb4) at /usr/dispatch/src/sys/kern/vfs_nlookup.c:409
#22 0xc02ff518 in vn_open (nd=0xd4ae3bb4, fp=0xc16c5080, fmode=1, cmode=0) at /usr/dispatch/src/sys/kern/vfs_vnops.c:159
#23 0xc02fb993 in kern_open (nd=0xd4ae3bb4, oflags=26571, mode=0, res=0xd4ae3c50)
    at /usr/dispatch/src/sys/kern/vfs_syscalls.c:1303
#24 0xc02fbcad in open (uap=0xd4ae3c24) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:1435
#25 0xc04b6607 in syscall2 (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 4, tf_esi = 673542944, tf_ebp = -1077944936, tf_isp = -726778508, tf_ebx = 672732180, tf_edx = 0, tf_ecx = 0, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 673061084, tf_cs = 31, tf_eflags = 582, tf_esp = -1077944964, tf_ss = 47}) at /usr/dispatch/src/sys/i386/i386/trap.c:1420
#26 0xc04a29ca in Xint0x80_syscall () at /usr/dispatch/src/sys/i386/i386/exception.s:852

could be fixed by bringing over the "vinitvmio(vdp);" line from ufs_lookup().
But then I get the same type of panic from another place.

The whole picture is: 

 - ufs has vinitvmio() in the following functions:
    ufs_open ufs_mkdir ufs_symlink ufs_readlink ufs_readdir (ufs_vnops.c)
    ufs_lookup ufs_dirempty (ufs_lookup.c)
    ffs_truncate (ffs_inode.c)

 - ext2fs has vinitvmio() in the following functions:
    ext2_open ext2_readlink (ext2_vnops.c)

  * * *

Another issue is that e2fsck is broken -- it just complains:

# e2fsck /dev/ad0s8
e2fsck 1.32 (09-Nov-2002)
The filesystem size (according to the superblock) is 1280026 blocks
The physical size of the device is 0 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? 

and then the kernel spits out a bunch of

dscheck(#ad/0x90002): b_bcount 1 is not on a sector boundary (ssize 512)

messages. (Although it's not a new issue -- I also see this with a pre
BUF/BIO patch kernel.)

Regards,
Csaba