<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>139950</bug_id>
          
          <creation_ts>2006-07-10 22:13 0000</creation_ts>
          <short_desc>PowerPC Mac machines reset the hardware clock to before the epoch</short_desc>
          <delta_ts>2006-08-05 22:21:13 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>baselayout</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>142748</blocked>
          
          <everconfirmed>1</everconfirmed>
          <reporter>josejx@gentoo.org</reporter>
          <assigned_to>base-system@gentoo.org</assigned_to>
          <cc>ppc@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>josejx@gentoo.org</who>
            <bug_when>2006-07-10 22:13:46 0000</bug_when>
            <thetext>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&apos;t be booted (the date doesn&apos;t stick).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>josejx@gentoo.org</who>
            <bug_when>2006-07-10 22:15:36 0000</bug_when>
            <thetext>Created an attachment (id=91426)
Skip hardware -&gt; system clock setting when the hwclock is set to before 1970

Maybe this is enough?  I&apos;m not sure what the best fix is.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2006-07-10 22:22:29 0000</bug_when>
            <thetext>I have the same issue on my Pegasos box.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2006-07-14 21:42:29 0000</bug_when>
            <thetext>hwclock is already pretty slow to execute (i hate the sob) ... plus, 1970 is kind of arbitrary, not all RTC&apos;s reset to that ...

historically we&apos;ve told people to change their config file ... see Bug 73652 (CLOCK_SYSTOHC)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>josejx@gentoo.org</who>
            <bug_when>2006-07-14 23:35:53 0000</bug_when>
            <thetext>Nah, the point wasn&apos;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&apos;t want to change it, I can just make a FAQ entry for it, no worries.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2006-07-14 23:52:47 0000</bug_when>
            <thetext>what i meant was that different hardware interprets &quot;0&quot; 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 &quot;--no-older-than &lt;date&gt;&quot; option to hwclock ...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>josejx@gentoo.org</who>
            <bug_when>2006-08-04 08:53:17 0000</bug_when>
            <thetext>Mike, you asked if there was a way to avoid the extra call to hwclock, but I don&apos;t think so.  You can only do one &quot;function&quot; at a time and the first call to hwclock doesn&apos;t return a date we can check.

The other option would be to make not setting the clock not fatal, but I&apos;m not sure if there&apos;s other reasons why that&apos;s not desirable.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2006-08-05 17:08:14 0000</bug_when>
            <thetext>does the hwclock call work ?  in other words, is the time actually reset ?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>josejx@gentoo.org</who>
            <bug_when>2006-08-05 20:24:42 0000</bug_when>
            <thetext>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&apos;t updated because we never get a valid time from the system clock.

(Is that what you were asking?) :)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2006-08-05 22:21:13 0000</bug_when>
            <thetext>should be fixed in svn now</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>91426</attachid>
            <date>2006-07-10 22:15 0000</date>
            <desc>Skip hardware -&gt; system clock setting when the hwclock is set to before 1970</desc>
            <filename>clock.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGNsb2NrLmJhawkyMDA2LTA3LTEwIDIyOjU0OjE1LjAwMDAwMDAwMCAtMDQwMAorKysgY2xv
Y2sJMTkwMy0xMi0zMSAxOToyMjozMy4wMDAwMDAwMDAgLTA1MDAKQEAgLTI3LDYgKzI3LDkgQEAK
IAllbGlmIFtbICQodW5hbWUgLW0pID09IHMzOTAqIF1dIDsgdGhlbgogCQlUQkxVUkI9InMzOTAi
CiAJCWZha2VpdD0xCisJZWxpZiBbWyAkKC9zYmluL2h3Y2xvY2sgfCBjdXQgLWQiICIgLWYgNSkg
PCAxOTcwIF1dIDsgdGhlbgorCQlld2FybiAiUGxlYXNlIGNoZWNrIHlvdXIgaGFyZHdhcmUgY2xv
Y2ssIGl0IGhhcyBhIGRhdGUgc2V0IGJlZm9yZSAxOTcwLiIKKwkJZmFrZWl0PTEKIAllbGlmIFtb
ICR7Q0xPQ0t9ID09ICJVVEMiIF1dIDsgdGhlbgogCQlteW9wdHM9Ii0tdXRjIgogCQlUQkxVUkI9
IlVUQyIK
</data>        

          </attachment>
    </bug>

</bugzilla>