Re: potato install-items
Kerstin Hoef-Emden <Kerstin.Hoef-Emden@Uni-Koeln.DE> writes:
> Hmm, my Alpha has an AlphaBIOS 5.66, it is not SRM, but since I don't
> intend to setup a DHCP server, this hopefully won't trouble me.
Actually it's the DHCP/BOOTP client (pump) that's affected by this in
my experience.
It happens with ARC too, and on further reflection I suspect that it's
a kernel bug - the code that sets the initial system clock contains
this little gem (arch/alpha/kernel/time.c, line 309):
if ((year += 1900) < 1970)
year += 100;
But 'year' here is being read from NVRAM and is not a two-digit offset
from 1900 except when the console type is set to VMS. So, in your
case, if you set the year to 2000 in the ARC console, the kernel will
read 20 here, then dutifully add 100 to it and call mktime() with a
year of 120, i.e. 2020. Likewise with SRM - 2000 = 48 in console
years.
You know, this could be construed as a Y2K bug.
Since there's little chance that time is going to start moving backwards,
this should at least be changed to something like:
/* Now that it's 2000, we can do this more reasonably.
Of course this will fail in 2020 on VMS console
machines. */
if (year >= 48) /* assume UNIX */
year += 1952;
else if (year >= 20) /* assume WNT */
year += 1980;
else /* assume VMS */
year += 2000;
A better solution (for SRM at least) might be to read the console's
OS_TYPE environment variable to see what the console thinks the epoch
is (1900 or 1952 for VMS or Unix, respectively). We'll be able to do
this soon :)
--
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Reply to: