From syjef@jef-nt.mdacc.tmc.edu  Mon Aug 18 10:44:50 2003
Return-Path: <syjef@jef-nt.mdacc.tmc.edu>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4926637B42C
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Aug 2003 10:44:47 -0700 (PDT)
Received: from jef-nt.mdacc.tmc.edu (jef-nt.mdacc.tmc.edu [143.111.64.231])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 37CBE44304
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Aug 2003 10:21:50 -0700 (PDT)
	(envelope-from syjef@jef-nt.mdacc.tmc.edu)
Received: from jef-nt.mdacc.tmc.edu (localhost [127.0.0.1])
	by jef-nt.mdacc.tmc.edu (8.12.9/8.12.9) with ESMTP id h7IHLlGd037057
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Aug 2003 12:21:47 -0500 (CDT)
	(envelope-from syjef@jef-nt.mdacc.tmc.edu)
Received: (from root@localhost)
	by jef-nt.mdacc.tmc.edu (8.12.9/8.12.9/Submit) id h7IHLk62037054;
	Mon, 18 Aug 2003 12:21:46 -0500 (CDT)
Message-Id: <200308181721.h7IHLk62037054@jef-nt.mdacc.tmc.edu>
Date: Mon, 18 Aug 2003 12:21:46 -0500 (CDT)
From: Jonathan Fosburgh <syjef@mdanderson.org>
Reply-To: Jonathan Fosburgh <syjef@mdanderson.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Kernel panic on NTFS
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         55702
>Category:       kern
>Synopsis:       Kernel panic on NTFS
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 18 10:50:07 PDT 2003
>Closed-Date:    Sat Nov 15 13:36:53 PST 2003
>Last-Modified:  Sat Nov 15 13:36:53 PST 2003
>Originator:     Jonathan Fosburgh
>Release:        FreeBSD 5.1-CURRENT i386
>Organization:
>Environment:
System: FreeBSD jef-nt.mdacc.tmc.edu 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Fri Aug 15 11:13:24 CDT 2003 syjef@jef-nt.mdacc.tmc.edu:/usr/obj/usr/src/sys/vmbsd i386


	
>Description:
	On performing various I/O operations on NTFS, a kernel panic occurs. The filesystems are mounted read only.  I have seen this problem when running commands such as ls or find on the filesystem, and most recently when trying to run the notepad.exe that ships with Windows2000 under Wine. I was not dropped into the kernel debugger, so I don't have an (obvious) instruction pointer.  However, the info file for the dump reads:

Good dump found on device /dev/ad0s1b
  Architecture: i386
  Architecture version: 1
  Dump length: 402587648B (383 MB)
  Blocksize: 512
  Dumptime: Mon Aug 18 11:52:48 2003
  Hostname: jef-nt.mdacc.tmc.edu
  Versionstring: FreeBSD 5.1-CURRENT #3: Fri Aug 15 11:13:24 CDT 2003
    syjef@jef-nt.mdacc.tmc.edu:/usr/obj/usr/src/sys/vmbsd
  Panicstring: filesystem goof: vop_panic[vop_specstrategy]
  Bounds: 7


And from gdb -k:

# gdb -k /boot/kernel/kernel vmcore.7
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd"...(no debugging symbols found)...
panic: filesystem goof: vop_panic[vop_specstrategy]
panic messages:
---
panic: filesystem goof: vop_panic[vop_specstrategy]

syncing disks, buffers remaining... 3044 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041 3041
giving up on 1304 buffers
Uptime: 4h38m1s
Dumping 383 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
---
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug
---Type <return> to continue, or q <return> to quit---
Reading symbols from /boot/kernel/nvidia.ko...done.
Loaded symbols for /boot/kernel/nvidia.ko
Reading symbols from /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/vmbsd/modules/usr/src/sys/modules/ntfs/ntfs.ko.debug
#0  0xc023157b in doadump ()
(kgdb) where
#0  0xc023157b in doadump ()
#1  0xc0231c09 in boot ()
#2  0xc0231fe8 in panic ()
#3  0xc02851ce in vop_panic ()
#4  0xc02851a8 in vop_defaultop ()
#5  0xc036685a in vnode_pager_input_smlfs ()
#6  0xc03671ec in vnode_pager_generic_getpages ()
#7  0xc0285da9 in vop_stdgetpages ()
#8  0xc02851a8 in vop_defaultop ()
#9  0xc0366ddb in vnode_pager_getpages ()
#10 0xc034c672 in vm_fault ()
#11 0xc039cb05 in trap_pfault ()
#12 0xc039c6a3 in trap ()
#13 0xc038ca88 in calltrap ()
---Can't read userspace from dump, or kernel process---

