Hello Stefan,

Let me ask you for some other stuff, since I would like to put what I wrote initially to hold (sleep state, for now).

You wrote: The official specs are not trustworthy IMHO and cpuid(1) and /proc/cpuinfo show the same physical address width of 36 bits (which would indicate a maximum of 64 GB).

Question to you: are you dealing with i686 kernel, (32 bit)? It seems to me that you have Nehalem which complies in IA32 with PAE HW extension, don't you?!

What is PAE? Here: https://en.wikipedia.org/wiki/Physical_Address_Extension

In computing, Physical Address Extension (PAE), sometimes referred to as Page Address Extension, is a memory management feature for the IA-32 architecture. PAE was first introduced in the Pentium Pro. It defines a page table hierarchy of three levels, with table entries of 64 bits each instead of 32, allowing these CPUs to access a physical address space larger than 4 gigabytes (232 bytes).

This is very important -> Enabling PAE (by setting bit 5, PAE, of the system register CR4) causes major changes to this scheme...

Thank you,
Zoran

On Sat, Jan 28, 2017 at 3:10 PM, Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> wrote:
On Sun, 22 Jan 2017 12:33:08 +0100
Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

> Hello Stefan,
>
> In addition what Charlotte wrote to you, I would advise you the following
> (as general approach for mem problems):
> [1] Please, for testing the memory, use secondary Coreboot payload called
> MEMTEST:
> [user@localhost coreboot]$ cat .config | grep MEMTEST
> CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
> CONFIG_MEMTEST_STABLE=y
> # CONFIG_MEMTEST_MASTER is not set
>
> Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my
> best guess) show to you what is wrong with your memory configuration.
>
> [2] You can also (since you are able to in some cases go to Linux) stop in
> GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot
> options (this can also help too, my best guess).
>
> (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999%
> cases used, it would be much easier for you to deal with memtest86+)

Hi Zoran,

I am not exactly sure what you are trying to convey. I mentioned
that memtest did lock up after some seconds with the vendor firmware in
my previous mail. Of course it's the first thing to try when memory
problems arise - I just tried to boot Linux to retrieve the e820 map
because Nico requested it on IRC. I presume that using memtest as
primary or secondary payload or booted from GRUB2 would not produce
different results (unless the binaries are different of course), no?

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner