Date:        Fri,  5 Nov 1999 10:22:39 +1100 (EST)
    From:        Daniel Carosone <dan@geek.com.au>
    Message-ID:  <14370.5435.778050.949628@passion.geek.com.au>

  | Not every time.  Sometimes it hangs instead of going back to the ">>>" 
  | prompt when I "halt" NetBSD. Oddly, it seems when it hangs it's *less* 
  | likely to forget it's settings than if it returns to the SRM prompt
  | before the box is powered off.

How certain are we that this is really a SRM bug?    It seems kind of
serious (and very obvious - it isn't as if it is subtle or anything)
to have survived several revisions of the SRM code.

I was wondering whether perhaps NetBSD may be having some impact upon this
and was meaning to ask, then I saw ...

  Message-id: <199911071126.DAA16863@nooksack.ldc.cs.wwu.edu>
  Date: Sun, 7 Nov 1999 03:26:09 -0800 (PST)
  From: dave_daniels@argonet.co.uk
  Reply-to: dave_daniels@argonet.co.uk
  To: gnats-bugs@gnats.netbsd.org
  Subject: port-arm32/8759: reboot command on RiscPC corrupts CMOS memory

  The NetBSD 'reboot' command on a RiscPC changes two bytes of the
  RiscPC's CMOS memory without updating the CMOS checksum.
  [...]

Now that's about a completely different architecture, etc, and so doesn't
mean anything in particular to the alpha port (or the 164's in particular)
but there might be a problem something like that.

One workaround that has been mentioned on the list is to explicitly set the
env vars just before a power off, that seems to cause them to be saved.
If it were some kind of corruption problem upsetting the checksum, that would
make sense, as the rewrite from SRM would be expected to correct things
(at least enough so the checksum would be correct, even if not completely).

It would probably be a good idea if those of us with these systems could
keep track of how the system gets shut down, and in what circumstances
the nvram data is saved, and when it is lost - maybe a pattern will emerge.

I did run FreeBSD on my alpha for a short while (it was too flaky to continue
with, and didn't support enough hardware) but I didn't ever see the nvram
lossage after rebooting from it, only ever after NetBSD, which is where I
started wondering if this really is the SRM problem we have all been assuming.

kre