NetBSD Problem Report #38121

From woods@once.weird.com  Thu Feb 28 22:01:04 2008
Return-Path: <woods@once.weird.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id E5F1E63B90D
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 28 Feb 2008 22:01:03 +0000 (UTC)
Message-Id: <m1JUqoF-0018LQC@once.weird.com>
Date: Thu, 28 Feb 2008 17:00:59 -0500 (EST)
From: "Greg A. Woods" <woods@planix.com>
Sender: "Greg A. Woods" <woods@once.weird.com>	
Reply-To: "Greg A. Woods" <woods@planix.com>
To: NetBSD GNATS Bugs <gnats-bugs@gnats.NetBSD.org>
Subject: "panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image
X-Send-Pr-Version: 3.95

>Number:         38121
>Category:       kern
>Synopsis:       "panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 28 22:05:00 +0000 2008
>Closed-Date:    
>Last-Modified:  Wed Apr 20 03:25:01 +0000 2011
>Originator:     Greg A. Woods
>Release:        NetBSD 4.0_STABLE
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD 4.0_STABLE GENERIC.MP
Architecture: i386
Machine: i386
>Description:

panic: buf mem pool index 23
Stopped in pid 13.1 (ioflush) at        netbsd:cpu_Debugger+0x4:        popl    %ebp
db{0}> trace
cpu_Debugger(c0959581,d9092718,b7d59dae,202,c09da440) at netbsd:cpu_Debugger+0x4
panic(c093264f,17,60e,246,d909272c) at netbsd:panic+0x155
allocbuf(da9a45fc,0,1,c04335c7,da9a4448) at netbsd:allocbuf+0x4a7
getblk(d930c590,a,0,0,0) at netbsd:getblk+0x2d5
bread(d930c590,a,0,0,ffffffff) at netbsd:bread+0x62
pcbmap(da9a5c80,300,d9092914,0,0) at netbsd:pcbmap+0x198
msdosfs_bmap(d9092890,d000,d90928ac,c07c4820,da9a368c) at netbsd:msdosfs_bmap+0x5f
VOP_BMAP(da9a368c,300,0,d9092924,d9092914) at netbsd:VOP_BMAP+0x40
genfs_do_io(ce03e000,d000,11,1,c03d8040) at netbsd:genfs_do_io+0x24f
genfs_gop_write(da9a368c,d9092aa4,d,11,d9092aa8) at netbsd:genfs_gop_write+0x61
genfs_do_putpages(da9a368c,0,0,0,0) at netbsd:genfs_do_putpages+0xb4b
genfs_putpages(d9092b40,c024,b7d59dae,c07c4a60,da9a368c) at netbsd:genfs_putpages+0x3d
VOP_PUTPAGES(da9a368c,0,0,0,0) at netbsd:VOP_PUTPAGES+0x40
vflushbuf(da9a368c,0,d9092bcc,c048b0f5,da9a3718) at netbsd:vflushbuf+0x61
msdosfs_fsync(d9092bf8,10012,d9092c1c,c048689f,da9a368c) at netbsd:msdosfs_fsync+0x27
VOP_FSYNC(da9a368c,d0020f04,8,0,0) at netbsd:VOP_FSYNC+0x49
sched_sync(d002f6b8,0,c01002d2,fbff,c01002d2) at netbsd:sched_sync+0x22b
db{0}> reboot
syncing disks... panic: lockmgr: locking against myself
Stopped in pid 13.1 (ioflush) at        netbsd:cpu_Debugger+0x4:        popl    %ebp
db{0}> reboot
rebooting...

>How-To-Repeat:

	I had mounted a floppy image containing drdos in hopes of
	creating a bootable ISO with a BIOS update for my Dell PE2650.
	(Earlier attempts with an msdos622 image failed due to the
	update program being "too big to fit in memory")

	The image file came from the drdflash.zip file commonly
	available for download at many sites (I'm pretty sure my copy
	came from bootdisk.com).

16:48 [2000] # mkdir drdflash
16:49 [2001] # cd drdflash
16:49 [2002] # unzip ../drdflash.zip
Archive:  ../drdflash.zip
  inflating: LICENCE.TXT             
  inflating: README.TXT              
  inflating: FIRM.COM                
  inflating: DRDFLASH.IMG            
