Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Jan 2001 14:37:20 +0100
From:      Rogier Mulhuijzen <rmulhuijzen@Transfer-Solutions.com>
To:        freebsd-current@freebsd.org
Cc:        John Baldwin <jhb@FreeBSD.org>
Subject:   NTFS issue (was: Panic w/crash dump (looks like atomic.h problem))
Message-ID:  <5.0.2.1.0.20010119135940.00a565d0@tfrsolcom>
In-Reply-To: <XFMail.010118130907.jhb@FreeBSD.org>
References:  <5.0.2.1.0.20010118201134.00a542c0@tfrsolcom>

next in thread | previous in thread | raw e-mail | index | archive | help
a quick look at kldstat output pinpointed the ??'s in my stacktrace(see 
previous posts) to ntfs.ko. Compiled NTFS into my kernel and reproduced the 
crash.

Taking a look at the trace now:

#11 0xc01c0c97 in vref (vp=0x0) at machine/atomic.h:332
#12 0xc0239592 in ntfs_vgetex (mp=0xc0f7dc00, ino=4458, attrtype=128,
     attrname=0x0, lkflags=2, flags=4, p=0xc8d82640, vpp=0xc7f85db8)
     at ../../ntfs/ntfs_vfsops.c:987
#13 0xc0235a0b in ntfs_ntvattrget (ntmp=0xc0f7da00, ip=0xc1043000, type=128,
     name=0xc02c3fe8 "", vcn=0, vapp=0xc7f85e3c) at ../../ntfs/ntfs_subr.c:231
#14 0xc0238134 in ntfs_readattr (ntmp=0xc0f7da00, ip=0xc1043000, attrnum=128,
     attrname=0x0, roff=1644032, rsize=512, rdata=0x0, uio=0xc7f85ee4)
     at ../../ntfs/ntfs_subr.c:1699
#15 0xc02396c5 in ntfs_read (ap=0xc7f85e9c) at ../../ntfs/ntfs_vnops.c:184
#16 0xc01c91e4 in vn_read (fp=0xc103e540, uio=0xc7f85ee4, cred=0xc1024600,
     flags=0, p=0xc8d82640) at vnode_if.h:279

I took a look at the code in src/sys/ntfs/ntfs_vfsops.c

I compared the code surrounding VREF there with code in other FS drivers.

in ntfs/ntfs_vfsops.c

         if (lkflags & LK_TYPE_MASK) {
                 error = VN_LOCK(vp, lkflags, p);
                 if (error) {
                         vput(vp);
                         return (error);
                 }
         }

         VREF(ip->i_devvp);

in isofs/cd9660/cd9660_vfsops.c


         } else
                 bp = 0;

         ip->i_mnt = imp;
         ip->i_devvp = imp->im_devvp;
         VREF(ip->i_devvp);


in ufs/ffs/ffs_vfsops.c

         /*
          * Finish inode initialization now that aliasing has been resolved.
          */
         ip->i_devvp = ump->um_devvp;
         VREF(ip->i_devvp);

in ufs/ifs/ifs_vfsops.c

         /*
          * Finish inode initialization now that aliasing has been resolved.
          */
         ip->i_devvp = ump->um_devvp;
         VREF(ip->i_devvp);

Seeing this I added a check to see if ip->i_devvp was equal to 
ntmp->ntm_devvp. And a check to see if it was 0.

During normal operation on my NTFS partition I got no messages, so I took a 
bold step and added 'ip->i_devvp = ntmp->ntm_devvp;' just before the VREF call.

After installing new kernel and reboot I once again started playback of an 
mp3 on my NTFS partition and started make -j 128 world on my UFS partition.

And 'lo behold, every time I got a message that ip->i_devvp was equal not 
to ntmp->ntm_devvp, ip->i_devvp was equal to 0.

I can now stress the hell out of my box and the NTFS filesystem, and it 
keeps running.

Why exactly ip->i_devvp is 0 I don't know, I have to dig into the code some 
deeper, but every other FS that uses VREF copies it from their mountpoint 
structure before calling vref().

Am I on the right track here?

	DocWilco


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.2.1.0.20010119135940.00a565d0>