Hi All,
This same discussion is also going on internally to CPQ, and here is the
current observation...
------------------------------
> I receive the above about a date problem on linux :
>
> I have had a call from CSC who have a loan DS20 running Linux RH 6.0.
They
> have reported that they have several files which have dates on them of
2047.
> Whether this was true before the beginning of 2000 is not known.
> Interestingly I also have a machine (an old 433 PWS) which also has files
> dates 2047. Not all files from last year have 2047, it would appear to
only
> be files touched before the end of 1999.
>
> i have a dpws with this king of behaviour too ...
>
> Any thoughts ?
Are you (or they) dual-booting Tru64 UNIX and Linux on the system?
Tru64 UNIX maintains the hardware Time of Year (TOY) clock offset
from the real year by, if I recall correctly, 48 years. It does
this because the SRM console firmware will screw around with the
hardware TOY clock (e.g., to try to adjust it between OpenVMS and
Windows NT formats, or if the looser uses the console's set time
command), and UNIX needs to be able to tell whether it's valid, as
UNIX has other ways to manipulate it (e.g., retrieve a possibly
good value from the boot blocks on the boot disk).
Anyway, if Tru64 UNIX is maintaining the TOY clock and Alpha Linux
isn't using anything except the hardware clock and is assuming that
the year field is "real", it's going to see 2047 (in 1999) or 2048
(in 2000) as the year.
This, of course, is resolved by using a network time service to set
the clock during boot..
--------------------------------------------
I will update the list if a "better" solution is found for those who
want to dual-boot their Alpha.
Tim
-----Original Message-----
From: Metod Kozelj [mailto:metod.kozelj@rzs-hm.si]
Sent: Friday, January 14, 2000 4:10 AM
To: Linux-alpha mailing list
Subject: boot from SRM & system date [ update ]
Hello,
On Thu, 13 Jan 2000, I wrote:
> today I installed linux (RH 6.1) on an alcor system (AlphaStation 600
> 5/333). Mostly it works right except for system date. It seems that linux
> takes wrong UNIX epoch from SRM. date shows some date in 2068, which is
> exactly one epoch (2**31 secs) too late.
The information above is note entirely correct. The behaviour is a bit
different: it gets the seconds, minuted, hours, day and month correct,
only the year is incorrect. It thinks we are in 2047.
It seems to calculate the epoch later and since the year is wrong (and in
next UNIX epoch, which starts sometime in 2038), the epoch is also wrong.
It still holds what I wrote about ntp:
> BTW, if I run ntpdate, it corrects clock by some seconds, so it seems that
> it doesn't know about epoch.
Does anybody else have similar problems. Any solution other than seting
the correct date/time in linux and then writing it back to SRM?
Peace!
Mkx
---- perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:28 EST