Hi Ben,

RVM uses (probably amongst others) timestamps to guarantee consistency, and
is therefore slightly picky about what time the gettimeofday call returns.

In your case, as you've just rebooted into a new kernel, the time is taken 
from the CMOS clock, and it must have been a couple of minutes behind your
system clock. We keep all servers (and clients) in sync by using xntpd, and
we write the current system time to the cmos during system shutdown to avoid
problems.

btw. about the lack of debug symbols, I've checked and the binaries were
compiled with debugging, but somehow got stripped before being packaged up.

> I still think the "check kernel date" error in the subject above is
> pretty vague, though.

Yeah, it might be possible to turn it into something like

"RVM_Init: detected an anomaly in the space-time continuum,
  last RVM operation was Mon Nov 30 1998, 18:00:00,
  current time is Mon Nov 30 1998, 17:56:00."

However that might still be confusing, for non-trekkies.

> Also, in an unrelated question, is it usual for codasrv to be taking
> up 116 megs of ram? :)

The RVM data partition is copied into the server process memory image. It is 
the way RVM is implemented. We might be able to use mmap to avoid using both 
disk- and swap-space, but it is not yet possible to memory map a raw partition
on linux. And we would have to make doubly sure it gives the same consistency 
guarantees. How many programs can you `kill-9' and restart without losing 
information?

As not all parts of the RVM mapping are used very intensively, most of the
memory occupied by RVM will get swapped out.

Jan