Hi! > Reboot: make a D exception after, saying it called int 28 or 28h... > and after saying it was ... cleaning DOS filesystems?...
It probably uses FDAPM to perform the reboot, which first signals DOS and caches to prepare for the upcoming reboot. Messages are a bit different from what you say, but similar. Note that FDAPM offers 3 choices: HOTBOOT, WARMBOOT and COLDBOOT. The more hot reboots are more likely to crash, while the more cool reboots are more comprehensive and in theory a bit slower. I am curious to hear from you which styles of FDAPM reboot work for you for boot options 1 (jemmex) and 2 (jemm386?). > Also LOADHIGH of UIDE.SYS seems to cause the same exception (at same address). Note that UIDE is sort of deprecated, you should use UHDD together with UDVD2 instead: http://mercurycoding.com/downloads.html#DOS The difference is that UIDE combines many features in a single file, while using the two-file solution gives you more features in total. So UIDE is probably only useful for boot disks with very limited disk space. Also note that the website mirrors XMGR, which can be interesting as HIMEM replacement, and various versions of HIMEM including one for more than 4 GB (!) of RAM. The latter is only useful if you have apps to use it. Other XMS drivers simply see "only" a few GB of RAM. Be aware that JEMMEX is "EMM386 and HIMEM in a single driver", so the use of HIMEM and XMGR is limited to boot options which use JEMM386 or another classic EMM386. > e800:67f push es,eax,ebx,ecx,edx,si,di,bp > mov bp,ss > mov al,8d > out 70,al That will disable NMI (non-maskable interrupt) and the next commands copy 3 dwords from 5000:0 to stack. Depending on DI, different SI (6c8 or 668) are chosen for copying 8 words to 5000:0 before doing LGDT and activating protected mode. Next, DS and ES are set to 8 and protected mode is immediately left again! That smells a lot like an "unreal mode" code snippet which tries to access RAM after 1 MB but fails to check if it is allowed to switch to protected mode first. When and EMM386-style driver is active, it is not and the driver in question would have to use int 15 instead. So the next question is: According to MEM, is there a driver at e800? Or is there some BIOS installed there? If the former, does it help to not load the driver to UMB, but rather keep it below 640 kB? If the latter, why is only reboot affected? I would have expected a more frequent problem which happens as soon as you do certain things while EMM386 (or JEMMEX, JEMM386 etc.) are active, probably even while any 32-bit apps with a DOS extender are active, if you have some controller BIOS at e800:0 which assumes that it can have protected mode for itself without first checking. Extra question would be: Can you find suitable EMM386 family options to make it more explicit to that BIOS that it is not allowed to use protected mode? Does it help to use VDS or NOVDS options, for example? Default is VDS and it is unlikely that NOVDS would be better, so this is probably not helping, but loading only XMGR or HIMEM without any EMM386 at all might help you here. > Where is the source code? If FDAPM is used, check the reboot.asm file. FDAPM may be called via a batch script or by defining an alias. > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable > [ 0.000000] BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved That is a pretty unusual place for reserved memory! 4 kB at 352 kB, so it could interfere with ordinary DOS apps. What does MEM say about your driver and app load segments and UMB areas? DOS is not normally able to avoid any areas below the end of your low 640 kB, it just adjusts the 640 kB limit down a bit when told by the BIOS. See my note about JEMMEX below, though! > [ 0.000000] BIOS-e820: [mem 0x0000000000059000-0x000000000009efff] usable In your case, the low 640 kB end at 636 kB. > [ 0.000000] BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved No UMB are allowed. But note that if your memory map listing was created while JEMMEX was already active, it may include entries generated by JEMMEX itself to reserve memory for UMB and itself. > [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000b3cb6fff] usable That means nearly 3 GB available for DOS XMS, HMA, EMS, DPMI etc. > [ 0.000000] BIOS-e820: [mem 0x00000000b3cb7000-0x00000000b3cedfff] ACPI > data As your ACPI tables are 220 kB in size, FDAPM will probably fail to make use of them, grepping around in the first 64 kB at the moment. The remaining usable and ACPI NVS and data areas are relatively fragmented, but HIMEM, EMM386 and similar might use some of the usable areas for additional memory. Probably not very useful. > [ 0.000000] BIOS-e820: [mem 0x00000000c2474000-0x00000000c248afff] ACPI > data Again 256 kB of more ACPI data. > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000236ffffff] usable Those are almost 5 GB of extra memory, so you apparently have 8 GB of RAM and your hardware is able to recycle the 1 GB area which has various ACPI and other reserved areas after 3 GB RAM by showing 1 GB more after the first 8 GB of address space :-) > [ 0.000000] NX (Execute Disable) protection: active Can you configure that in your BIOS? NX might confuse some DOS apps and drivers which use protected mode and are either self- modifying or assume to be able to write data to code segments. Regards, Eric _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
