DragonFlyBSD

Can the memory image file be used as a core dump?

Cheers,
Nuno

Hm:
"/home/var.vkernel/memimg.000000" is not a core dump: File format not
recognized" guess not? (tried it with gdb not kgdb)

I'm afraid there is no way to capture vkernel core dumps currently.
Simon posted a debug-oriented wish list a while ago and, IIRC, vkernel
core dumps were part of it.

I wonder how _sysref_put() can end up calling vget(). Any idea?

:Hm:
:"/home/var.vkernel/memimg.000000" is not a core dump: File format not
:recognized" guess not? (tried it with gdb not kgdb)

Heh.  No but you CAN gdb the live vkernel (assuming it dropped into
    db> it is still running).

In anycase, don't bother going that far.  There's definitely a bug
    here.  The vnode is supposed to have a VM object associated with it
    and clearly there must be a path where that vnode can be instantiated
    without one.

Can you by any chance reproduce the bug to test that this patch
    fixes the problem?

-Matt

Index: ufs_inode.c ===================================================================
RCS file: /cvs/src/sys/vfs/ufs/ufs_inode.c,v
retrieving revision 1.24
diff u -p -r1.24 ufs_inode.c
-- ufs_inode.c 2 Jan 2008 22:42:37 0000 1.24
++ ufs_inode.c 2 Apr 2008 05:51:41 -0000
@ -87,6 +87,8 @ if (!ufs_getinoquota(ip))
(void)ufs_chkiq(ip, -1, NOCRED, FORCE);
#endif
/* Must have a VM object to truncate */
if (vp>v_object == NULL)
+ vinitvmio(vp, 0);
error = ffs_truncate(vp, (off_t)0, 0, NOCRED);
ip->i_rdev = 0;
mode = ip->i_mode;

:
:2008/4/1, Rumko <rumcic@gmail.com>:
:> vget(669232e8,672d4b1c,669232f8,672d4ab0,80e7e97) at 0x80e803b
:> _sysref_put(669232f8,672d4b5c,66964418,672d4af8,80df8a0) at 0x808260a
:
:I wonder how _sysref_put() can end up calling vget(). Any idea?

I think that's just a backtrace snafu.  The vkernrel's DDB support
    for backtraces is rather hacked up.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matthew Dillon wrote:

I'll try to reproduce it, but since this is the first time I got this panic ...
I'll see if it can be done
--
Regards,
Rumko

:> /* Must have a VM object to truncate */
:> + if (vp->v_object == NULL)
:> + vinitvmio(vp, 0);
:> error = ffs_truncate(vp, (off_t)0, 0, NOCRED);
:> ip->i_rdev = 0;
:> mode = ip->i_mode;
:
:I'll try to reproduce it, but since this is the first time I got this panic ...
:I'll see if it can be done
:--
:Regards,
:Rumko

Scrap that patch.  It's bad.  It causes more panics then it fixes.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matthew Dillon wrote:

Ok ... I have yet to reproduce the panic (the vkernel is still building the
packages) so I have not applied the patch yet.
--
Regards,
Rumko

Rumko wrote:

