Re: rtc again...

["Iain Sandoe" <iain@sandoe.co.uk>]

>>I am using it as module both for 2.2.17-bk and for 2.4.0-test5. They
>>don't give the same time, and I think it is the one in 2.4.0 that is
>>right. I am at GMT+2:00, and the time in 2.2.17 is 2 hours early. When I
>>change /etc/sysconfig/clock from "UTC=false" to "UTC=true", both times
>>shift by 2 hours, but the discrepancy remains.
>>
>>The following patch for bitkeeper linuxppc_2_2 fixes this problem for
>>me. It brings 2.2.17pre13 in line with 2.4.0-test5 (and MacOS). I cannot
>>test the VIAPMU part, so maybe there the offset is necessary, but for
>>the VIACUDA part, it seems wrong.
>
> You patch reverts a fix I made some time ago. Basially, what probably
> happens is that your RTC is in UTC time, not in local time. The Mac RTC
> is supposed to be in local time, the offset corrects the kernel time on
> boot to account for this. Previously, without that fix, the kernel used
> to boot with a bogus UTC time until userland fixes it.

Hm.  I have exactly the same phenomenon.

I reset my RTC using NTP (on the Mac Side) last night and have daylight
saving set to "automatic".  The Mac timezone is correct (GB).  The Linux
timezone is also correct (GB).  I can't see any other random offsets around
the system.

If rtc is left out (and the module won't/isn't loaded).  2.2.17pre15 gets
the time right (UTC+0100).

If rtc is complied in (and I imagine the same will apply to a working
module) 2.217pre15 gets it one hour wrong. (UTC)

Under 2.4.0-t5 it's OK (well, it agrees with MacOS)...

Note that it has *always* been right with earlier versions of 2.2.x.

Unless, of course, Apple have changed to storing UTC in the transition to
9.0.4 (might ease the way to X?)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/