Re: Strange NVRAM corruption on Sun Blade 2500

On Fri, 19 Sep 2014, Martin Husemann wrote:

> Anyway, I am not looking for advice to recover this machine (it already is, I
> am typing this message there), but hints how to prevent this from happening
> again or reasons that might have caused it (i.e.: bugs in our code).

Have you checked to see if anything in the kernel is attaching to the 
SEEPROM?  

The SEEPROM is separated into two sections, the first section is the ID 
prom which contains important information that's used to boot the box.  
If that gets corrupted the board will not even configure DRAM.  Luckily, 
that section is protected with a hardware write-protect strapping on the 
SEEPROM.

The second half holds the NVRAM contents.  And yes, some of the 
environmental variables don't have defaults, so set-defaults will not 
recover them.

The first thing I would recommend is to determine whether it's the kernel 
or OBP that's writing to the device.  I haven't been following the code 
very closely, but if someone has implemented an NVRAM driver for the 
SEEPROM similar to the old NVRAM driver, it could be writing bad data 
during shutdown.

The next thing would be to dump all the parameters being passed to the 
client interface to shut the box down and make sure they are sane.  

Finally, it is possible that the problem is being caused by the MMU.  If 
the client call is relying on he kernel to manage it's mappings, and 
something has happened to the one containing the cached copy of the NVRAM 
settings, it may write out incorrect data to the SEEPROM.  But if the 
client terminates, OBP will take over the MMU and that problem won't 
occur.

Eduardo