Hello,
I did some search about the
http://sourceforge.net/tracker/index.php?func=detail&aid=2901916&group_id=5109&atid=105109
problem and find one potential reason for that: in function to convert from sft
to fnode, a value is used before being initialised. This lead to a drive to not
be considered as FAT32 despite it is (or vice-versa).
Here is the diff:
--- old/ke2039/kernel/fatfs.c 2009-07-18 10:05:28.000000000 +0200
+++ new/ke2039/kernel/fatfs.c 2011-03-22 00:52:31.716427584 +0100
@@ -1723,15 +1723,15 @@
fnp->f_dir.dir_attrib = sftp->sft_attrib;
fmemcpy(fnp->f_dir.dir_name, sftp->sft_name, FNAME_SIZE + FEXT_SIZE);
fnp->f_dir.dir_time = sftp->sft_time;
fnp->f_dir.dir_date = sftp->sft_date;
fnp->f_dir.dir_size = sftp->sft_size;
+ fnp->f_dpb = sftp->sft_dcb;
setdstart(fnp->f_dpb, &fnp->f_dir, sftp->sft_stclust);
fnp->f_diridx = sftp->sft_diridx;
fnp->f_dirsector = sftp->sft_dirsector;
- fnp->f_dpb = sftp->sft_dcb;
fnp->f_offset = sftp->sft_posit;
fnp->f_cluster = sftp->sft_cuclust;
#ifdef WITHFAT32
fnp->f_cluster_offset = sftp->sft_relclust |
((ULONG)sftp->sft_relclust_high << 16);
Another problem I found, but that is not related to previous one, is the clock
driver stack being too small. As clock driver calls int 1A, I suppose the stack
need depends on used BIOS (and perhaps on potential TSR). I increase the block
driver stack also because I found it too be very near to the limit in my case
also (but without overflowing as for the clock one). I do not know if there is
some documentation about what minimal stack should be, the only similar thing I
remember having read is this page about CWSDPMI
http://homer.rice.edu/~sandmann/cwsdpmi/r5bug01.txt
--- old/ke2039/kernel/kernel.asm 2009-07-12 23:19:34.000000000 +0200
+++ new/ke2039/kernel/kernel.asm 2011-03-20 13:20:46.000000000 +0100
@@ -722,16 +722,18 @@
init_end:
segment _DATA
; blockdev private stack
global blk_stk_top
- times 192 dw 0
+; times 192 dw 0
+ times 256 dw 0
blk_stk_top:
; clockdev private stack
global clk_stk_top
- times 64 dw 0
+; times 64 dw 0
+ times 128 dw 0
clk_stk_top:
; Dynamic data:
; member of the DOS DATA GROUP
; and marks definitive end of all used data in kernel data segment
Hope this will help,
Regards,
Damien
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Freedos-kernel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
