From owner-freebsd-current Fri Jan 19 5:35:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from tfrsolcom.transfer-solutions.com (mail.transfer-solutions.com [195.109.218.250]) by hub.freebsd.org (Postfix) with ESMTP id E817337B400; Fri, 19 Jan 2001 05:35:08 -0800 (PST) Received: by mail.transfer-solutions.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 14:29:12 +0100 Received: from tfrsolcom.transfer-solutions.com (localhost [127.0.0.1]) by tfrsolcom.transfer-solutions.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DAATSSWL; Fri, 19 Jan 2001 14:26:03 +0100 Received: from 193.100.100.198 by tfrsolcom.transfer-solutions.com (InterScan E-Mail VirusWall NT); Fri, 19 Jan 2001 14:25:58 +0100 (Romance Standard Time) From: Rogier Mulhuijzen To: freebsd-current@freebsd.org Cc: John Baldwin Message-Id: <5.0.2.1.0.20010119135940.00a565d0@tfrsolcom> X-Sender: rmulhuij@tfrsolcom X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 19 Jan 2001 14:37:20 +0100 Subject: NTFS issue (was: Panic w/crash dump (looks like atomic.h problem)) In-Reply-To: References: <5.0.2.1.0.20010118201134.00a542c0@tfrsolcom> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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