> > DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of > > a NULL navc pointer. > If so, please submit some code to make the kernel crash. > if not, shut up.
I did. Read and shut up: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/format/format-0.91r.txt > > Maybe saturation would be better. How do other DOSes handle this? > maybe would be better that YOU check other DOS'es behaviour BEFORE Buy me another DOS or shut up. > please provide exact code sequence where it DOES return nonsense - and > I'll fix it. (we are talking about ke2035 !!) That translates to: Provide a fix and you will have provided a fix. Helpful. > there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. > end of story. Compiler weakness :-P. > if sectors or heads are > 64K the LBA BIOS is probably buggy. > and IMO it's better to refuse to work with a buggy BIOS then to > try to trash a users disk. Alternative explanation: BIOS probably did not care to initialize the values because they are not needed for LBA access anyway. > > or if totalSectHigh is nonzero. > this will be relevant when disk (arrays) are larger then > 2 TB (not that far away) > but then we good old partitioning scheme stops to make sense, > and it's better not to touch these disks at all. I vote for: Then you better only use the first 2 TB. But current situation is: Use only the first 1024 CYLINDERS and stop using LBA at all. Certainly wrong. If you think it is risky to access such disks, accessing them in CHS mode will be risky, too. And you will probably have only a fraction of the DOS partitions reachable at all if you drop to CHS mode. Of course you could drop even further, to "this is no disk". I think the code can be "forgiving" here, because: flash disks and similar devices sometimes have odd BIOS support, but because we do not only read LBA information but also partition tables, REALLY broken BIOSes are still safely excluded. > > If buffer is exactly aligned, transfer limit should probably be > nonsense. you simply cant issue a read request to DOS > 0xffff Thanks for telling, should probably be clarified in the DMA checker code. > > Track wrap protection and DMA wrap > > protection should be turned off (maybe add a SYS CONFIG variable!) > > for harddisks. > nonsense again: there's a specific field in EXT13 functions... I know that you cannot detect this. BUT on the other hand I believe that turning off track wrap protection and maybe also DMA wrap protection can help to significantly improve performance, so the user should be allowed to enable that - manually and at own risk. Sorry but I have no big test partitions where I could test that, so somebody else has to. Eric ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
