On Jul 19, 2013 12:31 PM, "Bertho Grandpied" <[email protected]> wrote:
>
> Hi Jeremy !
>
> I'm glad someone (you) is / are fixing this issue. I have made a driver
which fixes it
> successfully in conjunction with the flawed kernels, and I was wondering
whether I should have
> to bundle that proof-of-concept with the EBDA mover. Obviously a kernel
fix is infinitely cleaner !
>
> Kenneth J.Davis said :
>
> > 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?
>
> Unfortunately it has not changed a thing! With the above kernel and XBDA
mover
> (either mine or Japheth's) and JEMM - memory corruption occurs - and my
fixing driver
> "FREEFIX.SYS" does repair it!
> I could't see a difference from using your /new/ build from the /stock/
ones, eother 2040 or 2041 :(
>
> Strange that it worked in VBox though !
>
> | /* reset root */
> |+ /* Note: since device drivers can change what is considered top of
memory (e.g. move XBDA) we must requery */
> |+ ram_top = init_oem();
> | LoL->uppermem_root = ram_top * 64 - 1;
>
> Please check the function "init_oem()" . ram_top should be obtained from
"peeking" at 40:13
> (more secure than calling BIOS int 0x12 at this point).
>
> > 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.
>
> The third option might be the cleanest one. What good does a private
variable do you if
> you have to reinstantiate it anyway ?
>
> As for the LoL ->uppermem_root, we (rogue EBDA movers!) keep it in sync
as needed, so the last
> line of C above is not strictly needed, though should not do harm...
>
> Thanks, and regards
>
> --
> Czerno
>
Please download the kernel again and let me know if there is any change.
Also after the umbrella driver a debug line should be printed, please let
me know the value you see for the 3 items, top of memory before ebda moved,
int 12 value and direct value from 0x40:13
Thank you.
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
