low memory corruption, fatal?? -- IT'S BACK!!

[mjbjr]

I have a ASUS X79-Deluxe mobo with a Intel i7-4820K CPU @ 3.70GHz with 32GB of memory

I just happened to look at 'dmesg' to check on something unrelated and
noticed that this was just reported (20180128 @2130):

[eccerr0r]

While it's possible bad memory could cause this, it's unlikely. Usually it's BIOS itself that's doing the corruption. There's an option in the kernel that you should try increasing:

CONFIG_X86_RESERVE_LOW

to something larger. 64KiB should have been enough unless you changed it to something else?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[mjbjr]

[mjbjr]

20180129 1830 - at some point in the last couple of hours 'dmesg' shows the corruption continues:

[eccerr0r]

That seems very strange. It looks like that it should be enough, but maybe not.

Try reserving the whole first 1MB?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[mjbjr]

[eccerr0r]

Yeah this is dependent on BIOS firmware. I suspect that despite using Linux for all this time, it must be many different machines.

I haven't run into one of these machines yet, at least one that requires more than 64K reserved (I do recall seeing this before but not recently.)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[mjbjr]

Well, after a couple of days without this BIOS memory problem raising its head,
plus a day and one half after updating the BIOS without the memory problem showing up,

it's back... dmesg reports:

[Hu]

I believe this is normal RAM. A replacement should be sufficient, if it is a RAM problem, but nothing in this thread definitively states that it is a defect in the RAM. Did you ever run memtest after this problem appeared? If so, how long did you let it run? Did it report any problems, anywhere at all?

Can you reproduce this problem with an untainted kernel? This is an unusual failure mode for buggy out-of-tree drivers, but it's not impossible.

[eccerr0r]

Also try adding to your kernel boot command line:

memmap=64K$0 memory_corruption_check=0

Seems that after reserving the low memory, it will still check it, this will prevent it from checking I think the error is now benign if you tell the kernel to not use this memory, so you should be safe in either case.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Ant P.]

You could try swapping RAM sticks between slots (if that's an option) and see if it still happens. Would help to at least rule them out as the cause.

[mjbjr]

Well, I downloaded the latest memtest and ran it overnight and it did not find any problems.
I ran it a second time choosing a slightly different option and again it did not find any problems.

I'll be messing with the ram sticks next.

[roarinelk]

If an extended memtest doesn't reveal any problems with the RAM itself, the I don't think you should worry.
This corruption check and the option in the kernel config to ignore a certain amount of ram starting at zero
is there precisely because some bioses use that area for themselves (in SMM mode for instance) although they
should not and/or they forget to mark that area as "reserved" in the E820 memory map.
If the kernel placed anything vital there, you'd get random behavior or random panics.

In your particular case, I'd set CONFIG_X86_RESERVE_LOW to 64 (I think that's the default anyway), and then disable
that check (set CONFIG_X86_CHECK_BIOS_CORRUPTION=n) and be done with it.

[mjbjr]