Opened 9 years ago
Last modified 4 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 Changed 9 years ago by
comment:2 Changed 9 years ago by
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 Changed 9 years ago by
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 Changed 9 years ago by
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 ...
What needs to be achieved is that the linker will make NO attempt to link in floating emulation libraries.
comment:5 Changed 9 years ago by
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
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. I know the FORMAT routine uses it when showing the % complete. Not sure about CHKDSK. 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.
comment:6 Changed 9 years ago by
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 Changed 9 years ago by
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 Changed 8 years ago by
| Milestone: | → Future |
|---|---|
| Priority: | major → Feedback pending |
| Severity: | → highest |
any news about that when using latest alpha?
comment:9 Changed 8 years ago by
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 Changed 4 years ago by
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 Changed 4 years ago by
| Owner: | set to martini |
|---|---|
| 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.