Hi,
> Ok. I'm glad there's an explanation eventually.
My hope is that it's just an oversight of not appropriately expanding
memtest's functionality when HIGHMEM was introduced into the kernel,
and not because memtest is considered insignificant.
> Please be kind enough to forward us the bug report URL once it's been
> filed: I'm obviously interested in tracking how far this goes.
The mail to linux-mm that generated some discussion on this list was
the bug report.
> While we're at it, I would consider it only fair if that sentence,
> that can be found on the Liberté Linux homepage, was promptly fixed:
Sure, I removed that — although to be fair, the sentence was added on
Sept 19, whereas the move from userspace memwipe to memtest was done
on Oct 13, so the sentence was correct at the time. But as I said, I
don't want to go back to userspace, since kernel's behavior on OOM is
unreliable in extreme conditions (i.e., not just allocating a big
chunk that the kernel can't provide, but slowly extending program's
region with brk()).
I am currently thinking about these possibilities:
1. Using an amd64 64-bit KEXEC kernel, and booting into it on 64-bit
machines (assuming KEXEC can do that), and on older computers, just
KEXEC'ing into MemTest86+ (that's possible, although MemTest86+
developers don't like that —
http://forum.canardpc.com/threads/42292-memtest86-with-kexec), or
using the current 32-bit solution (arguably 32-bit computers with >1
GiB RAM are rare).
2. Forking MemTest86+'s code to do two passes + reboot/halt, and using
that. That only makes sense if MemTest86+ reaches >4 GiB RAM on all
architectures (remember that I use PAE+HIGHMEM64G).
But best option, of course, is if kernel developers fix the kernel — I
will just apply a patch until the fix is in stable mainline.
Best regards,
Maxim
--
Maxim Kammerer
Liberté Linux (discussion / support:
http://dee.su/liberte-contribute)