>How-To-Repeat:
	Mount any NTFS and perform I/O operations on it.  I have never seen it take very long for this panic to manifest itself.
>Fix:

Don't mount NTFS filesystems.

>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@ringlet.net>
To: Jonathan Fosburgh <syjef@mdanderson.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/55702: Kernel panic on NTFS
Date: Thu, 28 Aug 2003 10:49:16 +0300

 On Mon, Aug 18, 2003 at 12:21:46PM -0500, Jonathan Fosburgh wrote:
 > 
 > >Number:         55702
 > >Category:       kern
 > >Synopsis:       Kernel panic on NTFS
 > >Originator:     Jonathan Fosburgh
 > >Release:        FreeBSD 5.1-CURRENT i386
 > >Organization:
 > >Environment:
 > System: FreeBSD jef-nt.mdacc.tmc.edu 5.1-CURRENT FreeBSD 5.1-CURRENT #3: Fri Aug 15 11:13:24 CDT 2003 syjef@jef-nt.mdacc.tmc.edu:/usr/obj/usr/src/sys/vmbsd i386
 [snip]
 > >Description:
 > On performing various I/O operations on NTFS, a kernel panic occurs.
 > The filesystems are mounted read only.  I have seen this problem when
 > running commands such as ls or find on the filesystem, and most
 > recently when trying to run the notepad.exe that ships with
 > Windows2000 under Wine. I was not dropped into the kernel debugger, so
 > I don't have an (obvious) instruction pointer.  However, the info file
 > for the dump reads:
 [snip dump header]
 > And from gdb -k:
 > 
 > # gdb -k /boot/kernel/kernel vmcore.7
 [snip]
 > #0  0xc023157b in doadump ()
 > (kgdb) where
 > #0  0xc023157b in doadump ()
 > #1  0xc0231c09 in boot ()
 > #2  0xc0231fe8 in panic ()
 > #3  0xc02851ce in vop_panic ()
 > #4  0xc02851a8 in vop_defaultop ()
 > #5  0xc036685a in vnode_pager_input_smlfs ()
 > #6  0xc03671ec in vnode_pager_generic_getpages ()
 > #7  0xc0285da9 in vop_stdgetpages ()
 > #8  0xc02851a8 in vop_defaultop ()
 > #9  0xc0366ddb in vnode_pager_getpages ()
 > #10 0xc034c672 in vm_fault ()
 > #11 0xc039cb05 in trap_pfault ()
 > #12 0xc039c6a3 in trap ()
 > #13 0xc038ca88 in calltrap ()
 > ---Can't read userspace from dump, or kernel process---
 
 Could you try rebuilding your kernel with debug symbols (in the kernel
 config, set 'makeoptions DEBUG=-g' and then either run config -g, or
 if you are using the proper buildworld/installworld procedure, set
 CONFIGARGS=-g in your environment before the buildworld), and then
 try to obtain another dump, so gdb can provide a bit more info?
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 If this sentence were in Chinese, it would say something else.

From: Jonathan Fosburgh <syjef@mdanderson.org>
To: Peter Pentchev <roam@ringlet.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/55702: Kernel panic on NTFS
Date: Thu, 28 Aug 2003 10:53:21 -0500

 >
 > Could you try rebuilding your kernel with debug symbols (in the kernel
 > config, set 'makeoptions DEBUG=-g' and then either run config -g, or
 > if you are using the proper buildworld/installworld procedure, set
 > CONFIGARGS=-g in your environment before the buildworld), and then
 > try to obtain another dump, so gdb can provide a bit more info?
 
 I didn't realize I had missed something (the CONFIGARGS, I have DEBUG set in 
 the config file).  Thanks, I'll get to that as soon as I can.
 -- 
 Jonathan Fosburgh
 AIX and Storage Administrator
 UT MD Anderson Cancer Center
 Houston, TX 

From: Jonathan Fosburgh <syjef@mdanderson.org>
To: Peter Pentchev <roam@ringlet.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/55702: Kernel panic on NTFS
Date: Thu, 28 Aug 2003 14:04:23 -0500

 OK, here it is.  Interestingly, I had to be in multi-user mode to reproduce 
 the panic.
 
 (kgdb) where
 #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
 #1  0xc01d51f9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
 #2  0xc01d55d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
 #3  0xc013fbe2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
 #4  0xc013fb42 in db_command (last_cmdp=0xc03b2bc0, cmd_table=0x0,
     aux_cmd_tablep=0xc0386068, aux_cmd_tablep_end=0xc038606c)
     at /usr/src/sys/ddb/db_command.c:346
 #5  0xc013fc85 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
 #6  0xc0142ca5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
 #7  0xc031f42c in kdb_trap (type=3, code=0, regs=0xd801a8f4)
     at /usr/src/sys/i386/i386/db_interface.c:171
 #8  0xc0330cba in trap (frame=
       {tf_fs = 24, tf_es = 16, tf_ds = 524304, tf_edi = 1, tf_esi = 
 -1070142462, tf_ebp = -670979776, tf_isp = -670979808, tf_ebx = 0, tf_edx = 
 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070467356, 
 tf_cs = 8, tf_eflags = 642, tf_esp = -1070072144, tf_ss = -1070158345})
     at /usr/src/sys/i386/i386/trap.c:577
 #9  0xc0320e18 in calltrap () at {standard input}:102
 #10 0xc01d5515 in panic (fmt=0xc036ec02 "filesystem goof: vop_panic[%s]")
     at /usr/src/sys/kern/kern_shutdown.c:534
 #11 0xc022933e in vop_panic () at /usr/src/sys/kern/vfs_default.c:171
 #12 0xc0229318 in vop_defaultop (ap=0x0) at 
 /usr/src/sys/kern/vfs_default.c:161
 #13 0xc02fa9aa in vnode_pager_input_smlfs (object=0xc4d744a0, m=0xc0b1dfc0)
     at vnode_if.h:1141
 #14 0xc02fb30c in vnode_pager_generic_getpages (vp=0xc39c9000, m=0xd801ac6c,
     bytecount=4096, reqpage=0) at /usr/src/sys/vm/vnode_pager.c:688
 #15 0xc0229f19 in vop_stdgetpages (ap=0x0)
     at /usr/src/sys/kern/vfs_default.c:795
 #16 0xc0229318 in vop_defaultop (ap=0x0) at 
 /usr/src/sys/kern/vfs_default.c:161
 #17 0xc02faefb in vnode_pager_getpages (object=0xc4d744a0, m=0x0, count=0,
     reqpage=0) at vnode_if.h:1317
 #18 0xc02e0762 in vm_fault (map=0xc4982500, vaddr=16777216,
     fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_pager.h:129
 #19 0xc0330ec5 in trap_pfault (frame=0xd801ad48, usermode=1, eva=16777276)
     at /usr/src/sys/i386/i386/trap.c:708
 #20 0xc0330a63 in trap (frame=
       {tf_fs = 143, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 4096, tf_ebp 
 = -1077942708, tf_isp = -670978700, tf_ebx = 1544379884, tf_edx = 16777216, 
 tf_ecx = -1077942620, tf_eax = 16777217, tf_trapno = 12, tf_err = 4, tf_eip = 
 1544246055, tf_cs = 31, tf_eflags = 66050, tf_esp = -1077942780, tf_ss = 47})
     at /usr/src/sys/i386/i386/trap.c:316
 #21 0xc0320e18 in calltrap () at {standard input}:102
 ---Can't read userspace from dump, or kernel process---
  
 I did get thrown into ddb this time, but I didn't see anything that looked 
 like the instruction pointer.  Let me know if there is anything else I need 
 to provide.
 -- 
 Jonathan Fosburgh
 AIX and Storage Administrator
 UT MD Anderson Cancer Center
 Houston, TX 

From: Peter Pentchev <roam@ringlet.net>
To: Jonathan Fosburgh <syjef@mdanderson.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/55702: Kernel panic on NTFS
Date: Thu, 28 Aug 2003 22:21:37 +0300

 On Thu, Aug 28, 2003 at 02:04:23PM -0500, Jonathan Fosburgh wrote:
 > OK, here it is.  Interestingly, I had to be in multi-user mode to reproduce 
 > the panic.
 > 
 > (kgdb) where
 [snip stack trace with function arguments]
 
 Unfortunately, I personally cannot do much with this; hopefully there
 are others who will take it from here :)
 
 Thanks for the quick feedback and the detailed stack trace!
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 If there were no counterfactuals, this sentence would not have been paradoxical.
State-Changed-From-To: open->closed 
State-Changed-By: tjr 
State-Changed-When: Sat Nov 15 13:35:38 PST 2003 
State-Changed-Why:  
Fixed in -current (I hope). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=55702 
>Unformatted:
