NVRAM stuck in DST?

NVRAM stuck in DST?

[Michel Lanners]

Hi all,

For some time now (in fact since going back from summer time to winter
time), my PowerMac 7500 gains one hour at very system boot. No matter
how I configure it to save sytsem time as GMT or as localtime in the
RTC, I _always_ get +1 hour on boot.

I've looked at kernel messages, and it says there:

...
GMT Delta read from XPRAM: 120 minutes, DST: on
...

Hmmm... DST on? That's wrong; we're not in DST anymore! And the current
offset to GMT is one hour, not two hours. I'm wondering whether
something else besides MacOS sets those values.

If not, then I'll be stuck with whatever NVRAM values MacOS wrote there
when it was last booted. Which means that unless at every DST time
change, unless I bot MacOS once, I'll be stuck with the wrong time....

Also, just for my understanding, doesn't MacOS save the system time in
the RTC in localtime? In that case I don't see how time _advances_ on
boot... unless the MacOS RTC is in DST-less localtime.

Anybody with more insight here?

Thanks, and cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: NVRAM stuck in DST?

[Benjamin Herrenschmidt]

>
>
>Hmmm... DST on? That's wrong; we're not in DST anymore! And the current
>offset to GMT is one hour, not two hours. I'm wondering whether
>something else besides MacOS sets those values.

AFAIK, MacOS is the only one to set it.

>If not, then I'll be stuck with whatever NVRAM values MacOS wrote there
>when it was last booted. Which means that unless at every DST time
>change, unless I bot MacOS once, I'll be stuck with the wrong time....

Yup, we need a proper tool for that. Actually, we need 2 things

 - a way for /dev/nvram to let userland know about the partitioning
of the nvram (expecially where the xpram is)
 - then a tool using that to write to the MachineLocation record
in nvram containing the tz offset and DST flag.

>Also, just for my understanding, doesn't MacOS save the system time in
>the RTC in localtime? In that case I don't see how time _advances_ on
>boot... unless the MacOS RTC is in DST-less localtime.

The kernel time is calculated from the RTC local time, offseted by
the pram gmt offset & dst to get a GMT time.

Ben.


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

Re: NVRAM stuck in DST?

[Benjamin Herrenschmidt]

>The kernel time is calculated from the RTC local time, offseted by
>the pram gmt offset & dst to get a GMT time.

Note that the offset MacOS stores there already includes DST.
The kernel doesn't use the additional DST flag, it's just displayed
in the message to help understand why your offset is wrong ;)

Ben.


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

DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[Michel Lanners]

Hi all,

Back in December, I had problems with my clock always beeing wrong.

On   7 Dec, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>Hmmm... DST on? That's wrong; we're not in DST anymore! And the current
>>offset to GMT is one hour, not two hours. I'm wondering whether
>>something else besides MacOS sets those values.
>
> AFAIK, MacOS is the only one to set it.

Also my understanding.

>>If not, then I'll be stuck with whatever NVRAM values MacOS wrote there
>>when it was last booted. Which means that unless at every DST time
>>change, unless I bot MacOS once, I'll be stuck with the wrong time....
>
> Yup, we need a proper tool for that.

I've since tracked what happens to the GMT offset in nvram on bootup.

In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
we use the GMT offset MacOS stores in nvram to correct this, and correct
kernel time to real GMT. We also set kernel timezone info, but it's use
is discouraged (have a look at man settimeofday).

Now, when this offset is wrong (like when DST switched and you didn't
boot MacOS since), your intial kernel time will be wrong. However, the
rc files should set the kernel time once more on bootup (which is the
case now for me in Debian), and everything is peachy again.

So, my initial problem was caused by either my kernel lacking RTC
support or by my distribution (linuxppc at that time) not forcing the
clock.

The question, of course, is whether Linux should maintain this GMT
offset in nvram, since it uses it's information. If so, then who should
maintain it where?

- Userland tool: doesn't sound like a good idea; it's something very
  machine-specific.

- kernel: maybe, but when should the info be updated in nvram? Where
  does the kernel get the DST and offset info from (since it basically
  doesn't know anything about the local idea of wallclock time)

My proposition would be to correct this everytime that the RTC is
updated (since the GMT offset belongs logicaly to the RTC function
block). Debian does this on every system shutdown.

Remains to be seen if the kernel RTC driver should do the work, or a
useland tool:

> Actually, we need 2 things
>
>  - a way for /dev/nvram to let userland know about the partitioning
> of the nvram (expecially where the xpram is)

There is an ioctl defined for /dev/nvram in include/asm-ppc/nvram.h,
but it's not accessible from userspace (defined inside #idfdef
__KERNEL__). I'd say bug?

>  - then a tool using that to write to the MachineLocation record
> in nvram containing the tz offset and DST flag.

