Re: MSDOSFS woes
On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: Gang, :-) While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. Interesting. Were you running with INVARIANTS on? I got a completely reproducible kernel panic when running your script, regardless of whether I used -F 12 or -F 16; it was trying to write file data past the end of the disk, and causing kernel memory pool to become corrupted. I was seeing Memory modified after free errors, with blocks most recently used by GEOM and file desc. Were you running the script with INVARIANTS on? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MSDOSFS woes
On Wed, Aug 06, 2003 at 08:05:52PM +1000, Tim Robbins wrote: On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: Gang, :-) While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. Interesting. Were you running with INVARIANTS on? I got a completely reproducible kernel panic when running your script, regardless of whether I used -F 12 or -F 16; it was trying to write file data past the end of the disk, and causing kernel memory pool to become corrupted. I was seeing Memory modified after free errors, with blocks most recently used by GEOM and file desc. Were you running the script with INVARIANTS on? My kernel config includes the GENERIC config which has INVARIANTS on. Further analysis of the problem shows that there are actually two problems. First problem is with newfs_msdos(8) (and kernel part of MSDOSFS). newfs_msdos(8) sometimes results in a bad file system lying about the number of available sectors (recorded in sector 0) than is actually available, as was demonstrated by Bruce Evans (and I've been able to reproduce this). Sometimes, this results in warnings from MSDOSFS on a console, immediately followed by a panic. Sometimes, I also saw the Memory modified after free. IIRC, I ended up with a conclusion that -s arguments 32M are unsafe with newfs_msdos(8). Second problem is with vnode-backed md(4) devices, and it is not MSDOSFS-specific. I've been able to reproduce the wdrain lockup after attempting to newfs(8) and fill (with cpio(1)) an 11MB-only vnode-backed UFS file system yesterday. Sometimes it just works, and sometimes it causes a lock-up. I asked Poul-Henning to look into this issue in a private message to him with more details and a test case. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: MSDOSFS woes
On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: Gang, :-) While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. The issue is not IA64 specific, both machines in question are i386. The following script makes my machines unhappy: EFISZ=131072 dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ md=`mdconfig -a -t vnode -f $BASE/$EFIPART` newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md mount -t msdosfs /dev/$md /mnt dd if=/dev/zero of=/mnt/foo Changing to the -F 16 does not take any (good) effect. Anyone is interested in narrowing it down? I've also seen this happening on my Athlon XP system running -CURRENT. I presumed it was the deadlock in vnode-backed md disks. It seems that when a lot of disk activity occurs on the md partition, the process stops - this is on a 30GB image containing UFS2 partitions /dev/md0s1[a,d,e]. Attempting to reboot results in the message 'processes would not die - ps axl advised', I had to reset the computer because nothing more happened. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MSDOSFS woes
On Sat, Aug 02, 2003 at 05:00:45PM +0100, Bruce Cran wrote: On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote: Gang, :-) While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. The issue is not IA64 specific, both machines in question are i386. The following script makes my machines unhappy: EFISZ=131072 dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ md=`mdconfig -a -t vnode -f $BASE/$EFIPART` newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md mount -t msdosfs /dev/$md /mnt dd if=/dev/zero of=/mnt/foo Changing to the -F 16 does not take any (good) effect. Anyone is interested in narrowing it down? I've also seen this happening on my Athlon XP system running -CURRENT. I presumed it was the deadlock in vnode-backed md disks. It seems that when a lot of disk activity occurs on the md partition, the process stops - this is on a 30GB image containing UFS2 partitions /dev/md0s1[a,d,e]. Attempting to reboot results in the message 'processes would not die - ps axl advised', I had to reset the computer because nothing more happened. Yes, the same here. And I have just been able to reproduce this with only a 16MB MS-DOS file system on a vnode backed md(4) device. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: MSDOSFS woes
On Sat, 2 Aug 2003, Ruslan Ermilov wrote: While working with Marcel on a bootable CD-ROM for IA64 issue, I've stumbled upon the following problem. I needed to increase the size of the EFI partition (which is an MS-DOS file system) to 64M, and that made two of my machines stuck solidly -- a lot of process are waiting on the wdrain event. The issue is not IA64 specific, both machines in question are i386. The following script makes my machines unhappy: EFISZ=131072 dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ md=`mdconfig -a -t vnode -f $BASE/$EFIPART` newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md mount -t msdosfs /dev/$md /mnt dd if=/dev/zero of=/mnt/foo Try fixing newfs_msdos so that the -s option actually works, or adjusting sizes. Otherwise the file system doesn't fit on the device: Filesystem1024-blocksUsed Avail Capacity iused ifree %iused Mounted on /dev/md065568 64 65504 0% 512 0 100% /mnt so bad things should be expected to happen when msdosfs runs off the end. The kernel should handle this gracefully, but might not. newfs has an end-of-partition check to avoid this problem. I still get assorted panics and strange behaviour after increasing the device size, but suspect unrelated bugs from version skew. The strangeness was the second dd failing with EINVAL for one run and with the correct error ENOSPC for another. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
