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