Opened 9 years ago
Last modified 5 years ago
#17 assigned defect
Trap d in dumpfs
| Reported by: | abwillis | Owned by: | martini |
|---|---|---|---|
| Priority: | Feedback Pending | Milestone: | Future |
| Component: | IFS | Version: | |
| Severity: | highest | Keywords: | |
| Cc: |
Description
I just updated my svn to 101 and built it. I am booted from JFS HDD and find that formating fat32 causes a trap d. The format was successful even on a 160G drive (149G free after format which is consistent with when it is formated on windows). I also found that when I booted with the new fat32 files in place that I got a trap d on boot in dumpfs.ifs at the point that the desktop should have been about to come up. I ended up just remarking out the dumpfs so that I could boot and test the new fat32. dumpfs did not have any issues with the previous fat32.
Change History (12)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
OK, after much playing around with various compiler switches, I have found that both the issues I was seeing (dumpfs trap and trap on format) are related to cachef32.exe. Once I disable cachef32.exe, I no longer have the traps. I do find that on the format, I have to format twice with my flash drives. The first time it throws and error on writing the label and a dir on an 8G stick gives me 32M, if I eject the drive and reinsert it is seen as 8G but chkdsk shows errors. If I instead of ejecting, do a second format it goes through clean and a dir now show the 8G and chkdsk is clean.
comment:3 by , 9 years ago
The following makes it so that I do not have to format it twice as mentioned above by essentially formatting it twice for me and I know longer get an error on writing to the label I had always gotten on the first format. I also added some clean rules and added the fpi87 that Lars had mentioned in another thread... I have actually added it just about everywhere I think.
Index: format.c
===================================================================
--- format.c (revision 101)
+++ format.c (working copy)
@@ -425,13 +425,38 @@
int SectorStart = dp.ReservedSectCount + (i * dp.FatSize );
write_sect ( hDevice, SectorStart, dp.BytesPerSect, pFirstSectOfFat, 1 );
}
-
+/*
//printf("001\n");
// free memory
mem_free ( (void *)pFirstSectOfFat, dp.BytesPerSect );
mem_free ( (void *)pFAT32FsInfo, dp.BytesPerSect );
mem_free ( (void *)pFAT32BootSect, dp.BytesPerSect );
+*/
+// /////////////////////////////
+ remount_media ( hDevice );
+ // First zero out ReservedSect + FatSize * NumFats + SectorsPerCluster
+ SystemAreaSize = (dp.ReservedSectCount+(dp.NumFATs*dp.FatSize) + dp.SectorsPerCluster);
+ zero_sectors( hDevice, 0, dp.BytesPerSect, SystemAreaSize); // &dgDrive);
+ printf ( "Clearing out %d sectors for \nReserved sectors, fats and root cluster...\n", SystemAreaSize );
+ printf ( "Initialising reserved sectors and FATs...\n" );
+ // Now we should write the boot sector and fsinfo twice, once at 0 and once at the backup boot sect position
+ for ( i=0; i<2; i++ )
+ {
+ int SectorStart = (i==0) ? 0 : BackupBootSect;
+ write_sect ( hDevice, SectorStart, dp.BytesPerSect, pFAT32BootSect, 1 );
+ write_sect ( hDevice, SectorStart+1, dp.BytesPerSect, pFAT32FsInfo, 1 );
+ }
+ //printf("000\n");
+ // Write the first fat sector in the right places
+ for ( i=0; i<dp.NumFATs; i++ )
+ {
+ int SectorStart = dp.ReservedSectCount + (i * dp.FatSize );
+ write_sect ( hDevice, SectorStart, dp.BytesPerSect, pFirstSectOfFat, 1 );
+ }
+// ////////////////////////////////
+
+
// The filesystem recogniser in Windows XP doesn't use the partition type - in can be
// set to pretty much anything other Os's like Dos (still useful for Norton Ghost!) and Windows ME might,
// so we could fix it here
@@ -466,6 +492,11 @@
fflush(stdout);
//printf("010\n");
+ // free memory
+ mem_free ( (void *)pFirstSectOfFat, dp.BytesPerSect );
+ mem_free ( (void *)pFAT32FsInfo, dp.BytesPerSect );
+ mem_free ( (void *)pFAT32BootSect, dp.BytesPerSect );
+
return( TRUE );
}
Index: makefile.wcc
===================================================================
--- makefile.wcc (revision 101)
+++ makefile.wcc (working copy)
@@ -7,7 +7,7 @@
# create OS/2 binaries
OBJS1=ufat32.obj format.obj os2.obj msg.obj chkdsk.obj
OBJS2=format.obh os2.obh msg.obh
-COPT=-3s -s -sg -hw -mf -od -zq -q -i=. -i=.. -i=..\include -i=$(%WATCOM)\h -i=$(%WATCOM)\h\os2
+COPT=-3s -fpi87 -s -sg -hw -mf -od -zq -q -i=. -i=.. -i=..\include -i=$(%WATCOM)\h -i=$(%WATCOM)\h\os2
TARGETS=ufat32.dll fat32fmt.exe ufat32.sym fat32fmt.sym
SYS=os2v2
!else
@@ -57,7 +57,7 @@
@for %e in ($(OBJS2)) do @%append $^@ FILE %e
clean: .symbolic
- @del *.obj *.obh *.lnk *.wmp *.map >nul 2>&1
+ @del *.obj *.obh *.lnk *.wmp *.map *.dll *.exe *.sym >nul 2>&1
comment:4 by , 9 years ago
the -fpi87 switch was for the Microsoft 16-bit C-compiler version 6.0 which was what was used for the distributed version of FAT32.
But ok, I just checked the Watcom help and it does in fact specify the very same switch for the 16-bit as well as for the 32-bit compiler. Sometimes things are easy ...
comment:5 by , 9 years ago
I am booted from JFS HDD and find that formating fat32 causes a trap d.
What was the cluster size? 64k cluster (128 sectors) can cause a trap. But it is not supported so far.
I also found that when I booted with the new fat32 files in place that I got a trap d on boot in dumpfs.ifs at the point that the desktop should have been about to come up. I ended up just remarking out the dumpfs so that I could boot and test the new fat32. dumpfs did not have any issues with the previous fat32.
Hm, strange. Though, I never used dumpfs, so didn't see such problem. Maybe, it consider dumpfs a fat32 drive, mounts it and tries to work with it? I made some changes to FS_MOUNT IFS routine, so it may trying to mount it.
+COPT=-6 -bt=os2 -ml -ecw -s -zdp -zfp -zgp -zls -zl -zp=1 -zu -ze -zq -od -of+ -q -d16BITS -dWATCOM -i=$(%WATCOM)\h -i=$(%WATCOM)\h\os21x -i=. -i=.. -i=..\include
-6 is "generate i686 instructions" don't know why. On 16-bit IFS driver, I see no reason to use it.
-bt=os2 is "generate OS/2 code". Also, don't see a sense to use it, as I use "system os2 dll" linker directive
To Lars: So, -fpi87 helps? What is the principal difference between using FPU and its emulation? So, it won't throw a floating point exceptions? Really, I think, better to eliminate using the FP at all. And yes, the FP emulation was used in fat32.dll, not the IFS driver. I know that using FP is not recomended in drivers, but here is not a driver, but an utility DLL. I know the FORMAT routine uses it when showing the % complete. Not sure about CHKDSK. But the IFS (either dumpfs or fat32) could trap trying to mount a FS in inconsistent state.
PS: Also, didn't touched cachef32.exe and other utilities at all.
Also, why the next patch? The remount_media() is in fact DSK_REDETERMINEMEDIA ioctl, it needs to be done after format is complete. Before FORMAT or CHKDSK, you must issue the DSK_BEGINFORMAT, to remount the volume before formatting/checking IFS's in DASD mode. After all, you make DSK_REDETERMINEMEDIA, which remounts it in normal mode again (where all FS structures are valid). Trying to zero-out structures (including the boot block) after remounting the drive can lead to a trap.
PPS: What filesystem was on the drive you are formatting? Dumpfs? Did you install both a fat32.dll and the new fat32.ifs? (The cachef32.exe and other utilities don't changed. only recompiled, so you may test with old utils, will it trap or not?) The fat32.ifs is also needed because it was fixed to support reformatting without a reboot.
comment:6 by , 9 years ago
The first diff was just an attempt to get rid of the trap, I chose the settings I did based on Lars' comment in another bug. They did not help so you'll notice in the second patch I only have the -fp87 see Lars' comment 4. All my traps are gone since I disabled the cache... I am not sure of the cluster size, I let it default. I had it with 8G, 64G, and 160G drives. I have found that my patch is not working as well as I had originally thought. I can read and write to from OS/2 with it but Windows I found has a problem with it then. The reason I had done it was that I was having to format the drive twice for it to be able to read/write to it. The second time would go smoothly but the first time it fails out when it goes to write the label. I found that moving the frees allowed the label function to complete without error. I was just experimenting to see what I could find. I replaced all files... in fact, I suppose I should put the original cachef32 in place to make sure there is not just a problem in my build. The drives I formatted from were fat32, jfs, hpfs, and ntfs.
comment:7 by , 9 years ago
about -fpi87: I haven't tried out but the difference is that it directly inlines Floating Point instructions in the code instead of linking in a library. It's pretty obvious that linking in the library causes the problems in ticket #16.
comment:8 by , 8 years ago
| Milestone: | → Future |
|---|---|
| Priority: | major → Feedback pending |
| Severity: | → highest |
any news about that when using latest alpha?
comment:9 by , 8 years ago
I reloaded my system and have yet to get a copy of dumpfs going. I'll try to get that setup to test.
comment:10 by , 5 years ago
Hi Andy
Is there any feedback about this issue. I'm just giving a hand with the tickets here to see if we can close the old ones.
Regards
comment:11 by , 5 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
I tried the following but had made no difference on either the trap it causes in dumpfs nor did it stop the trap when doing a format, putting it here just to document the attempt.