Re: Command to set hardware clock

Mark South <mark.south@xxxxxxxxxxxx> wrote:
> On Wed, 18 Jan 2006 16:13:57 +0000, jKILLSPAM.schipper wrote:
>
>> Mark South <mark.south@xxxxxxxxxxxx> wrote:
>>> On Tue, 17 Jan 2006 21:31:36 +0000, jKILLSPAM.schipper wrote:
>>>
>>>> Mark South <mark.south@xxxxxxxxxxxx> wrote:
>>>> I wasn't implying that this was a dumb question, as it does appear not
>>>> to have that simple an answer (it always Worked For Me, so I never
>>>> bothered to look into it).
>>>
>>> Fair enough. In this case, it seems not to work for me, and I need to
>>> know more to work around it and possibly learn enough to file a bug.
>>
>> Well, I don't think that is necessary - if what Peter wrote upthread is
>> correct, and I presume it is, then date(1) sets the hardware clock just
>> fine.
>
> Not for me on my machine. If it did, the query wouldn't have arisen.

Hmm... that's strange.

>>>> The function resettodr(9) is called in
>>>> /usr/src/sys/arch/i386/i386/machdep.c, or the equivalent for your
>>>> machine, in the function boot() - which, aptly named, handles shutdowns,
>>>> from the comments in the code. On my 3.8-stable machine, it's at line
>>>> 2282:
>>>>
>>>> if ((howto & RB_TIMEBAD) == 0) {
>>>> resettodr();
>>>> } else {
>>>> printf("WARNING: not updating battery clock\n");
>>>> }
>>>
>>> Hmm. I'm not seeing that warning.
>>
>> It is there on my box - are you looking at the -stable source?
>
> It's in my source. It doesn't appear on my console in the course of
> shutdown, and the clock is not set. That's what I meant by needing to
> know more.

Well, *do* observe that if the kernel thinks it knows what to do, the
message 'WARNING: not updating battery clock' shouldn't appear. But the
clock should be set.

>>>>>> Also, if the error is large, -current includes a fix that makes
>>>>>> adjtime() adjust time faster if it seems to be 'losing'.
>>>>>
>>>>> When one is connected, ntpd works fine at boot (although often
>>>>> frustratingly slowly). If the clock is way off, ntpd does not use
>>>>> the sequential application of adjtime() at all, it just bangs in the
>>>>> right time.
>>>>>
>>>>> This solution works well for a permanently connected server or
>>>>> desktop that's always on. It truly sucks for a portable that gets
>>>>> booted relatively often, and that may not be connected all the time
>>>>> (so one's email written offline has bogus timestamps, for example).
>>>>>
>>>>> There must be a simple, working, existing solution that I've
>>>>> overlooked??
>>>>
>>>> Yes, there is. The easy, slightly hackish way is described above.
>>>
>>> shutdown -r
>>
>> Again, no - see hostname.if(5) for the !command syntax.
>
> No longer relevant.

Well, it *is* relevant to the part of the question that mentioned that
running ntpd was a bit of a pain as the laptop was not always connected.

But it does not really help with hardware clocks, agreed.

>>>> However, I'd argue that banging in the right time is the more correct
>>>> solution. If the system can not accurately keep time, there's no need
>>>> to keep slewing - and while there are very real reasons not to kick
>>>> the clock around on live systems, a booting system isn't that live.
>>>
>>> Well, I'm grateful for the information provided, despairing at being
>>> disparaged for not knowing the answer before asking the question,
>>> amused at the belief that configuration through reboots is a normal
>>> part of life, accepting that no better solution is possible at present,
>>> and quietly out of here for now.
>>
>> Well, it is at least not necessary to reboot. And yes, the openbsd
>> community can be harsh - but that has its good effects, too (for one,
>> the seemingly endless numbers of people who are too lazy to read the
>> documentation asking truly stupid questions present in so many venues,
>> seems to be scared off - which is not a bad thing in my book).
>
> I'm still unconvinced that you are justified in considering the original
> question to be illegitimate.
>
> Naturally, it's pointless to try to legitimise the original question if
> the act of asking a question itself labels one as "too lazy to read the
> documentation". However, the absence of explicit mention of the hardware
> clock in the documentation makes that label less sticky.
>
> Admittedly, I didn't read the entire source, but "RTFS" seems an unfairly
> harsh response even by the BSD standards you espouse above.

Once again, I do not consider the original question illegitimate. I was
just trying to get across that there is some merit in the sometimes
heavy-handed approach in the OpenBSD community.

You are right that in this case, the documentation does not seem to
provide a clear answer; additionally, I can see how the question would
be useful. So I think it is a pretty legitimate question, even if it is
clearly from a Linux perspective. ;-)

