The CMOS clock on ARC consoles is in a different format -- you
have to use "clock -A" (see man clock).
I will change this in my boot up script.
Eugen R. Neuber
euneuber@sbox.tu-graz.ac.at
---------- Forwarded message ----------
Date: Wed, 3 Jun 1998 13:44:58 +0200 (MEST)
From: Eugen <eu@neutrino.lab.ork>
To: Jerome BERTHIER <j-bert97@bat710.univ-lyon1.fr>
Cc: linux-alpha@vger.rutgers.edu
Subject: Re: clock skew
I do have a similar problem: My running 164LX does fine, but after reboot
I have (proper-day)-2018 or Nov-4-2036.
This IS VERY harmful if it is not detected imediately !!! (I had to check
my *.c an *.cpp files by hand...) --- But now I know ;-)
Is this a hardware or a software problem ? (I have ISA cards in my system)
Eugen R. Neuber
euneuber@sbox.tu-graz.ac.at
On Wed, 3 Jun 1998, Jerome BERTHIER wrote:
> Date: Wed, 03 Jun 1998 12:18:28 +0200
> From: Jerome BERTHIER <j-bert97@bat710.univ-lyon1.fr>
> To: linux-alpha@vger.rutgers.edu
> Subject: clock skew
>
> Hi!
>
> None of the kernel I compiled works (the station doesn't boot after
> having uncompressed the new kernel). I have yet do make mrproper, make
> menuconfig (without changing any of the options, except the scsi, since
> I have only ide drives), make dep, make clean, make boot, make modules,
> make modules_install. After that, I rename my old kernel, and move the
> new one from arch/alpha/boot/ to / , but it doesn't works...
> It probably comes from some warnings I have sometimes during
> compilation: "clock skew detected. your build may not be
> complete", after each "ld" or "ar" instructions. These warnings can
> result of the difference between the values returned by "clock" and
> "date": clock returns the real date (but sometimes give some random
> dates, like 13 november 2019), and date works too fast (it gains
> approximately 6 seconds after doing "make boot"), and I must do a "clock
>
> -a" after loging, because it never returns a good year.
> Sometimes, the compilation even prints the contains of the
> registers, and blocks the computer...
>
> So well, if anybody can help...
> --
> Jerome Berthier
> j-bert97@bat710.univ-lyon1.fr