jmtd → log → memtest
Since I'm writing about my NAS, a month ago I happened to notice an odd kernel message:
Aug 8 04:04] list_del corruption. prev->next should be ffff90c96e9c2090,
but was ffff90c94e9c2090
A kernel dev friend said "I'm familiar with that code ... you should run memtest86". This seemed like advice it would be foolish to ignore!
I installed the memtest86
package, which on Debian stable, is actually the
formerly open-source "memtest86" software, last updated in 2014, rather than
the currently open-source "memtest86+". However the package (incorrectly, I
think) Recommends: memtest86+
so I ended up with both. The package scripts
integrate with GRUB, so both were added as boot options.
Neither however, would boot on my NAS, which is a UEFI system: after selection from the GRUB prompt, I just had a blank screen. I focussed for a short while on display issues: I wondered if trying to run a 4k monitor over HDMI was too much to expect from a memory tester OS, but my mainboard has a VGA out as well. It has some quirky behaviour for the VGA out: the firmware doesn't use it at all, so output only begins appearing after something boots (GRUB for example). I fiddled about with the HDMI output, VGA output, and trying different RGB cables, to no avail.
The issue was (likely) nothing to do with the video out, but rather that the
packaged versions of memtest
/memtest86+
don't work properly on UEFI
systems. What did work, was Passmark Software's non-FOSS
memtest86. It drew on HDMI, albeit in a postage
stamp sized window. After some time (much less than I expected, some kind of
magic modern memory matrix stuff going on I think), I got a clean bill of
health:
It's quite possible the FOSS versions of memtest
(pcmemtest
is another)
have better support for UEFI in more recent versions than I installed (I
just went with what's in Debian stable), and if not, then this is a worthy
feature to work on.