16:49 [2003] # cd ..
16:49 [2004] # cp drdflash/DRDFLASH.IMG PE2650-A21-boot-drdfloppy.image
16:50 [2005] # vnconfig -c vnd0 PE2650-A21-boot-drdfloppy.image
16:50 [2006] # fsck_msdos /dev/vnd0a
** /dev/vnd0a
** Phase 1 - Read and Compare FATs
** Phase 2 - Check Cluster Chains
** Phase 3 - Checking Directories
** Phase 4 - Checking for Lost Files
5 files, 1302 free (2605 clusters)
16:50 [2007] # mount -t msdos /dev/vnd0a /floppy


	I then copied the BIOS update program to the /floppy filesystem
	and some moments later, just as I was about to type the "umount"
	command, the system crashed, presumably while trying to flush
	the pending I/Os out to the vnd device.

>Fix:

	unknown

>Release-Note:

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: pooka@netbsd.org
Subject: Re: kern/38121: "panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image
Date: Thu, 28 Feb 2008 23:08:36 +0000

 On Thu, Feb 28, 2008 at 10:05:01PM +0000, Greg A. Woods wrote:

 > >Synopsis:       "panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image

 I have a vague recollection that this is fixed in -current..

 Andrew

From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: Andrew Doran <ad@NetBSD.org>
Subject: Re: kern/38121: "panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image
Date: Fri, 29 Feb 2008 12:09:51 -0500

 On 28-Feb-08, at 6:10 PM, Andrew Doran wrote:
 >
 >  On Thu, Feb 28, 2008 at 10:05:01PM +0000, Greg A. Woods wrote:
 >
 >>> Synopsis:       "panic: buf mem pool index 23" crash apparently  
 >>> caused by mounting msdos floppy image
 >
 >  I have a vague recollection that this is fixed in -current..

 If you have any idea what change might have fixed it I can try  
 pulling it up and testing it for inclusion into the netbsd-4 branch.

 I've seen some other msdos filesystem problems that I should  
 reproduce and report too.  I think they may be related to running an  
 msdos FS out of space, but they also reveal very serious bugs in  
 fsck_msdos as they result in corruption that it is never able to fix  
 (but scandisk on dos-6.22 found and fixed the problems fine).  Those  
 should probably all be in a separate PR though I guess as they're not  
 likely related to this bug.

 -- 
 					Greg A. Woods; Planix, Inc.
 					<woods@planix.ca>



State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 19 Sep 2009 21:09:47 +0000
State-Changed-Why:
Have you tried this on 5.0?


From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/38121
Date: Sun, 20 Sep 2009 12:07:19 +0300

 A bit over a year ago I fixed one msdosfs problem resulting in "buf
 mem pool index 23", but that manifested itself already at mount time.
 It was due to unexpected values in bpb.  I'm pretty sure this one is too.

 You should be able to debug the problem fairly easily using rump_msdos
 (but that doesn't exist out-of-the-box on NetBSD 4.0.  It, however,
 should be possible to use rump from -current and fs-utils to recreate
 the problem).  In any case, this PR is a textbook example of why to not
 mount untrusted file system images with in-kernel drivers ...