I have something working for OldWorld, but it's a _very_ ugly hack ;-)


Obviously, the easiest thing to do is do nothing and entirely rely on
the bootup scripts to set the correct time.

Comments anyone?

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[Ethan Benson]

On Thu, Mar 28, 2002 at 12:28:27PM +0100, Michel Lanners wrote:
>
> In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
> taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
> we use the GMT offset MacOS stores in nvram to correct this, and correct
> kernel time to real GMT. We also set kernel timezone info, but it's use
> is discouraged (have a look at man settimeofday).

this is broken.  the kernel should just use the time stored in nvram
and ignore the crap macos is keeping there regarding time zones.

the solution to the `windows controls the hardware clock' problem was
made many years ago, hwclock can be told whether the RTC is in
localtime or GMT, just about every distro asks you this on install (at
least on x86 debian does on powerpc too).

we should just deal with the RTC exactly how its delt with on x86, if
you have windows (or in our case MacOS) you tell hwclock the RTC is in
localtime and let it deal with it, if you don't have MacOS/windows you
tell it you have the RTC in GMT like its supposed to be and all is well.

> Now, when this offset is wrong (like when DST switched and you didn't
> boot MacOS since), your intial kernel time will be wrong. However, the

which demonstrates exactly why this crap in the kernel trying to be
like macos is just plain wrong and broken.

> The question, of course, is whether Linux should maintain this GMT
> offset in nvram, since it uses it's information. If so, then who should
> maintain it where?

no it should not.  the kernel should NOT know or care what the
timezone is, that belongs in userspace not kernel space.  period.

the feilds macos sets should be ignored entirely by linux, not read,
not written.

> My proposition would be to correct this everytime that the RTC is
> updated (since the GMT offset belongs logicaly to the RTC function
> block). Debian does this on every system shutdown.

please don't forget systems that don't have legacy MacOS, these
systems will keep the RTC in GMT like its supposed to be.

> Obviously, the easiest thing to do is do nothing and entirely rely on
> the bootup scripts to set the correct time.

this is of course the correct solution, this problem was met and
solved YEARS ago on x86 its stupid that powerpc is fooling around with
it when there is already a well established and working solution.

> Comments anyone?

see above, in short this `lets pretend we are MacOS!!' crap in the
kernel should be *REMOVED* the kernel should not know or care about
timezones or DST, it should just read the RTC and ignore these macos
fields.  the standard bootup scripts running hwclock will pass --utc
or --localtime depending on how the user configured it and all will be
fine, just like on x86 for dealing with windows.

--
Ethan Benson
http://www.alaska.net/~erbenson/

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

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[Geert Uytterhoeven]

On Thu, 28 Mar 2002, Ethan Benson wrote:
> On Thu, Mar 28, 2002 at 12:28:27PM +0100, Michel Lanners wrote:
> > In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
> > taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
> > we use the GMT offset MacOS stores in nvram to correct this, and correct
> > kernel time to real GMT. We also set kernel timezone info, but it's use
> > is discouraged (have a look at man settimeofday).
>
> this is broken.  the kernel should just use the time stored in nvram
> and ignore the crap macos is keeping there regarding time zones.
>
> the solution to the `windows controls the hardware clock' problem was
> made many years ago, hwclock can be told whether the RTC is in
> localtime or GMT, just about every distro asks you this on install (at
> least on x86 debian does on powerpc too).
>
> we should just deal with the RTC exactly how its delt with on x86, if
> you have windows (or in our case MacOS) you tell hwclock the RTC is in
> localtime and let it deal with it, if you don't have MacOS/windows you
> tell it you have the RTC in GMT like its supposed to be and all is well.

Perhaps someone can writes a utility to `patch' MacOS to treat the hardware
clock being in GMT/UTC/Zulu time? I did a similar thing for AmigaOS many many
years ago.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[Ethan Benson]

