Dave Jiang
Dave Jiang
Hmm....I don't understand why it attempts to enable the dimm while attempting overwrite. Can you enable verbose debugging and provide the log please?
Ok, I think I know why we are seeing this behavior. Overwrite has been issued, but then we call revalidate_labels() afterwards. and that fails. I think this is the wrong...
https://lore.kernel.org/nvdimm/168357518158.2750073.1393407560977941832.stgit@djiang5-mobl3/ Can you please try this fix and see if that does the job? Thanks!
Do you have CONFIG_NVDIMM_SECURITY_TEST=y in your kernel config? I talked to Vishal and he said it works for him. The only thing I can think of right now is that...
So issue 239, where key blob isn't removed after overwrite, is addressed correct? The remaining issue is 244, where overwrite is issued anyways even though there's error of some sort?
Did you call ndctl wait-overwrite nmem0 to wait for overwrite completion first before checking the state?
Looking at the DSM 1.8 spec, I'm starting to get the feeling that overwrite does not change the security state of being enabled. And that when I implemented overwrite, maybe...
Also, is this a Crow Pass on Sapphire Rapids or some other DIMM on a different platform? Trying to find some help internally....
If your BIOS has the feature: Boot to the UEFI menu and enable Secure Erase Unit for the module(s) 1. UEFI EDKII > Socket Configuration > Memory Configuration > PMem...
Can you open up an IPS case so Intel can track it? We can look into how to get that DIMM serviced.