From: "Greg A. Woods" <woods@planix.com>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: kern/38121 ("panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image)
Date: Mon, 18 Apr 2011 12:46:14 -0700

 --pgp-sign-Multipart_Mon_Apr_18_12:46:13_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 At Sat, 19 Sep 2009 21:09:49 +0000 (UTC), dholland@NetBSD.org wrote:
 Subject: Re: kern/38121 ("panic: buf mem pool index 23" crash apparently ca=
 used by mounting msdos floppy image)
 >=20
 > Have you tried this on 5.0?

 I've just tried the exact same procedure using the same image files and
 update programs on a 5.1_STABLE system running under VirtualBox.

 The results are less dramatic, but no more encouraging.

 The good news is that there's no kernel crash, yet.

 However the msdos filesystem image is still apparently corrupted by the
 operation, or at least fsck_msdos(8) claims that it has been corrupted.

 fsck_msdos also claims to fix it, but I'm not convinced.

 	# cp DRDFLASH.IMG 2nd-msdos-test.img
 	# vnconfig -v -c vnd0 2nd-msdos-test.img
 	vnd0: mbr partition exceeds disk size
 	/dev/rvnd0d: 1474560 bytes on 2nd-msdos-test.img
 	# fsck -t msdos vnd0a
 	** /dev/rvnd0a
 	** Phase 1 - Read and Compare FATs
 	** Phase 2 - Check Cluster Chains
 	** Phase 3 - Checking Directories
 	** Phase 4 - Checking for Lost Files
 	5 files, 1302 free (2605 clusters)
 	# mount -t msdos /dev/vnd0a /floppy
 	# cp BIOSA21.exe /floppy
 	# sync
 	# sync
 	# umount /floppy
 	# fsck -t msdos -y vnd0a
 	** /dev/rvnd0a
 	** Phase 1 - Read and Compare FATs
 	Cluster 245 is marked free in FAT 0, but continues with cluster 246 in FAT=
  1
 	Use continuation from FAT 1? [yn] yes
 	[[ ... repeated for every cluster between ... ]]
 	Cluster 1023 is marked free in FAT 0, but continues with cluster 1024 in F=
 AT 1
 	Use continuation from FAT 1? yes
 	** Phase 2 - Check Cluster Chains
 	** Phase 3 - Checking Directories
 	** Phase 4 - Checking for Lost Files
 	Update FATs? yes
 	Unable to write FAT (Read-only file system)
 	***** FILE SYSTEM WAS MODIFIED *****
 	ksh: exit code: 8
 	# mount -t msdos /dev/vnd0a /floppy
 	# ls -l /floppy
 	total 728
 	-rwxr-xr-x  1 root  wheel      39 Feb  1  2006 autoexec.bat
 	-rwxr-xr-x  1 root  wheel  620776 Apr 18 12:20 biosa21.exe
 	-rwxr-xr-x  1 root  wheel   66785 Jan  7  1999 command.com
 	-r-xr-xr-x  1 root  wheel   24810 Jan  7  1999 ibmbio.com
 	-r-xr-xr-x  1 root  wheel   30880 Jan  7  1999 ibmdos.com
 	# rm /floppy/biosa21.exe
 	# sync
 	# sync
 	# umount /floppy
 	# fsck -t msdos -y vnd0a
 	** /dev/rvnd0a
 	** Phase 1 - Read and Compare FATs
 	** Phase 2 - Check Cluster Chains
 	** Phase 3 - Checking Directories
 	** Phase 4 - Checking for Lost Files
 	Lost cluster chain at cluster 1024
 	434 Cluster(s) lost
 	Reconnect? yes
 	No LOST.DIR directory
 	Clear? yes
 	Update FATs? yes
 	Unable to write FAT (Read-only file system)
 	***** FILE SYSTEM WAS MODIFIED *****
 	ksh: exit code: 8

 Without expert examination of the MS-DOS filesystem image at various
 stages, something I might have had the expertise and energy to do
 fifteen years ago but no longer, it doesn't seem clear to me whether the
 bugs are in the filesystem code, or in fsck_msdos(8), or both.

 BTW, if I repeat the procedure, but also create a "LOST.DIR" directory
 on the floppy as is suggested by fsck_msdos(8), then its initial run
 also deletes the directory:

 	** Phase 3 - Checking Directories
 	/LOST.DIR starts with free cluster
 	Remove? yes

 At one point I ended up with an image which fsck_msdos(8) repeatedly did
 the same thing over and over again, so then I created a "LOST.DIR"
 directory and it finally re-connected a file there, but not the removed
 file -- only about half of it:

 	Cluster 1624 continues with cluster 1625 in FAT 0, but is marked free in F=
 AT 1
 	Use continuation from FAT 0? yes
 	Cluster 1625 is marked as EOF in FAT 0, free in FAT 1
 	use FAT 0's entry? yes
 	** Phase 2 - Check Cluster Chains
 	** Phase 3 - Checking Directories
 	** Phase 4 - Checking for Lost Files
 	Lost cluster chain at cluster 1024
 	602 Cluster(s) lost
 	Reconnect? yes
 	Update FATs? yes
 	Unable to write FAT (Read-only file system)
 	***** FILE SYSTEM WAS MODIFIED *****
 	ksh: exit code: 8
 	# fsck -t msdos -y vnd0a
 	# mount -t msdos /dev/vnd0a /floppy
 	# ls -l /floppy
 	total 122
 	-rwxr-xr-x  1 root  wheel     39 Feb  1  2006 autoexec.bat
 	-rwxr-xr-x  1 root  wheel  66785 Jan  7  1999 command.com
 	-r-xr-xr-x  1 root  wheel  24810 Jan  7  1999 ibmbio.com
 	-r-xr-xr-x  1 root  wheel  30880 Jan  7  1999 ibmdos.com
 	drwxr-xr-x  1 root  wheel    512 Apr 18 12:36 lost.dir
 	# ls -l /floppy/lost.dir/
 	total 301
 	arwxr-xr-x  1 root  wheel  308224 Dec 31  1969 1024
 	# ls -l BIOSA21.exe
 	-rw-r--r--  1 root  wheel  620776 Feb  9  2007 BIOSA21.exe

 I guess we could close this PR # 38121 and open a new one with this
 message, unless maybe we just change the synopsis to reflect the current
 state of things in netbsd-5?

 --=20
 						Greg A. Woods

 +1 250 762-7675                                RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>      Secrets of the Weird <woods@weird.com>

 --pgp-sign-Multipart_Mon_Apr_18_12:46:13_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)

 iD8DBQBNrJUFZn1xt3i/9H8RAiCrAJ0XO4YuHyGXBzgam6qGNEp4YrQScwCgv/NI
 eETTE7IRp+ipKjcJGPhVfpw=
 =dQCx
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Mon_Apr_18_12:46:13_2011-1--

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 18 Apr 2011 23:53:10 +0000
State-Changed-Why:
no more crash, but corrupts the fs. not sure if that counts as an improvement
or not.



