Strange error message: cannot validate NVM

[Florian Heigl (new acc)]

Hi,

I just noticed the following message in dmesg in a vpar (SD-64).

Jan 24 18:35:23 hxx0142 vmunix: entry 0000000000000001 - major is 31, mi
nor is 0x10000; start = 1215328, size = 3145728
Jan 24 18:35:23 hxx0142 vmunix: read_ss_nvm: Cannot validate NVM - -2

I found this error in the following thread, but the author was searching for something different...
http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1106588296880+28353475&threadId=210276

I guess NVM is 'non-volatile-memory' - but which one, and why can't it be read?

Does anyone have a hint on this?

[harry d brown jr]

I have that in all my vpars dmesg's and my systems are cranking along.

post a call to HP.

live free or die
harry d brown jr

[Florian Heigl (new acc)]

I'll open a call tomorrow, it's already after hour support time here in germany and I don't wanna disturb anyone that late.

But good to know this is 'regular' behaviour, I already assumed it must be some component that's inaccessible to vpars.

I'll post back on the reason when I hear from them.

Thanks!

[Kent Ostby · Accepted solution]

This is the result of a call made by VPARs and can be ignored.

More specifically from some research:

The current implementation of vpar simply passes this
call to the PDC, so it really depends whether the PDC
implemented this call.

I have found a table in vpar design doc which says that
N/L class systems do not support PDC_PAT_NVOLATILE_VERIFY option
of PDC_PAT_NVOLATILE. Thus the returned value is
define PDC_RET_NE_OPT LONG(-2) /* Non-existent option */

So to sum up, this message is normal to appear on N/L class
systems and doesn't present any harm.
The next releases of vpmon could handle this call internally
which would avoid the message, there is no definite plan we could
tell to customer however.