When I add the "badram" pattern that 64bit Memtest86+ v6.10/v6.20 gave me, GRUB 2 hangs completely on boot.


Q:
- Why is the badram pattern address different from the "Error Address" displayed (
0x0ac...
vs0x62c...
)? What is the reason for this apparent offset? - Why does GRUB hang on passing a 64bit
badram
pattern?
This is my GRUB...
# grub-mkimage --version
grub-mkimage (GRUB) 2.06-3~deb11u5
sleeping on the job...

Beyond the "Welcome to GRUB!" message, nothing. No reboot, no reaction to key inputs, no rescue shell.
System completely "bricked" - I had to build a rescue USB UEFI boot stick to to recover from this. (Btw, no secure-boot hardware, no signed grub install, so no excuse.)
Anyway. I don't have too much knowledge about system memory and really can't tell much from Memtests' hex numbers.
But I don't think I can just trim the leading zeros and pass these like 32-bit numbers to GRUB, or can I? ...Some person on reddit seems to have done just that, but, like me, couldn't afterwards verify if those numbers actually worked as expected, and masked out the correct memory regions.
Why might GRUB crap itself on this? Is this a bad mem region to mask? Is the region too small, should it be a certain size (like 4K page size) or alignment?
Is GRUB badram
just broken, perhaps? Or is the hardware? (I don't think so, but you never know with these ACPI tables, right?)
In any case, I dug up quite a few instances of other people reporting the same problem with GRUB + 64bit addresses (clearly my GRUB is not the only lazy worker out there):
Upon issuing this command (either via grub.cfg or interactively on the command line) my system hangs and becomes unresponsive.
badram 0x000000008c4e0800,0xffffffffffffcfe0
(They got no response from GRUB devs)
GRUB_BADRAM="0x00000000b3a9feec,0xfffffffffffffffc"
And after that change, I don't even get to Grub boot screen. When it's supposed to show up, computer just hangs and shows the black screen.
(They didn't manage to fix it, either)
I did all that, but the Computer that is perfectly fine and has no errors refused to boot after that GRUB_BADRAM= line addition. it never boots and gives no menu at al.
(The GRUB badram
argument failed on two different computers for them...)
... I can't tell if there might be any relation between these patterns that make them bad, or if GRUB badram
just plain doesn't work with 64bit addresses, since I couldn't find any positive "works for me" reports.
(Those all boiled down to people using Linux memmap=
format or Linux memtest=
kernel parameters, instead.)
Finally, I found one more person who seems to have had success with badram
... using 32bit address notations (on a 64bit machine) ?
So I'm going to try that next.