[Freedos-kernel] Re: Kernel bug parade / moving on
Hi Arkady! > EA> * 698 floppy change / floppy DMA boundary check should be moved from > EA> "int" 25/26 to the int 13 handler. > Hm. Probably I not very understand this request, but FreeDOS does all > DMA checks in dsk.c:LBA_Transfer(). Moving the check to int 13 means that DOS programs which use int 13 directly never have to worry about DMA boundaries. MS DOS provides this service. It also hooks int 13 to have more secure detection of disk changes (i.e. even if the disk change happens while some program uses int 13 directly - then only the int 13 handler and that program but not the kernel notices the change unless the kernel itself hooks the int 13 handler as well). > EA> * 1176 second floppy controller not detected. > FreeDOS detects second floppy drive presence through analyzing > "equipment list" (INT 11) ... Yes, sure, but I wrote about second floppy CONTROLLER. This is the thing to which you connect the third and possibly fourth floppy drive and which - I believe - can only be found in 808x PCs, not in newer models. Not sure if the BIOS has or needs special support for that as well. > EA> * 1630 int 21.4bxx should clear the high parts of the general 32 bit > ? _Why_ DOS "should" clear hight parts of 32-bit registers?! Because some programs would conceivably assume that the high parts are 0 instead of setting them to 0 manually. Check www.256b.com to see that DOS programs sometimes assume quite a lot of stuff about initial register values. > To make UMBs, DOS uses XMS services. Good point. Then UMBs on pre-286 PCs would need really special drivers. Anyway, you can tell the user that UMBs are almost impossible if you detect an 808x at boot time then (i.e. if the user tries to use UMBs then the error message can be more helpful: If 286+, suggest loading an XMS plus if needed an extra UMB or if 386+ EMM386 driver. If 808x, suggest giving up X-)). Same for HMA. If 286+, suggest loading an XMS driver, and otherwise tell the user that an HMA is impossible on that PC. > EA> * 1789 the builtin disk format (!) function causes weird kernel error > EA> message LBA-Transfer error... Sorry, there is a word missing in the above!! The builtin disk format function OF PKZIP causes weird kernel error message ... Eric --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel bug parade / moving on
Hi! 6-Июн-2004 00:47 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> * 698 floppy change / floppy DMA boundary check should be moved from EA> "int" 25/26 to the int 13 handler. This is also needed for later when EA> we want Win 3.1x /3 compatibility. Please comment on how hard it would EA> be to move the boundary check function. Hm. Probably I not very understand this request, but FreeDOS does all DMA checks in dsk.c:LBA_Transfer(). EA> * 1176 second floppy controller not detected. Am I right in writing EA> in the bug report that this can only affect 808x systems? How about EA> required BIOS support, if any? A solution could be to interpret the EA> "installed hardware" bitmask from the BIOS differently if CPU is 808x!? FreeDOS detects second floppy drive presence through analyzing "equipment list" (INT 11) in initdisk.c:ReadAllPartitionTable(). I know no other (defined) way, how to detect second floppy(ies), without accessing hardware directly - and equipment list was defined from the starting IBM PC. EA> * 1630 int 21.4bxx should clear the high parts of the general 32 bit EA> registers - of course this must check if CPU is 386 or better first. ? _Why_ DOS "should" clear hight parts of 32-bit registers?! EA> I think a CPU detection at boot time could also provide other advantages: EA> If CPU is 808x, you can disable HMA detection and stuff (but I believe EA> UMBs can be possible on 808x), To make UMBs, DOS uses XMS services. IF you have RAM in A000- region AND IF you write own driver, which will imitate the XMS (version 2.x), then DOS will able to reuse those RAM for UMB. Notwithstanding the CPU. By itself DOS doesn't deals with upper memory. EA> * 1789 the builtin disk format (!) function causes weird kernel error EA> message LBA-Transfer error... - Somebody already tried but could not EA> reproduce, so maybe this depends on the used hardware? The internal formating code (INT 21/440D/CL=42, also 0x13 Generic IOCTL Call) in dsk.c:Genblkdev() is bad. I already report this some years ago and now again prepare bugfix for it. --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Hi! 5-Июн-2004 11:22 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to [EMAIL PROTECTED]: >>> Well, looks like Bart is gone. Who now will manage the kernel >>> (reconcile patches, update CVS, release intermediate snapshots)? For [...] KJD> If there are no objections, then about once a week I will go KJD> through the kernel mailing list archives [I no longer assume I Not neccessary, I may repeat all my posts. Especially, they was not all. KJD> Is this acceptable? or is there someone else already doing this? KJD> wanting to do it? etc. Looks like no one other pretends to this role. --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: LBACache test results
> Hi, please do turn off HTML in your mail program - use only plain text: Sorry, I just reinstalled Windows and forgot to set OE back to Plain Text, it's on Plain Text now. > Why did you use STACKS=9,256 - how about STACKS=0,0 ??? Because STACKS=9,256 is a very common setting; I thought it was the best one. Anyway I should try that (STACKS=0,0) > In what way did you copy the same file 10 times? >From one directory to another on the same drive/partition > I think for test b) you need a bigger > LBAcache for that, something like THREE megabytes. Please try that (both > LBAcache and the writeback feature of SMARTDRV store WRITTEN data in the > cache. Therefore if you copy 1.2 MB disk -> disk, BOTH the source file and > the target file will be stored in the cache!). Good idea. > Thanks for re-testing already ;-). You're welcome. I like to help DOS related projects whenever the opportunity is right. > PS: If INTERLNK crashes FreeDOS, how about INTERSVR? And did it help to > - load no HIMEM / EMM386 > - use no XMS swapping FreeCOM > - use no UMBs / do not load DOS to HMA > - ...? I didn't bother with InterServer since it is useless without Interlink. I should test InterServer anyway, thanks for reminding me. I also tried diverse configs with same results. Anyway I should try more configs to see if IL is willing to work. > You just wrote "various contents" for config sys - but to get started, > an as fail-safe as possible config would be better. Sorry about that, I tried DEVICE=INTERLNK.EXE as the only line in CONFIG.SYS, then I added XMS drivers in subsequent tests. Still got Invalid Opcode (followed by a bunch of hexadecimal gibberish). In my PC 340, when I used FDXMS.SYS, the computer rebooted after loading InterLink. When I used Microsoft/IBM HIMEM.SYS, I got the Invalid Opcode, when I used no XMS driver on the PC 340, I got Invalid Opcode. IIRC, on my 386 both XMS drivers yielded Invalid Opcode. Anyway, I got a decent start on it, thanks for the tips, now we can go further with this on my Pentium Class PC 340 and my 386 SX. Heck, maybe we should later try File Maven, a freeware alternative to InterLink/InterServer, if IL/IS has no hope for FreeDOS. Justin --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel bug parade / moving on
Eric Auer wrote: Hi, while we have no real kernel maintainer right now (I assume Jeremy can at most find enough time to upload patches submitted by others, not for doing coding / testing himself), I think it would be good to review some old bugs before we move on to do new optimizations. Of course now that Arkady already has optimized things: If no new bugs get introduced those patches can of course be added. But I think we should focus on a bit of bug testing and fixing now for a while. I hope there are people on the list who can test some of the issues (i.e. have the affected type of software / hardware around!). YES !!! I also believe that we should focus in buf testing and fixing. We have most of what we need for a Version 1.0. Couldn't that be our goal? Alain PS. I became sudenly very much affraid that so close to the end, we could have FreeDOS to become some kind of _never_ended_ project. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: LBACache test results
Hi, please do turn off HTML in your mail program - use only plain text: Especially when mailing to the list, everybody otherwise gets TWO copies of the text (although only one mail, this is called "alternative" format), one in text and one in HTML. The HTML version marks every single line of text separately as being in Arial font etc.! If you use Outlook (which is crappy) you probably have to disable HTML mail for different address book entries separately or something. Why did you use STACKS=9,256 - how about STACKS=0,0 ??? Interesting results... all caches 2 MB. LBAcache, SMARTDRV, SMARTDRV/WriteBack a) 9 MB of cache misses: 75 / 84 / 78 / 81 seconds for none / LBAcache / SMARTDRV / S.D.W.B. respectively b) copying 1.2 MB 10 times in a row: 69 / 79 / 49 / 81 seconds for the same candidates. So on this SCSI 386sx 20 MHz (31 MB FAT16, FreeDOS 2035-FAT16, FreeCOM XMS swap 12 MB RAM...) the overhead of cache misses for 2 MB cache size is 0.3 sec/MB smartdrv, 1 sec/MB LBAcache, 0.7 sec/MB smartdrv_with_writeback and the overhead for cache hits is ... 2.5 sec/MB higher with writeback or LBAcache than with plain SMARTDRV, strange! What does LBAcache STAT tell after each test? And SMARTDRV statistics? I hope at they did have lots of cache hits in the second test? In what way did you copy the same file 10 times? From harddisk to ramdisk? >From one directory to another one? I think for test b) you need a bigger LBAcache for that, something like THREE megabytes. Please try that (both LBAcache and the writeback feature of SMARTDRV store WRITTEN data in the cache. Therefore if you copy 1.2 MB disk -> disk, BOTH the source file and the target file will be stored in the cache!). (Hm, why are we discussing this on -kernel? Feels more like -devel...!?) Thanks for re-testing already ;-). Eric PS: If INTERLNK crashes FreeDOS, how about INTERSVR? And did it help to - load no HIMEM / EMM386 - use no XMS swapping FreeCOM - use no UMBs / do not load DOS to HMA - ...? You just wrote "various contents" for config sys - but to get started, an as fail-safe as possible config would be better. > Test 1: copy a specific group of files, about 9 MB > No disk cache: 1:15 > LBACACHE 2 MB: 1:24 > SMARTDRV 2 MB: 1:18 > SMARTDRV WC 2 MB: 1:21 > Test 2: copy the same file 10 times, the file was about 1.2 MB > No disk cache: 1:09 > LBACACHE 2 MB: 1:19 > SMARTDRV 2 MB: 0:49 > SMARTDRV WC 2 MB: 1:21 (WC = delayed write cache feature enabled) --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Interlink/Interserver test results
Tested on two different computers (a Pentium-class and a 386) using the same boot floppy (Kernel 2035-16, latest FreeCOM XMS swap) CONFIG.SYS: (various contents) DEVICE=INTERLNK.EXE Result: Invalid Opcode, then it locks up. This happened for both computers. Loading an XMS driver did not help.
[Freedos-kernel] LBACache test results
Test 1: copy a specific group of files, about 9 MB Format - Caching method: minutes:seconds WC=write cache enabled No disk cache: 1:15 LBACACHE 2 MB: 1:24 SMARTDRV 2 MB: 1:18 SMARTDRV WC 2 MB: 1:21 Test 2: copy the same file 10 times, the file was about 1.2 MB No disk cache: 1:09 LBACACHE 2 MB: 1:19 SMARTDRV 2 MB: 0:49 SMARTDRV WC 2 MB: 1:21 Tested on a 386 SX/20 with a SCSI hard drive, 31 MB FAT16 partition, Kernel 2035-16, 12 MB RAM, latest FreeCOM XMS-swap CONFIG.SYS: DEVICE=C:\DOS\FDXXMS.SYS DOS=HIGH FILES=20 BUFFERS=20 STACKS=9,256 LASTDRIVE=E AUTOEXEC.BAT: @ECHO OFF (disk cache executable - nothing, LBACACHE, or SMARTDRV)
[Freedos-kernel] Edit / Kernel problem?
Hey everyone, I'm working on the next release of Edit, 0.82. One of the bugs I already fixed, but keeps getting reported is the write protection bug (#1781). However, when I test this on my machine, it works fine. I don't have a FreeDOS release installed, I'm testing it on an XP machine, so I don't know if that has something to do with it. If it does, then this might be a bug in the kernel, not recognizing the fact that the disk is write protected. I also don't know if the reporter of this bug is using FreeDOS, Win9x or XP, or DOSEMU. Will anyone with any insight or other means of testing please let me know? Later, Joe
Re: [Freedos-kernel] Kernel bug parade / moving on
I think this kind of bug list would best appear on the 'FreeDOS @ SourceForge' page, since it directly relates to the kernel. Eric: would you like me to add you to that project on SF so you can create/maintain this page yourself? -jh Eric Auer wrote: Hi, while we have no real kernel maintainer right now (I assume Jeremy can at most find enough time to upload patches submitted by others, not for doing coding / testing himself), I think it would be good to review some old bugs before we move on to do new optimizations. Of course now that Arkady already has optimized things: If no new bugs get introduced those patches can of course be added. But I think we should focus on a bit of bug testing and fixing now for a while. I hope there are people on the list who can test some of the issues (i.e. have the affected type of software / hardware around!). Bugzilla URLs all look like http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id= where is the number of the bug in question (no leading zeroes). You can also use the http://www.europa.sp.nl/campagne2004/waakhond.shtml page to get a list of all bugs (just select a "sort by" and submit the form as-is) and http://www.freedos.org/bugs/bugzilla/ (just enter a bug number - you actually can NOT enter search terms in the latter form! Now for the bugs. If you are able to test a bug, please do so. [...] Maybe we could put a technote online with this list or something? Some of the abovementioned bugs are very exotic, so we may have to "search the world" for testers who can reproduce the described bug triggering conditions... and most normal people will not read the whole bugzilla system when they find the FreeDOS homepage and have a glance at the project status. -- _ This email message has been automatically encrypted using ROT-26. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Kernel bug parade / moving on
Eric Auer escribió: Hi Justin, thanks for your help offer! Win 3.11 can only run in 386 multitasked mode, 386 ENHANCED mode it would be interesting to get fresh test results (kernel 2035, new himem or maybe ms himem, better no emm386, maybe use DOS=LOW and a non-XMS-Swap FreeCOM for the test as well) for the 286 mode of Windows 3.0 / 3.1 (use WIN /S to start in this mode - you may want to use other "enable compatibility stuff" options of WIN as well, not sure). you mean running the STANDARD mode, that can also be run in a 386 In 286 mode, Windows can run on a 286 (you guessed that, right?). Aitor suggested that it only runs one DPMI task at a time then, swapping the other stuff to XMS. Well, what I suggest is that "Windows" (KRNL386.EXE) runs as a DPMI app, which is what it is actually, a DPMI app. Under a DPMI app you can run other DPMI apps, and have some multitasking using WSWAP, similar to the DSWAP of DOSSHELL. Aitor --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
