DragonFlyBSD

On 2006-03-29, Csaba Henk <csaba.henk@creo.hu> wrote:

I got the following panic after mounting an ext2 partition,
when doing an "ls" on the mount point.

Duh, I just see that ext2fs is a module, and the backtrace could be
more useful with the respective symbols inserted... So,

Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc04a0f1a
stack pointer = 0x10:0xcaf416b4
frame pointer = 0x10:0xcaf416bc
code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 12 (ls)
current thread = pri 6

panic: from debugger
Uptime: 1m16s

#10 0xc04a1e9f in calltrap () at /usr/dispatch/src/sys/i386/i386/exception.s:774
#11 0xc04150c4 in ufs_bmap (ap=0xcaf418f8) at /usr/dispatch/src/sys/vfs/ufs/ufs_bmap.c:96
#12 0xc041bba2 in ufs_vnoperate (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:2413
#13 0xc030054a in vop_bmap (ops=0xc0bfae84, vp=0x0, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_vopops.c:859
#14 0xc041b31e in ufs_strategy (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:1807
#15 0xc041bba2 in ufs_vnoperate (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:2413
#16 0xc0300580 in vop_strategy (ops=0x0, vp=0xc0ba3908, bio=0xc0bfae30) at /usr/dispatch/src/sys/kern/vfs_vopops.c:874
#17 0xc02e7304 in vn_strategy (vp=0xc0ba3908, bio=0xc0bfae84) at /usr/dispatch/src/sys/kern/vfs_bio.c:2779
#18 0xc02e403c in bread (vp=0xc0ba3908, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_bio.c:608
#19 0xcaf62914 in ext2_read (ap=0xcaf41a7c) at ext2_readwrite.c:109
#20 0xc03000d0 in vop_read (ops=0x0, vp=0x0, uio=0x0, ioflag=0, cred=0x0) at /usr/dispatch/src/sys/kern/vfs_vopops.c:506
#21 0xcaf5ef9e in ext2_readdir (ap=0xcaf41b30) at /usr/dispatch/src/sys/vfs/gnu/ext2fs/ext2_lookup.c:178
#22 0xc0300406 in vop_readdir (ops=0x0, vp=0x0, uio=0x0, cred=0x0, eofflag=0x0, ncookies=0x0, cookies=0x0)
at /usr/dispatch/src/sys/kern/vfs_vopops.c:759
#23 0xc02fd7ba in kern_getdirentries (fd=0, buf=0x280b1000 <Address 0x280b1000 out of bounds>, count=4096, basep=0xcaf41be8, res=0x0,
direction=UIO_USERSPACE) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:2904
#24 0xc02fd8de in getdirentries (uap=0xcaf41c24) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:2946
#25 0xc04b5b67 in syscall2 (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1268, tf_esi = 671793216, tf_ebp = -1077939480, tf_isp = -889971340, tf_ebx = 0, tf_edx = 671793216, tf_ecx = 671793152, tf_eax = 479, tf_trapno = 12, tf_err = 2, tf_eip = 134824764, tf_cs = 31, tf_eflags = 582, tf_esp = -1077939508, tf_ss = 47}) at /usr/dispatch/src/sys/i386/i386/trap.c:1420
#26 0xc04a1f2a in Xint0x80_syscall () at /usr/dispatch/src/sys/i386/i386/exception.s:852

Regards,
Csaba

:On 2006-03-29, Csaba Henk <csaba.henk@creo.hu> wrote:
:> I got the following panic after mounting an ext2 partition,
:> when doing an "ls" on the mount point.
:
:Duh, I just see that ext2fs is a module, and the backtrace could be
:more useful with the respective symbols inserted... So,

Hmm.  Is that ext2fs partition small enough that you can put the
    raw disk image up somewhere?  It's probably something simple related
    to the BUF/BIO 64 bit offset conversion work, but I don't think I
    can track it down from that backtrace.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

^^^

^^^

^^^

^^^

^^

