Project

General

Profile

Actions

Bug #130

closed

ext2fs panic with Dfly 1.5.2

Added by csaba.henk over 15 years ago. Updated about 15 years ago.

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

0%

Estimated time:

Description

Hi,

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

Regards,
Csaba

Fatal trap 18: integer divide fault while in kernel mode
instruction pointer = 0x8:0xc041b02c
stack pointer = 0x10:0xcaf418ac
frame pointer = 0x10:0xcaf418e0
code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 42 (ls)
current thread = pri 6

panic: from debugger

Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc04a6dee
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 = 42 (ls)
current thread = pri 6

panic: from debugger
Uptime: 1m38s

dumping to dev #ad/0x50001, offset 1621729
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-dragonfly".
(kgdb) bt
#0 dumpsys () at thread.h:81
#1 0xc02ad166 in boot (howto=260) at /usr/dispatch/src/sys/kern/kern_shutdown.c:365
#2 0xc02ad626 in panic (fmt=0xc0500f2a "from debugger") at /usr/dispatch/src/sys/kern/kern_shutdown.c:679
#3 0xc0162b2a in db_panic (addr=-1069436884, have_addr=0, count=-1, modif=0xcaf41718 "")
at /usr/dispatch/src/sys/ddb/db_command.c:447
#4 0xc0162abf in db_command (last_cmdp=0xc05b75d0, cmd_table=0x0, aux_cmd_tablep=0xc055a4a4, aux_cmd_tablep_end=0xc055a4bc)
at /usr/dispatch/src/sys/ddb/db_command.c:343
#5 0xc0162b9f in db_command_loop () at /usr/dispatch/src/sys/ddb/db_command.c:469
#6 0xc016589c in db_trap (type=18, code=0) at /usr/dispatch/src/sys/ddb/db_trap.c:71
#7 0xc04a6a98 in kdb_trap (type=18, code=0, regs=0xcaf4186c) at /usr/dispatch/src/sys/i386/i386/db_interface.c:150
#8 0xc04bb6a5 in trap_fatal (frame=0xcaf4186c, eva=0) at /usr/dispatch/src/sys/i386/i386/trap.c:1199
#9 0xc04bb118 in trap (frame= {tf_fs = 24, tf_es = -889978864, tf_ds = -1072103408, tf_edi = 0, tf_esi = -964579904, tf_ebp = -889972512, tf_isp = -889972584, tf_ebx = -889972488, tf_edx = 0, tf_ecx = -1060993916, tf_eax = 0, tf_trapno = 18, tf_err = 0, tf_eip = -1069436884, tf_cs = 8, tf_eflags = 66071, tf_esp = -889890304, tf_ss = 0}) at /usr/dispatch/src/sys/i386/i386/trap.c:858
#10 0xc04a7d7f in calltrap () at /usr/dispatch/src/sys/i386/i386/exception.s:774
#11 0xc041b02c in ufs_bmap (ap=0xcaf418f8) at /usr/dispatch/src/sys/vfs/ufs/ufs_bmap.c:96
#12 0xc0421ac2 in ufs_vnoperate (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:2382
#13 0xc03016f7 in vop_bmap (ops=0xc0c28484, vp=0x0, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_vopops.c:881
#14 0xc042123e in ufs_strategy (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:1778
#15 0xc0421ac2 in ufs_vnoperate (ap=0x0) at /usr/dispatch/src/sys/vfs/ufs/ufs_vnops.c:2382
#16 0xc030172d in vop_strategy (ops=0x0, vp=0xcaf55a00, bio=0xc0c28430) at /usr/dispatch/src/sys/kern/vfs_vopops.c:896
#17 0xc02e7a0f in vn_strategy (vp=0xcaf55a00, bio=0xc0c28484) at /usr/dispatch/src/sys/kern/vfs_bio.c:2786
#18 0xc02e46dc in bread (vp=0xcaf55a00, loffset=Unhandled dwarf expression opcode 0x93
) at /usr/dispatch/src/sys/kern/vfs_bio.c:611
#19 0xc0b0a914 in ?? ()
#20 0xcaf55a00 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00001000 in ?? ()
#24 0xcaf41a60 in ?? ()
#25 0x00001000 in ?? ()
#26 0xc05f1724 in map_init ()
#27 0xcaf41a6c in ?? ()
#28 0xc02abe9f in kmem_slab_alloc (size=3404995196, align=0, flags=-964720192)
at /usr/dispatch/src/sys/kern/kern_slaballoc.c:1171
#29 0xc0301244 in vop_read (ops=0x0, vp=0x0, uio=0x0, ioflag=0, cred=0x0) at /usr/dispatch/src/sys/kern/vfs_vopops.c:510
#30 0xc0b06f9e in ?? ()
#31 0xc67f89c0 in ?? ()
#32 0xcaf55a00 in ?? ()
#33 0xcaf41af8 in ?? ()
#34 0x00000000 in ?? ()
#35 0xc0b56120 in ?? ()
#36 0xc4356f00 in ?? ()
#37 0x00000000 in ?? ()
#38 0xcaf55a00 in ?? ()
#39 0x01020002 in ?? ()
#40 0x00020002 in ?? ()
#41 0x00000000 in ?? ()
#42 0x00000000 in ?? ()
#43 0xc0ae3000 in ?? ()
#44 0x01020002 in ?? ()
#45 0x00000000 in ?? ()
#46 0xc0ae3000 in ?? ()
#47 0x00001000 in ?? ()
#48 0xcaf41af0 in ?? ()
#49 0x00000001 in ?? ()
#50 0x00000000 in ?? ()
#51 0x00000000 in ?? ()
#52 0x00001000 in ?? ()
#53 0x00000001 in ?? ()
#54 0x00000000 in ?? ()
#55 0xc4356f00 in ?? ()
#56 0xcaf41c24 in ?? ()
#57 0xc3fdf840 in ?? ()
#58 0xc4356f00 in ?? ()
#59 0xcaf41b60 in ?? ()
#60 0xc03015b3 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:781
#61 0xc03015b3 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:781
#62 0xc02fe79f 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:2905
#63 0xc02fe8c3 in getdirentries (uap=0xcaf41c24) at /usr/dispatch/src/sys/kern/vfs_syscalls.c:2947
#64 0xc04bba47 in syscall2 (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1268, tf_esi = 671793216, tf_ebp = -1077939544, 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 = -1077939572, tf_ss = 47}) at /usr/dispatch/src/sys/i386/i386/trap.c:1420
#65 0xc04a7e0a in Xint0x80_syscall () at /usr/dispatch/src/sys/i386/i386/exception.s:852
#66 0x0000001f in ?? ()
#67 0x0000002f in ?? ()
#68 0x00000000 in ?? ()
#69 0x00000000 in ?? ()
#70 0x00000000 in ?? ()
#71 0x00000000 in ?? ()
#72 0x0268f000 in ?? ()
#73 0x0000000d in ?? ()
#74 0xc05cc214 in intr_info_ary ()
#75 0xcaf416ec in ?? ()
#76 0xcaf416d4 in ?? ()
#77 0xc4356f00 in ?? ()
#78 0xc02b30d6 in lwkt_preempt (ntd=0xbfbff2a8, critpri=31) at /usr/dispatch/src/sys/kern/lwkt_thread.c:861
Previous frame inner to this frame (corrupt stack?)

Actions #1

Updated by csaba.henk over 15 years ago

On 2006-03-29, Csaba Henk <> 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

Actions #2

Updated by dillon over 15 years ago

:On 2006-03-29, Csaba Henk <> 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
&lt;&gt;
Actions #3

Updated by corecode over 15 years ago

^^^

^^^
^^^
^^^
^^

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

Actions #4

Updated by dillon over 15 years ago

: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
Actions #5

Updated by csaba.henk over 15 years ago

On 2006-04-01, Matthew Dillon <> 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

Actions #6

Updated by dillon over 15 years ago

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

Updated by joerg over 15 years ago

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

Actions #8

Updated by dillon over 15 years ago

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

-Matt
Actions #9

Updated by csaba.henk over 15 years ago

On 2006-04-04, Matthew Dillon <> 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

Actions #10

Updated by dillon over 15 years ago

: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
Actions #11

Updated by csaba.henk over 15 years ago

On 2006-04-05, Csaba Henk <> 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

Actions #12

Updated by csaba.henk over 15 years ago

On 2006-04-05, Matthew Dillon <> 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

Actions

Also available in: Atom PDF