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) _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
