NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: 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@localhost 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@localhost>
 Planix, Inc. <woods%planix.com@localhost>      Secrets of the Weird 
<woods%weird.com@localhost>
 
 --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--
 


Home | Main Index | Thread Index | Old Index