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:
(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.