DOS ain't dead

I tested my pascal code for memory size detection. It is quite standard routine using E820h with fallback to E801h.
In every computer I tried it works nice and always via primary solution, via E820h.
(only on my P4 it reports not 512MB but 511MB).
But OK.
However on my now notebook Lenovo legion Y540 with 16GB RAM it detects only 2GB of RAM and the rest does not appear in the memory map.
I found no mistake in my code but was is even more important, all software information tools which rely on the E820h also report the 2GB of RAM.
See the screenshot from Astra:
http://www.laaca.borec.cz/imag0239.jpg

Sure - I can use for the memory detecion the SMBIOS scan with memory chips info but why the usual E820h does not work on my machine?
Is it a known bug on some BIOSes?
Or should I do some black magic voodoo with MSR registers?

---
DOS-u-akbar!

Hm, I updated my BIOS (it was quite scary because after the flashing the computer was not booting - I had to remove a return the battery and after that it booted at least into BIOS menu where I was able to enable the boot from other device than network)
However - after the BIOS update the Astra sysinfo reports the correct memory size even using the E820h service.
(I also have to test my pascal detection routine)

---
DOS-u-akbar!

Well, things are much more compicated than I expected. I made more tests and sometimes the memory size is reported correctly and sometimes wrong.
For tests I used the Japheth's utility GETI15EX (originaly from HXDOS\TEST\ subdirectory). Not sure whether it it the last version however the file has 2374 bytes.
Also I used my quick-and-dirty utility TestMem

First of all - I have found a bug in Japheth's utility GETI15EX. It does not correctly process the E820h chain and omits the last record.
(log here )

So for further testing I used only TestMem.

And the result is that it seems to be a conflict between JEMMEX and the memory map created by BIOS service E820h.

Under these configurations is returned the proper size of my RAM (16GB):
raw DOS, HimemX, HimemX+Jemm386 (both from config.sys and commandline)
Logfile is here

But if I load JemmEX (from config.sys) the memory map is corrupted and the last entry from E820h is corrupted and is marked as memory region type 2 (aka reserved).
(See here)

I thought that JemmEX overwrites some data in some BIOS segment where the E820h map is loaded from. I suspected the page frame for EMS.
But this curruption occurs with every parametrs I tried even with such configuration when everything is off: DEVICE=C:\FREEDOS\JEMMEX.EXE MAX=32M NOVME NOEMS NOVCPI
And what is even more strange is the fact that the combination HIMEMX+JEMMEX is OK but JEMMEX not.
Any ideas?

---
DOS-u-akbar!

> First of all - I have found a bug in Japheth's utility GETI15EX. It does
> not correctly process the E820h chain and omits the last record.
> (log here )

Yes. This tool is totally outdated. The up-to-date tool is called MEMSTAT and contained in the jemmex package.

> But if I load JemmEX (from config.sys) the memory map is corrupted and the
> last entry from E820h is corrupted and is marked as memory region type 2
> (aka reserved).

That's quite correct. It's not "corrupted", however. The currect jemmex implements XMS v3.5, that is, the XMM handles memory beyond 4 GB - and it wants to handle that memory exclusively. For this reason it intercepts int 15h, ax=e820 and marks the corresponding regions as "reserved". It's documented, so all you need is to read XMS35.txt.

If you don't want this, there's another jemm version, jemmexl.exe, that leaves int 15h e820h untouched.

---
MS-DOS forever!

>
> If you don't want this, there's another jemm version, jemmexl.exe, that
> leaves int 15h e820h untouched.

I see.
Anyway, you are right, I don't want this. It is not OK to loose the standard way (almost the only way) how to detect the RAM size.

---
DOS-u-akbar!