Alrighty ... I triggered another panic (while checking out the pkgsrc tree ...
but it seems to me a different panic unrelated to this?

Checkout latest pkgsrc-current...
mode = 030721, inum = 64, fs =
panic: ffs_valloc: dup alloc
Trace beginning at frame 0x6565480c
panic(65654830,0,58583800,65c95300,656548ac) at 0x80a1777
panic(81ebe10,81eba88,31d1,40,585838d4) at 0x80a1777
ffs_valloc(65c27de8,81a4,63b08798,656548d0,65654bbc) at 0x81888fd
ufs_vnoperatespec(65654a60,fffffffe,65ca7c08,65654a08,81996cd) at 0x8199e28
ufs_vnoperatespec(65654a14,65654a3c,80efc2c,65654a14,820a370) at 0x819a11b
ufs_vnoperate(65654a14,820a370,5ee91fd0,2,65c27de8) at 0x81996cd
vop_old_create(5ee91fd0,65c27de8,65654bbc,65654a60,65654b10) at 0x80efc2c
vop_compat_ncreate(65654ab0,65654aa4,81996cd,65654ab0,65654ae4) at 0x80e05cd
vop_defaultop(65654ab0,65654ae4,80f09a3,65654ab0,820a4d0) at 0x80df3ef
ufs_vnoperate(65654ab0,820a4d0,5ee91fd0,6216700f,0) at 0x81996cd
vop_ncreate(5ee91fd0,65654c38,65c27de8,65654bbc,63b08798) at 0x80f09a3
vn_open(65654c38,63bc8778,20a,1a4,620c9400) at 0x80ef076
kern_open(65654c38,209,1b6,65654ca0,65ca7c08) at 0x80ec5ba
sys_open(65654ca0,6,0,0,63b2ed18) at 0x80ec78f
syscall2(65654d40,0,6,0,0) at 0x81bd7af
user_trap(65654d40,620c9400,81bd5b1,0,81bde4c) at 0x81bd982
go_user(65654d38,0,0,7b,0) at 0x81bdd01
Debugger("panic")
Stopped at 0x81bb3c9: movb $0,0x82a1074
--
Regards,
Rumko

:Alrighty ... I triggered another panic (while checking out the pkgsrc tree ...
:but it seems to me a different panic unrelated to this?
:
:Checkout latest pkgsrc-current...
:mode = 030721, inum = 64, fs =
:panic: ffs_valloc: dup alloc
:Trace beginning at frame 0x6565480c

That's a different, unrealted panic.

Did you at any time prior to the checkout fill up the filesystem?
    There's a bug in UFS that can cause corruption when the filesystem 
    fills up which we haven't patched yet.

-Matt

Matthew Dillon wrote:

Er ... now that is a very good question ... I don't remember right now if I did
ever fill it up, but the base image which I copy (and abuse the copy) is very
old, so there is a possibility of that ... oh well, guess it's time to remake
the base image.
--
Regards,
Rumko

Well it's been a long time, but I have managed to get a panic with "panic:
getblk: vnode 0xf1fda768 has no object!" on my host machine this time.
The kernel.1 and vmcore.1 files are at leaf:~rumko/crash/01.05.2008

The backtrace:
#0 dumpsys () at ./machine/thread.h:83
#1 0xc0270739 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc02709fc in panic (fmt=0xc050659c "getblk: vnode %p has no object!") at
/usr/src/sys/kern/kern_shutdown.c:800
#3 0xc02ac5c6 in getblk (vp=0xf1fda768, loffset=-274945245184, size=16384,
blkflags=<value optimized out>, slptimeo=0)
at /usr/src/sys/kern/vfs_bio.c:2350
#4 0xc03b0160 in ffs_indirtrunc (ip=0xf1389200, lbn=-16781326, dbn=-16793008,
lastbn=-1, level=2, countp=0xf18629c0)
at /usr/src/sys/vfs/ufs/ffs_inode.c:465
#5 0xc03b0da5 in ffs_truncate (vp=0xf1fda768, length=0, flags=0, cred=0x0) at
/usr/src/sys/vfs/ufs/ffs_inode.c:333
#6 0xc03bb472 in ufs_inactive (ap=0xf1862aa4) at
/usr/src/sys/vfs/ufs/ufs_inode.c:90
#7 0xc03bdffa in ufs_vnoperate (ap=0xf1862aa4) at
/usr/src/sys/vfs/ufs/ufs_vnops.c:2444
#8 0xc02c2e56 in vop_inactive (ops=0xd3a14970, vp=0xf1fda768) at
/usr/src/sys/kern/vfs_vopops.c:610
#9 0xc02badc8 in vnode_terminate (vp=0xf1fda768) at
/usr/src/sys/kern/vfs_lock.c:252
#10 0xc0250670 in _sysref_put (sr=0xf1fda778) at /usr/src/sys/kern/kern_sysref.c:318
#11 0xc02bac20 in vrele (vp=0x0) at /usr/src/sys/sys/sysref2.h:85
#12 0xc02b25f0 in vop_compat_nresolve (ap=0xf1862b68) at
/usr/src/sys/kern/vfs_default.c:230
#13 0xc02b213b in vop_defaultop (ap=0xf1862b68) at
/usr/src/sys/kern/vfs_default.c:146
#14 0xc03bdffa in ufs_vnoperate (ap=0xf1862b68) at
/usr/src/sys/vfs/ufs/ufs_vnops.c:2444
#15 0xc02c315b in vop_nresolve (ops=0xd3a14970, nch=0xf1862ba8, dvp=0xf2331168,
cred=0xe0b53318)
at /usr/src/sys/kern/vfs_vopops.c:945
#16 0xc02af3be in cache_resolve (nch=0xf1862bd8, cred=0xe0b53318) at
/usr/src/sys/kern/vfs_cache.c:2065
#17 0xc02b6bc4 in nlookup (nd=0xf1862c84) at /usr/src/sys/kern/vfs_nlookup.c:397
#18 0xc02be82f in kern_stat (nd=0xf1862c84, st=0xf1862c1c) at
/usr/src/sys/kern/vfs_syscalls.c:2157
#19 0xc02be8d7 in sys_lstat (uap=0xf1862cf0) at
/usr/src/sys/kern/vfs_syscalls.c:2220
#20 0xc048132d in syscall2 (frame=0xf1862d40) at
/usr/src/sys/platform/pc32/i386/trap.c:1348
#21 0xc046e8b5 in Xint0x80_syscall () at
/usr/src/sys/platform/pc32/i386/exception.s:872
#22 0x0804e698 in ?? ()

Matt, if I recall correctly you managed to buildworld and buildkernel inside a
vkernel, right?