And RTFS is an answer best reserved for people thinking they'll hack the
kernel between breakfast and lunch, and expect you to hand-walk them
through it. I don't think the community is nasty enough to visit this
answer upon the average clued question.

However, to tie stuff together: we found out that at least shutdown
should set the clock, and probably both ntpd and date should do
likewise; however, this does not appear to work on your hardware. Is
this correct?

I also gather that the system clock is set as it should be, and there
are no strange warnings in any log file (either by ntpd, date, or the
kernel), and that the system clock is read from the hardware clock at
boot.

If all that is correct, you should probably look up the brand of laptop
on the hardware page (www.openbsd.org/i386.html and the linked page
about laptops) and in the misc@ archives; if nothing comes up either
way, test the hardware using a different OS (something relatively close
to OpenBSD, like Net- or FreeBSD, would be best, especially if they *do*
work - as it is far easier to lift some code off them). If it works
under any OS (even Windows), try -current (which breaks occasionally,
but does have the latest fixes). If the clock works under some other OS
(so it's not just broken hardware) and -current does not fix your
problems, please file a bug report (see sendbug(1); all the stuff above
will make your bug that much easier to close, which will make it that
much more likely to be resolved quickly).

Joachim
.

Relevant Pages

  • Re: Coding style, wait statement, sensitivity list and synthesis.
    ... >> least assume that XST supports this style and create this hardware. ... >>>then the higher precedence clock must be coded first. ... For these very rare dual-edge sensitive register, yes, I think instantiation ... Dual-edge sensitive register elements is not common practice in hardware design. ...
    (comp.lang.vhdl)
  • Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays
    ... which is the same as the underlying hardware counter. ... So you are saying that you can trivally make it work with a clock that is, ... will never change while I am in the preempt disabled code. ... it's called from an IPI running on each CPU. ...
    (Linux-Kernel)
  • Re: Coding style, wait statement, sensitivity list and synthesis.
    ... Or they decided collectively not to implement the double-edge hardware feature to was that 1076.6 recommended it. ... there is a standard for coding styles? ... modeling the IBM style separate master-slave register hardware, which also allowed some pretty exotic scan/functional clock designs. ... In a design review, I require all multiple clock and clock ...
    (comp.lang.vhdl)
  • Re: Get time & milliseconds.
    ... The OAL has the implementation for GetSystemTime and SetSystemTime, so it can be adjusted to set and get it in any manner you desire, whether from hardware, NTP, a GPS receiver, an atomic clock or a sun dial is completely up to the OEM. ... Then when I need SystemTime with ms, ... adapt system tick to compensate drift. ...
    (microsoft.public.windowsce.app.development)
  • Re: HP Proliant SuSE 9.3 problems
    ... put SLES10 onto my Proliant I tried my trusty 9.3 which worked very well', ... get it to use the HP72x6 tape drive, some clash with the HP tape drivers ... The clock first though, the RTC clock isn't checked that often (once at ... Whats really odd is the fact that the system clock (not the hardware ...
    (alt.os.linux.suse)