Hi... I guess freedos-devel would be better than freedos-user or off-list mails for this... Anyway ;-).
>> In other words, if you have more than 32 MB XMS2...? > I don't know, once I had found the technical reason for the bug I > stopped examine all possible configurations (with the exception of > vmware, were I was curious if this emulation indeed somehow is able to > "cure" the bug. It isn't.) Okay... any idea why the limit-to-32-MB-XMS-2 default somehow blocked the problem? >> So it is about VCPI allocation? Or EMS? > Yes, it is a VCPI issue, calling memory functions ax=DE03h ... DE05h in > protected mode. http://www.delorie.com/djgpp/doc/rbinter/id/15/75.html RBIL 67.de03: get number of free 4k pages http://www.delorie.com/djgpp/doc/rbinter/id/16/75.html RBIL 67.de04: allocate a VCPI page http://www.delorie.com/djgpp/doc/rbinter/id/17/75.html RBIL 67.de05: free a 4k page >> And... Is that the actual cause, a stack overflow? > No, the actual cause is an address context switch (CR3 register is > changed) without ensuring that the current stack pointer is valid in > this new context. How can that be fixed? If the stack pointer is in some page which you are just about to unmap, you cannot just move the stack pointer to "some" other place... Please explain in more detail. >> What is the URL of the Bugzilla entry? > I dont know, but should be easy to find out for those who are interested. http://www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1941 ... given that you reported the bug and want it to be fixed, you could be a bit more helpful ;-). You write: BEGIN you The protected-mode VCPI functions 03-05 are good candidates for causing a reboot: the VCPI host has switched CR3, but IDT (and stack, GDT, ...) are still set to the client's, a hazardous constellation if an exception occurs then. PM_ENTRY PROC ... mov ecx,fs:[PAGEDIR] mov cr3,ecx this switch silently assumes that the host is called with SS:ESP pointing to conventional memory (there is no stack switch to the hosts SS:ESP between PM_ENTRY and the move to CR3). END you As said, sounds reasonable, but how to fix it? >> What is the DIFF / patch for EMM386 which you used to fix it? > no DIFF has been created. We cannot apply your patch unless you submit one! >> Be more verbose please! (On the list, of course...) > Hopefully this was enough? Yes but it was off-list, CCing the list... Eric ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
