On Sat, Jul 13, 2013 at 4:14 PM, Bertho Grandpied <[email protected]>wrote:
> Said Tom Ehlert <te@dr.. - 2013-07-13 17:31 :
>
> > I can reproduce the bug; reason so far not found
> Do you mean, not identified in the source, or what ?
>
> > it would be helpful for the uninitiated if you could share
> > which MCB and which internal variable to adjust
>
> I /thought/ I had provided /enough/ information.. Well, here we go,
> note that I'm going yo decribe how to work around the broken kernel, /not/
> how to fix the kernel code itself!
>
> Not sure this is the place for this level of detail, but Tom asked for
> it...
>
> To repair the memory chain after 1) the XBDA has been removed from
> mem_top 2) DOS UMB management has been (mis)installed, a
> device driver (3) would simply have to :
>
> a) lift the (erroneous) 'segment of upper memory link (Word at offset
> 8C in DOS Sysvars segment, cf. int 21/52). It /was/ the segment
> immediately preceding the /original/ XBDA. Let this be called P
> Change that sysvar from P to 9FFF.
>
> b) Copy the MCB (erroneously) built by FreeDOS,, from paragraph P
> to memory paragraph 9FFF , then adjust SIZE by substracting
> (9FFF - P). The resulting MCB will point to the first actual MCB
> in upper mem.
>
> That's the :scheme to /work around/.the bug/ in excruciating detail ;=)
>
> OTOH for properly /fixing the kernel code/ I guess you'll have to lookup
> and follow specially how the variables ram_top & ebda_size are
> initialised and adjusted, hint : starting in 'config.c'...
>
>
> >and being not so secretive about your project might even rise motivation
>
> I think I have already said, I am not at liberty to disclose more at the
> moment. Besides, I hardly perceive how this would affect the validity
> of a bug report, made in good faith.
>
> Cheers
>
> --
> Czerno
>
>
Please try the kernel at:
http://www.fdos.org/kernel/testing/ebda/KERNEL.SYS
And let me know if it resolves the issue for you? I verified in Virtualbox
that prior to the patch the MCB chain is corrupted if an external device
driver (Japeth's movexbda.exe) updates the top of memory location and then
an UMB driver is loaded (Jemm in my test) and no longer corrupt after the
patch.
Full source is at https://github.com/PerditionC/fdkernel
Patch to fix issue (ignore the 2nd chunk):
http://www.fdos.org/kernel/testing/ebda/config.c.diff
There are multiple possible fixes; I choose to update ram_top in the
umb_init code as that is where it is used for generating the new MCB chain
for UMBs (which produces issue described above). Another option, is to
update ram_top after each load of a device driver (and possibly install'd
command). A third variation would be to remove ram_top variable and always
query for value when used.
Jeremy
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