On Thu, Mar 28, 2002 at 05:19:56PM +0100, Geert Uytterhoeven wrote:
>
> Perhaps someone can writes a utility to `patch' MacOS to treat the hardware
> clock being in GMT/UTC/Zulu time? I did a similar thing for AmigaOS many many
> years ago.

or if you want a macos only use OSX, it has no problems with the
hardware clock set to UTC, at least the beta did not.

(i tinkered with the beta, at the time my machine had no trace of
MacOS 8/9 and my nvram contains no macos cruft, that is the timezones
and DST fields are null, OSX showed the proper time, and it never
reset the hardware clock to localtime.)

--
Ethan Benson
http://www.alaska.net/~erbenson/

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

bug: kernel timer added twice at e3259abc.

[Kevin B. Hendricks]

Hi,

The following has showed up in my dmesg log (running Ben's latest) on a
dual SMP G4 machine:

bug: kernel timer added twice at e3259abc.
bug: kernel timer added twice at e3259abc.

And using sun gem driver I see the following on occaision:

invalidate: busy buffer
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
sending pkt_too_big to self
Saw underflow (9728 of 61440 bytes). Treated as error
Saw underflow (3584 of 53248 bytes). Treated as error
sending pkt_too_big to self

Ideas welcome about either.

Kevin

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

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[benh]

>we should just deal with the RTC exactly how its delt with on x86, if
>you have windows (or in our case MacOS) you tell hwclock the RTC is in
>localtime and let it deal with it, if you don't have MacOS/windows you
>tell it you have the RTC in GMT like its supposed to be and all is well.

Which means that during boot, the kernel will have a wrong (local) time
instead of UTC. That can be annoying.

Ben.


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

Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)

[Ethan Benson]

On Thu, Mar 28, 2002 at 06:18:59PM +0100, benh@kernel.crashing.org wrote:
> >we should just deal with the RTC exactly how its delt with on x86, if
> >you have windows (or in our case MacOS) you tell hwclock the RTC is in
> >localtime and let it deal with it, if you don't have MacOS/windows you
> >tell it you have the RTC in GMT like its supposed to be and all is well.
>
> Which means that during boot, the kernel will have a wrong (local) time
> instead of UTC. That can be annoying.

only for a short period of time, look at debian woody for how they
invoke hwclock, it ensures this period is short.

but in any event its the price you pay for keeping a broken OS
installed and letting it control the hardware clock. it is certainly
not severe enough to justify all these fragile and broken kludges and
kernel bloat.

--
Ethan Benson
http://www.alaska.net/~erbenson/

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

Re: NVRAM stuck in DST?

[Greg Noel]

On Fri, 7 Dec 2001 08:59:14 +0100 (CET) Michel Lanners <mlan@cpu.lu> wrote:

>If not, then I'll be stuck with whatever NVRAM values MacOS wrote there
>when it was last booted. Which means that unless at every DST time
>change, unless I bo[o]t MacOS once, I'll be stuck with the wrong time....

One way to keep your UNIX clock correct is to run NTP; see www.ntp.org.
Then the only problem is that it no longer seems possible to get MOL to
synchronize with the UNIX clock, but that's another issue...

Hope this helps,
-- Greg Noel, retired UNIX guru


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

Re: NVRAM stuck in DST?

[Gabriel Paubert]

On Fri, 7 Dec 2001, Michel Lanners wrote:

>
> Hi all,
>
> For some time now (in fact since going back from summer time to winter
> time), my PowerMac 7500 gains one hour at very system boot. No matter
> how I configure it to save sytsem time as GMT or as localtime in the
> RTC, I _always_ get +1 hour on boot.

Do you use any program like adjtime, ntp or write directly to the clock
through the RTC driver ?

If it;s the former, I don't understand how it can happen since the
settimeofday/adjtimex interface will use the offset found in the NVRAM.

For the latter, your clock will be screwed up. But not consistently by 1
hour:

- at boot: read the clock which claims to be UT+2, substract 2 hours

- when writing system clock to RTC:
	- if localtime: write UT+1 to RTC, on next boot you will be
	one hour late
	- if UT: write system time to RTC, on next boot you will be
	two hours late

Unless I've got the signs wrong, your clock should be running late. And it
should depend on whether you are in UTC or not.

I agree there is a bug, but besides the fact that it's not easy to solve,
it should not produce the symptoms that you describe. IMHO time handling
should never go through the RTC driver to start with, or at least it
should be better abstracted: it's too important and too intimately related
to other parts of the kernel.

But believe me, you don't want to overwrite time offset of DST in the
NVRAM. Decent clocks are in UT or TAI...

>
> I've looked at kernel messages, and it says there:
>
> ...
> GMT Delta read from XPRAM: 120 minutes, DST: on
> ...
>
> Hmmm... DST on? That's wrong; we're not in DST anymore! And the current
> offset to GMT is one hour, not two hours. I'm wondering whether
> something else besides MacOS sets those values.

No, the only thing the kernel may overwrite is the time.

>
> If not, then I'll be stuck with whatever NVRAM values MacOS wrote there
> when it was last booted. Which means that unless at every DST time
> change, unless I bot MacOS once, I'll be stuck with the wrong time....

No, I don't think that it is the problem. I believe that the adjtimex
syscall should be enhanced to perform the task of saving time to RTC
when needed, because it is easier to abstract the platform specific
weirdness there than through the RTC driver.

>
> Also, just for my understanding, doesn't MacOS save the system time in
> the RTC in localtime?

It does, unfortunately (same for Windows).

> In that case I don't see how time _advances_ on
> boot... unless the MacOS RTC is in DST-less localtime.
>
> Anybody with more insight here?

Still trying to understand exactly what happens.

	Regards,
	Gabriel.


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