Bug 139950 - PowerPC Mac machines reset the hardware clock to before the epoch
Bug#: 139950 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: base-system@gentoo.org Reported By: josejx@gentoo.org
Component: baselayout
URL: 
Summary: PowerPC Mac machines reset the hardware clock to before the epoch
Keywords:  
Status Whiteboard: 
Opened: 2006-07-10 22:13 0000
Description:   Opened: 2006-07-10 22:13 0000
Some PowerPC Mac machines reset their hardware clocks to 1900 instead of a
reasonable (1970 or later).  This causes the clock init script to die when
trying to set the system clock to the hardware clock date. Perhaps instead of
dying it should warn the user that the hardware clock is set wrong, or at the
very least, warning should be given as to why the hardware clock failed before
dying.

I would rather see it just be a warning since on some older machines, a dead
system battery is a common occurance and the result is a system that can't be
booted (the date doesn't stick).

------- Comment #1 From Joe Jezak 2006-07-10 22:15:36 0000 -------
Created an attachment (id=91426) [details]
Skip hardware -> system clock setting when the hwclock is set to before 1970

Maybe this is enough?  I'm not sure what the best fix is.

------- Comment #2 From Doug Goldstein 2006-07-10 22:22:29 0000 -------
I have the same issue on my Pegasos box.

------- Comment #3 From SpanKY 2006-07-14 21:42:29 0000 -------
hwclock is already pretty slow to execute (i hate the sob) ... plus, 1970 is
kind of arbitrary, not all RTC's reset to that ...

historically we've told people to change their config file ... see Bug 73652
(CLOCK_SYSTOHC)

------- Comment #4 From Joe Jezak 2006-07-14 23:35:53 0000 -------
Nah, the point wasn't to catch the date the RTC was set to, the point was
catching invalid dates passed to the system clock from the hw clock (which can
only take dates after 0:00:00 Jan. 1, 1970 afaik).

If we don't want to change it, I can just make a FAQ entry for it, no worries.

------- Comment #5 From SpanKY 2006-07-14 23:52:47 0000 -------
what i meant was that different hardware interprets "0" differently, so picking
1970 as the limit doesnt work all the time ... alpha for example can go with
like 1952 ;)

too bad there isnt like an "--no-older-than <date>" option to hwclock ...

------- Comment #6 From Joe Jezak 2006-08-04 08:53:17 0000 -------
Mike, you asked if there was a way to avoid the extra call to hwclock, but I
don't think so.  You can only do one "function" at a time and the first call to
hwclock doesn't return a date we can check.

The other option would be to make not setting the clock not fatal, but I'm not
sure if there's other reasons why that's not desirable.

------- Comment #7 From SpanKY 2006-08-05 17:08:14 0000 -------
does the hwclock call work ?  in other words, is the time actually reset ?

------- Comment #8 From Joe Jezak 2006-08-05 20:24:42 0000 -------
The hwclock (adjtime) command works, but it fails when setting the linux system
clock from the hardware clock (the second hwclock call).  The system time is
not reset and the hwclock isn't updated because we never get a valid time from
the system clock.

(Is that what you were asking?) :)

------- Comment #9 From SpanKY 2006-08-05 22:21:13 0000 -------
should be fixed in svn now