From: "Greg A. Woods" <woods@planix.com>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: kern/38121 ("panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image)
Date: Tue, 19 Apr 2011 20:23:30 -0700

 --pgp-sign-Multipart_Tue_Apr_19_20:23:29_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 FYI I've just managed to trigger the panic again.

 This time I had done approximately:

     cp DRDFLASH.IMG 4th-test.img
     vnconfig  -c vnd0 4th-test.img
     fsck_msdos -y /dev/rvnd0a
     mount -t msdos /dev/vnd0a /floppy
     mkdir /floppy/LOST.DIR
     cp BIOSA21.EXE /floppy/PE2650-A21.EXE	# testing long name mangle
     ls -l /floppy
     umount /floppy
     fsck_msdos -y /dev/rvnd0a
     vnconfig -u vnd0
     vnconfig  -c vnd0 4th-test.img
     fsck_msdos -y /dev/rvnd0a

 I'm guessing the key to the cause of the crash is that I copied the BIOS
 update program to the MS-DOS FS with a long name, which is probably also
 what I did when I first encountered this bug.

 I don't know why it didn't crash this time until I tried to read the
 file back again after first having completely unmounted and re-mounted
 the filesystem image.

 The rest is a cut&paste from my xterm (the fsck output is more than the
 number of lines I allow for scroll-back so the exact commands above are
 lost):

 	Use continuation from FAT 1? yes
 	Cluster 1022 is marked free in FAT 0, but continues with cluster 1023 in F=
 AT 1
 	Use continuation from FAT 1? yes
 	Cluster 1023 is marked free in FAT 0, but continues with cluster 1024 in F=
 AT 1
 	Use continuation from FAT 1? yes
 	** Phase 2 - Check Cluster Chains
 	** Phase 3 - Checking Directories
 	** Phase 4 - Checking for Lost Files
 	Update FATs? yes
 	Unable to write FAT (Read-only file system)
 	***** FILE SYSTEM WAS MODIFIED *****
 	ksh: exit code: 8
 	# mount -t msdos /dev/vnd0a /floppy
 	# ll /floppy
 	total 728
 	  308   1 -rwxr-xr-x  1 root  wheel      39 Feb  1  2006 autoexec.bat
 	  306  66 -rwxr-xr-x  1 root  wheel   66785 Jan  7  1999 command.com
 	  304  25 -r-xr-xr-x  1 root  wheel   24810 Jan  7  1999 ibmbio.com
 	  305  31 -r-xr-xr-x  1 root  wheel   30880 Jan  7  1999 ibmdos.com
 	35872   1 drwxr-xr-x  1 root  wheel     512 Apr 19 19:43 lost.dir
 	  309 607 -rwxr-xr-x  1 root  wheel  620776 Apr 19 19:43 pe2650~1.exe
 	# cmp BIOSA21.exe /floppy/PE2650-A21.EXE
 	cmp: /floppy/PE2650-A21.EXE: No such file or directory
 	ksh: exit code: 2
 	# cmp BIOSA21.exe /floppy/PE2650*.EXE
 	cmp: /floppy/PE2650*.EXE: No such file or directory
 	ksh: exit code: 2
 	# cmp BIOSA21.exe /floppy/PE2650~1.EXE
 	panic: buf mem pool index 23
 	Begin traceback...
 	End traceback...
 =09
 	dumping to dev 0,1 offset 2000263
 	dump 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 =
 succeeded
 =09
 =09
 	rebooting...

 I still don't understand why fsck_msdos(8) is claiming the filesystem is
 read-only in some instances.  It doesn't always fail though -- I've had
 it successfully reconnect a badly removed file into the LOST.DIR
 directory.

 I'm not sure what happened to the traceback there either, but at least
 it seems as if a kernel core was captured:


 	Checking for core dump...
 	savecore: reboot after panic: panic: buf mem pool index 23
 	Apr 19 19:58:37  savecore: reboot after panic: panic: buf mem pool index 23
 	savecore: system went down at Tue Apr 19 19:45:18 2011
 	savecore: /var/crash/bounds: No such file or directory
 	savecore: writing compressed core to /var/crash/netbsd.0.core.gz
 	savecore: writing compressed kernel to /var/crash/netbsd.0.gz
 	savecore: (null): Bad address
 	Apr 19 19:58:39  savecore: (null): Bad address

 (also I don't know why savecore failed to copy the kernel....)


 This looks semi-correct though:

 	# gdb /netbsd /var/crash/netbsd.0.core
 	GNU gdb 6.5
 	Copyright (C) 2006 Free Software Foundation, Inc.
 	GDB is free software, covered by the GNU General Public License, and you a=
 re
 	welcome to change it and/or distribute copies of it under certain conditio=
 ns.
 	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--netbsdelf"...(no debugging symbols found)
 =09
 	"/var/crash/netbsd.0.core" is not a core dump: File format not recognized
 	(gdb) target kvm /var/crash/netbsd.0.core
 	#0  0xc05d005c in cpu_reboot ()
 	(gdb) where
 	#0  0xc05d005c in cpu_reboot ()
 	#1  0xc04fa500 in panic ()
 	#2  0xc0531c34 in buf_mempoolidx ()
 	#3  0x00000017 in ?? ()
 	#4  0xd3cdd7ec in ?? ()
 	#5  0xc0533258 in allocbuf ()
 	Previous frame inner to this frame (corrupt stack?)
 	(gdb)=20

 Hmmm.... perhaps I can do better with the debug kernel and sources NFS
 mounted:


 # gdb $MY_OBJDIR/usr/src/sys/arch/i386/compile/GENERIC/netbsd.gdb
 GNU gdb 6.5
 Copyright (C) 2006 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 condition=
 s.
 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--netbsdelf"...
 (gdb) target kvm /var/crash/netbsd.0.core
 #0  0xc05d005c in cpu_reboot (howto=3D260, bootstr=3D0x0)
     at /rest/work/woods/m-NetBSD-5/sys/arch/i386/i386/machdep.c:944
 944                     dumpsys();
 (gdb) where
 #0  0xc05d005c in cpu_reboot (howto=3D260, bootstr=3D0x0)
     at /rest/work/woods/m-NetBSD-5/sys/arch/i386/i386/machdep.c:944
 #1  0xc04fa500 in panic (fmt=3D0xc0b8ea8f "buf mem pool index %d")
     at /rest/work/woods/m-NetBSD-5/sys/kern/subr_prf.c:253
 #2  0xc0531c34 in buf_mempoolidx (size=3D0)
     at /rest/work/woods/m-NetBSD-5/sys/kern/vfs_bio.c:620
 #3  0xc0533258 in allocbuf (bp=3D0xc24434e4, size=3D0, preserve=3D0)
     at /rest/work/woods/m-NetBSD-5/sys/kern/vfs_bio.c:628
 #4  0xc0534624 in getblk (vp=3D0xd3aabf28, blkno=3D10, size=3D0, slpflag=3D=
 0,=20
     slptimeo=3D0) at /rest/work/woods/m-NetBSD-5/sys/kern/vfs_bio.c:1247
 #5  0xc05347c7 in bio_doread (vp=3D0xd3aabf28, blkno=3D0, size=3D0, cred=3D=
 0xffffffff,=20
     async=3D0) at /rest/work/woods/m-NetBSD-5/sys/kern/vfs_bio.c:679
 #6  0xc0534a32 in bread (vp=3D0xd3aabf28, blkno=3D0, size=3D0, cred=3D0xfff=
 fffff,=20
     flags=3D0, bpp=3D0xd3cdd8b4)
     at /rest/work/woods/m-NetBSD-5/sys/kern/vfs_bio.c:738
 #7  0xc03919a5 in pcbmap (dep=3D0xd3defbb8, findcn=3D3, bnp=3D0xd3cdd914, c=
 np=3D0x0,=20
     sp=3D0x0) at /rest/work/woods/m-NetBSD-5/sys/fs/msdosfs/msdosfs_fat.c:2=
 63
 #8  0xc0396250 in msdosfs_bmap (v=3D0xd3cdd94c)
     at /rest/work/woods/m-NetBSD-5/sys/fs/msdosfs/msdosfs_vnops.c:1749
 #9  0xc054f753 in VOP_BMAP (vp=3D0xd3aa70c4, bn=3D2, vpp=3D0xd3cddac0,=20
     bnp=3D0xd3cddaa4, runp=3D0xd3cddac4)
     at /rest/work/woods/m-NetBSD-5/sys/kern/vnode_if.c:1459
 #10 0xc0554db2 in genfs_getpages (v=3D0xd3cddb00)
     at /rest/work/woods/m-NetBSD-5/sys/miscfs/genfs/genfs_io.c:501
 #11 0xc054f3e5 in VOP_GETPAGES (vp=3D0xd3aa70c4, offset=3D0, m=3D0xd3cddc8c=
 ,=20
     count=3D0xd3cddc94, centeridx=3D0, access_type=3D1, advice=3D0, flags=
 =3D2)
     at /rest/work/woods/m-NetBSD-5/sys/kern/vnode_if.c:1726
 #12 0xc0476b87 in uvn_get (uobj=3D0xd3aa70c4, offset=3D0, pps=3D0xd3cddc8c,=
 =20
     npagesp=3D0xd3cddc94, centeridx=3D0, access_type=3D1, advice=3D0,=20
     flags=3D<value optimized out>)
     at /rest/work/woods/m-NetBSD-5/sys/uvm/uvm_vnode.c:188
 #13 0xc045ee9c in uvm_fault_internal (orig_map=3D0xd3d060d8, vaddr=3D314867=
 7120,=20
     access_type=3D1, fault_flag=3D0)
     at /rest/work/woods/m-NetBSD-5/sys/uvm/uvm_fault.c:1505
 #14 0xc05d352e in trap (frame=3D0xd3cddd48)
     at /rest/work/woods/m-NetBSD-5/sys/arch/i386/i386/trap.c:667
 #15 0xc010ccd7 in calltrap ()
 (gdb)=20


 Please do let me know if further information is required.


 (NOTE:  my line numbers may be a bit off in some places, but so far as I
 know none of my local changes can possibly affect MSDOSFS code.)

 Copies of my source tree, the kernel and core images, etc. can all be
 made available as necessary.

 --=20
 						Greg A. Woods

 +1 250 762-7675                                RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>      Secrets of the Weird <woods@weird.com>

 --pgp-sign-Multipart_Tue_Apr_19_20:23:29_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)

 iD8DBQBNrlGxZn1xt3i/9H8RAjy0AKDSffm3+d2u7yZmAvuCf+JqhsEzzACg0Y44
 dKlH+TATbh1ekDxw2m+V2vk=
 =wwh4
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Tue_Apr_19_20:23:29_2011-1--

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.