why on earth does ext2_read cascade to ufs_*? is that the operation on
the /dev vnode which is on an ufs? but then it should be specfs, or
not? i'm puzzled. if this isn't fishy, somebody gotta explain to me
how reads really run through the kernel until they reach the DMA.

cheers
simon

:why on earth does ext2_read cascade to ufs_*? is that the operation on=20=
:
:the /dev vnode which is on an ufs? but then it should be specfs, or=20
:not? i'm puzzled. if this isn't fishy, somebody gotta explain to me=20
:how reads really run through the kernel until they reach the DMA.
:
:cheers
: simon

You'd have to look at the FreeBSD cvs history.  I think ext2 is close
    enough to ufs that the person who did the original port decided to 
    just use most of the UFS code, with a few conditionalized exceptions.
    Don't ask me why.

-Matt

On 2006-04-01, Matthew Dillon <dillon@apollo.backplane.com> wrote:

Hmm. Is that ext2fs partition small enough that you can put the
raw disk image up somewhere? It's probably something simple related
to the BUF/BIO 64 bit offset conversion work, but I don't think I
can track it down from that backtrace.

Well, that concrete partition is far from being small enough, and ATM
don't have a Dfly box handy which I could use for reproducing the issue
with artifically small partitions... but I looked a bit into the code
and the issue is quite clear.

ext2fs doesn't have a dedicated strategy + bmap, it just falls back on
those of ufs:

sys/vfs/gnu/ext2fs/ext2_vnops.c :
----------------------------
/* Global vfs data structures for ufs. */
struct vnodeopv_entry_desc ext2_vnodeop_entries[] = { { &vop_default_desc, (vnodeopv_entry_t) ufs_vnoperate },
----------------------------

This worked fine with the old ufs bmap.

But take a look at the effect of the

"Major BUF/BIO work commit.  Make I/O BIO-centric and specify the disk or
  file location with a 64 bit offset instead of a 32 bit block number."

patch on sys/vfs/ufs/ufs_bmap.c :

http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ufs_bmap.c.diff?r1=1.9&r2=1.10&f=h

Unlike the old ones, the new ufs_bmap() and ufs_bmaparray() utilizes an "fs"
thingy, which is initialized like this:

sys/vfs/ufs/ufs_bmap.c :
----------------------------
fs = VTOI->i_fs;
----------------------------

Here the VTOI macro gives back the private field of the vnode as a struct
inode, which is fine for both of ufs and ext2fs. But fetching "i_fs" is bogus
-- struct inode looks like this:

sys/vfs/ufs/inode.h :
----------------------------
struct inode {
[...]
union { /* Associated filesystem. /
struct fs *fs; / FFS /
struct ext2_sb_info *e2fs; / EXT2FS */
} inode_u;
#define i_fs inode_u.fs
#define i_e2fs inode_u.e2fs
[...]
}
----------------------------

That is, eventually the ufsish superblock-alike structure gets used in
ufs_bmap() and ufs_bmaparray(), regardless the actual "client" is being
ufs or ext2.

Sure, ext2fs won't be made happy by this maltreatment.

Regards,
Csaba

:
:But take a look at the effect of the
:
: "Major BUF/BIO work commit. Make I/O BIO-centric and specify the disk or
: file location with a 64 bit offset instead of a 32 bit block number."
:
:patch on sys/vfs/ufs/ufs_bmap.c :
:
: http://www.dragonflybsd.org/cvsweb/src/sys/vfs/ufs/ufs_bmap.c.diff?r1=1.9&r2=1.10&f=h
:
:Unlike the old ones, the new ufs_bmap() and ufs_bmaparray() utilizes an "fs"
:thingy, which is initialized like this:
:
:sys/vfs/ufs/ufs_bmap.c :
:----------------------------
:fs = VTOI->i_fs;
:----------------------------
:
:Here the VTOI macro gives back the private field of the vnode as a struct
:inode, which is fine for both of ufs and ext2fs. But fetching "i_fs" is bogus
:...

Yah, I think you are right.  EXT2FS can't share UFS's routines any 
    more.

I'll have a go at making ext2-private versions of all the UFS routines.
    I don't yet know how hard (or easy) it will turn out to be.

-Matt

On Sun, Apr 02, 2006 at 02:40:26AM +0200, Simon 'corecode' Schubert wrote:

why on earth does ext2_read cascade to ufs_*?

ext2 == async ufs modulo Linux bugs. Sharing the code makes a lot sense.

Joerg

All right. I have no idea whether EXT2 still works after all the surgery
I just did, but its worth a try.

-Matt

On 2006-04-04, Matthew Dillon <dillon@apollo.backplane.com> 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:

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

: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:

I'll synch up the vinitvmio calls with UFS right now.

I don't know re: e2fsck. 

-Matt

On 2006-04-05, Csaba Henk <csaba.henk@creo.hu> wrote:

But then I get the same type of panic from another place.

To be more exact:

#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=0xd4adc2f0, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_bio.c:2157
#13 0xd4a4763c in ext2_balloc (ip=0xd4a3cd00, bn=0, size=24, cred=0xd25a07d8, bpp=0xd49f98f8, flags=3) at ext2_balloc.c:146
#14 0xd4a50912 in ext2_write (ap=0xd49f9924) at ext2_readwrite.c:250
#15 0xc0300957 in vop_write (ops=0xc050f8fc, vp=0xd4adc2f0, uio=0x12, ioflag=18, cred=0x12)
at /usr/dispatch/src/sys/kern/vfs_vopops.c:524
#16 0xc02ffa8f in vn_rdwr (rw=UIO_WRITE, vp=0xd4adc2f0, base=0x12 <Address 0x12 out of bounds>, len=24, offset=Unhandled dwarf expression opcode 0x93
)
at /usr/dispatch/src/sys/kern/vfs_vnops.c:436
#17 0xd4a51fcf in ext2_mkdir (ap=0xd49f9a30) at ext2_vnops.c:968
#18 0xc0300b97 in vop_old_mkdir (ops=0xc050f8fc, dvp=0x12, vpp=0x12, cnp=0x12, vap=0x12)
at /usr/dispatch/src/sys/kern/vfs_vopops.c:702
#19 0xc02edb6f in vop_compat_nmkdir (ap=0xd49f9ac8) at /usr/dispatch/src/sys/kern/vfs_default.c:457
#20 0xc02ed4f6 in vop_defaultop (ap=0xc050f8fc) at /usr/dispatch/src/sys/kern/vfs_default.c:155
#21 0xc03012d1 in vop_nmkdir (ops=0xc050f8fc, ncp=0x12, vpp=0xd49f9b1c, cred=0x12, vap=0x12)
at /usr/dispatch/src/sys/kern/vfs_vopops.c:1256
#22 0xc02fde94 in kern_mkdir (nd=0xd4ab0d08, mode=511) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:2812
#23 0xc02fdf03 in mkdir (uap=0xd49f9c24) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:2832
#24 0xc04b6607 in syscall2 (frame= {tf_fs = 673644591, tf_es = 680525871, tf_ds = -1078001617, tf_edi = 673855244, tf_esi = 673669632, tf_ebp = -1077943928, tf_isp = -727736972, tf_ebx = 672496640, tf_edx = 672455056, tf_ecx = 0, tf_eax = 136, tf_trapno = 7, tf_err = 2, tf_eip = 673058396, tf_cs = 31, tf_eflags = 658, tf_esp = -1077943972, tf_ss = 47}) at /usr/dispatch/src/sys/i386/i386/trap.c:1420
#25 0xc04a29ca in Xint0x80_syscall () at /usr/dispatch/src/sys/i386/i386/exception.s:852

Regards,
Csaba

On 2006-04-05, Matthew Dillon <dillon@apollo.backplane.com> wrote:

I'll synch up the vinitvmio calls with UFS right now.

Now the "no vmobject" panic happened via ext2_symlink(). Furthermore,
you've left some printf's in the code, I wonder if it's intentional...

Unfortunately, some hardware error just made my Dfly box unuseable,
so I won't be able to do further testing for an undefinite while.

Regards,
Csaba