On Thu, 2015-02-19 at 14:43 -0800, Roger C. Pao wrote:
Cut and paste
5361792048656c6c6f20746f204d79204c6974746c6520467269656e64 into
hexedit:
<snip>
Ctrl-X and Y to save.
$ sudo hexedit /dev/pmem0
will display what we pasted.
Ctrl-X to exit.
At this point, you can do a graceful Restart, pull the power cables
from the back of the computer, whatever type of power cycle test you
want.
Once the computer is back on and you login and get back to a terminal,
check the contents of /dev/pmem0 again.
In my case, it is zeros at 0x000 but has stuff at 0x400. I expected
it to be what I pasted in above.
<snip>
This occurs with both Ross's prd and Boaz's pmem trees both
at HEAD.
I'm not sure what's going on. I know that the driver itself doesn't mess
with
the memory that it uses, it just gives you block access to it. On my desktop
system, which importantly doesn't clear RAM when rebooting, I can reserve
memory for PMEM, make a filesystem, lay down some files, do a graceful reboot,
then after the OS comes back up I can re-mount the file system and all my
files are still there.
Boaz's tree and my tree should both be able to do this. The differences
between them are only with regard to configuration, not the I/O path
characteristics.
If you can do this same test with regular DRAM and it works, the finger then
points at your NVDIMM. I have server systems which do zero memory on boot, so
this little test doesn't work, but I'm pretty sure that if this was the case
you'd see all zeros, not random garbage.
- Ross