Re: kern/38121 ("panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image)

To: kern-bug-people%netbsd.org@localhost,gnats-admin%netbsd.org@localhost,netbsd-bugs%netbsd.org@localhost,"Greg A. Woods" <woods%planix.com@localhost>
Subject: Re: kern/38121 ("panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image)
From: "Greg A. Woods" <woods%planix.com@localhost>
Date: Wed, 20 Apr 2011 03:25:03 +0000 (UTC)
The following reply was made to PR kern/38121; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
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@localhost>
 Planix, Inc. <woods%planix.com@localhost>      Secrets of the Weird 
<woods%weird.com@localhost>
 
 --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--
Prev by Date: NetBSD Nightly Trouble Ticket Report
Next by Date: Re: kern/39676 (cpu est sysctl nodes disappear when booting from battery)
Previous by Thread: Re: kern/38121 ("panic: buf mem pool index 23" crash apparently caused by mounting msdos floppy image)
Next by Thread: Re: port-macppc/38243 (named (bind9) bundled with netbsd 4.0 rlease hangs on startup)
Indexes:
Home | Main Index | Thread Index | Old Index