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=9999 where 9999 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. * 423 Quicken 7 does not notice Linux write protection of files in DOSEMU. Instead, Quicken believes to write to the file in FreeDOS (while it fails to open the file at all in DR DOS, probably trying to open for R/W). * 698 floppy change / floppy DMA boundary check should be moved from "int" 25/26 to the int 13 handler. This is also needed for later when we want Win 3.1x /3 compatibility. Please comment on how hard it would be to move the boundary check function. * 735 if you remove a disk during access, FreeDOS has problems to give up in the middle of the access. No idea how other DOSes handle this. * 943 boot failure on dual Pentium III system with all-SCSI drives... * 994 some remote drive letter thing called RIFS network has problems with FindFirst/FindNext. We did have some related bugfix a while ago, but nobody had a suitable test system to check if that solved 994 as well. * 1049 Abort Ignore Retry Fail semantics might be incorrect... * 1176 second floppy controller not detected. Am I right in writing in the bug report that this can only affect 808x systems? How about required BIOS support, if any? A solution could be to interpret the "installed hardware" bitmask from the BIOS differently if CPU is 808x!? * 1630 int 21.4bxx should clear the high parts of the general 32 bit registers - of course this must check if CPU is 386 or better first. I think a CPU detection at boot time could also provide other advantages: If CPU is 808x, you can disable HMA detection and stuff (but I believe UMBs can be possible on 808x), and if CPU is 386, you can enable 32 bit processing in two or three most "performance interesting" "inner loops" like the memcpy function (where else?). And of course the test will allow "optimized for ?86" kernels to show a message instead of crashing when you attempt to run them on x86 with x being a too small number... * 1651 FreeDOS failed to notice a disk change during access (kernel 2029) and then wrote buffered data from the first disk to the second disk, bad. * 1658 the Norton Ghost file browse dialog cannot see files on CD-ROM with kernel 2029/2033, but works with 2027 (not sure why this is a "SYS" bug). * 1688 initdisk complains about unknown partition types instead of ignoring them when you boot from a floppy. * 1743 INTERLNK / INTERSVR (the MS serial/parallel port network drive letter thing) crashes on FreeDOS. So if you have it and you have FreeDOS: Test it. * 1753 Netware VLM crashes on login. To test, you need a Netware server... The strange thing is that in 2026b, Netware NLM crashed, and since 2027, NLM works but VLM crashes! You need himem but do not need emm386. If you had needed emm386, I had suspected some UMB <-> network driver problem,. * 1768 QuickBASIC 4.5 / VBDOS library load problems in FreeDOS. Sounds interesting. VBDOS can be found on the net but it is pretty big and I hope others are more experienced with using it... * 1769 Some DOS4GW versions crash, but using DOS32A usually helps. DOSEMU has a similar problem (see EMUfailure text) which is related to mixing 16 / 32 bit stack segments. Strange that FreeDOS would be affected by this even if you do not load EMM386 - is it? * 1779 the DJGPP RHIDE GUI does not display right unless you use -G 2 mode. Might be VESA / DPMI related, but is not EMM386 related... Not sure, maybe somebody can test on a system with similar graphics card with other DOS? * 1789 the builtin disk format (!) function causes weird kernel error message LBA-Transfer error... - Somebody already tried but could not reproduce, so maybe this depends on the used hardware? * 1793 yet another RHIDE problem: grep function for directories often hangs, possibly redirection related. 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. Be careful with linking bugzilla entries directly, though. Our current CGI versions do not provide spam protection for email addresses which are linked in the bug reports. Thanks for your help already...! Eric. PS: Can somebody with a SLOW PC try LBAcache? If you use smaller caches, something like 0.25 - 2 MB maybe, CPU usage should be reasonable. But I have the idea that LBAcache on a slow 386 or 486 might already be as slow as uncached disk access. If this is the case, I can definitely postpone plans to write a 286 version (are there still 286s out there?). Anyway, I think I will change from "fully associative with memoization to gain speed" to "16 way associative (*) with memoization" to gain even more speed especially for cache miss cases. (*: kind of "16 way 16 sector set associative" actually, as cache searches always look for elements and not for single sectors. Elements can be up to 16 sectors each...) ------------------------------------------------------- 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
