On 3 Jun, 01:03, Hans-Peter Diettrich wrote:
> Since some days my openSUSE 10.3 (64 bit) fails to set the system time
> to the (correct) BIOS time on startup, instead it seems to resume with
> the time of the last shutdown. Possibly with the correct date...
>
> On the same machine, Vista seems to continue to accept the BIOS time.
> The machine is half a year old, a battery problem is quite unlikely.
> Perhaps one of the latest updates prevents proper access to the RTC?
>
> In /var/log/boot.msg I found the following suspect entries:
>
> <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> <4>rtc_cmos: probe of 00:04 failed with error -16
>
> I have no idea what error -16 means, and how to cure that nasty
> behaviour at all :-(
>
> DoDi

Have you set the Linux time to use 'utc'? And is there some reason you
are not using NTP to reset your time at boot time and maintain it from
then on?

Nico Kadel-Garcia schrieb:

>> Since some days my openSUSE 10.3 (64 bit) fails to set the system time
>> to the (correct) BIOS time on startup, instead it seems to resume with
>> the time of the last shutdown. Possibly with the correct date...

> Have you set the Linux time to use 'utc'?

The RTC is set to local time, as required by some other systems on my
machine.

> And is there some reason you
> are not using NTP to reset your time at boot time and maintain it from
> then on?

Exactly this is my question ;-)

What may be the reasons for the described misbehaviour,
how can I find out what has changed in my system,
and how can I restore the initial behaviour?

I never had such problems before, and consequently know nothing about
the possibly related settings, processes, tools and procedures :-(


According to your hint I've looked for NTP (was disabled). Unfortunately
NTP requires access to an according network, and even if I have
permanent Internet access in theory, in practice Linux fails to
establish the connection to my WLAN every other day :-(

Nonetheless I enabled NTP now, and found in the configuration display an
hint:
"Undisciplined Local Clock (LOCAL)"
What does that mean?

DoDi

Hans-Peter Diettrich wrote:

> Nonetheless I enabled NTP now, and found in the
> configuration display an hint:
> "Undisciplined Local Clock (LOCAL)"
> What does that mean?

Different terminology. You call it RTC, NTP calls it
"undisciplined local clock". This is not some sort of
error message. I guess it's called undisciplined
because it doesn't synchronize with anything.


Regards,
Marcel

Marcel Bruinsma writes:

>Hans-Peter Diettrich wrote:

>> Nonetheless I enabled NTP now, and found in the
>> configuration display an hint:
>> "Undisciplined Local Clock (LOCAL)"
>> What does that mean?

>Different terminology. You call it RTC, NTP calls it
>"undisciplined local clock". This is not some sort of
>error message. I guess it's called undisciplined
>because it doesn't synchronize with anything.

What is your /etc/ntp.conf file? It sounds to me like you are trying to use
the local clock as one of your reference clocks-- an very silly idea.
That has nothing to do with the rtc.




>Regards,
>Marcel

Unruh wrote:

> What is your /etc/ntp.conf file? It sounds to me like you
> are trying to use the local clock as one of your reference
> clocks-- an very silly idea.

http://www.eecis.udel.edu/~mills/ntp...s/driver1.html

" Another application for this driver is if a particular
" server clock is to be used as the clock of last resort
" when all other normal synchronization sources have
" gone away.


Regards,
Marcel
--
printf -v email $(echo \ 155 141 162 143 145 154 155 141 162 \
143 145 154 100 157 162 141 156 147 145 56 156 154 | tr \ \\)
# O Herr, lass Hirn vom Himmel fallen! #

Hans-Peter Diettrich wrote:
> Nico Kadel-Garcia schrieb:
>
>>> Since some days my openSUSE 10.3 (64 bit) fails to set the system time
>>> to the (correct) BIOS time on startup, instead it seems to resume with
>>> the time of the last shutdown. Possibly with the correct date...
>
>> Have you set the Linux time to use 'utc'?
>
> The RTC is set to local time, as required by some other systems on my
> machine.
>
>> And is there some reason you
>> are not using NTP to reset your time at boot time and maintain it from
>> then on?
>
> Exactly this is my question ;-)
>
> What may be the reasons for the described misbehaviour,
> how can I find out what has changed in my system,
> and how can I restore the initial behaviour?
>
> I never had such problems before, and consequently know nothing about
> the possibly related settings, processes, tools and procedures :-(
>
>
> According to your hint I've looked for NTP (was disabled). Unfortunately
> NTP requires access to an according network, and even if I have
> permanent Internet access in theory, in practice Linux fails to
> establish the connection to my WLAN every other day :-(

Ahh. NTP is most effective when allowed to regularly synchronize. But other
tools, such as 'rdate', can be used to synchronize on a more predictable
basis. It's unclear why your clock winds up reset: time on a computer is
stored as a digital number, *relative to a specific date*, and what that
specific date is and the offsets for things like timezones wind up being
negotiated among the BIOS nad the operating system. It seems clear that your
different operating systems agree about how it's being stored on the BIOS, and
wind up resetting it for each other. Frustrating, that!

> Nonetheless I enabled NTP now, and found in the configuration display an
> hint:
> "Undisciplined Local Clock (LOCAL)"
> What does that mean?
>
> DoDi

A default NTP setup uses the'local' time, at a high numbered 'stratum', to
keep NTP from whining if there's no network connection available. That's what
you're seeing, I think. It prefers to use a lower "stratum", and will do so if
one is configured and available in your /etc/ntp.conf and on your network.

Marcel Bruinsma writes:

>Unruh wrote:

>> What is your /etc/ntp.conf file? It sounds to me like you
>> are trying to use the local clock as one of your reference
>> clocks-- an very silly idea.

>http://www.eecis.udel.edu/~mills/ntp...s/driver1.html

>" Another application for this driver is if a particular
>" server clock is to be used as the clock of last resort
>" when all other normal synchronization sources have
>" gone away.

It is still an EXTREmELY silly thing to do. It is there so that if you are
an ntp SERVER and for some reason all of your sync sources disappear, you
can still report to the machines downline that you are synced to something.
That something is absurd-- it is the clock itself. "My time is good because
I checked with myself and my clock agrees with itself". Do NOT use the
local as a server if you are a client, and do not use it if you are a
server unless you absolutely must Ie you will have 1000 people coming to
hang you because your server stopped serving ntp).

Unruh schrieb:

> What is your /etc/ntp.conf file? It sounds to me like you are trying to use
> the local clock as one of your reference clocks-- an very silly idea.
> That has nothing to do with the rtc.

ntp.conf states that it is the fallback (fake driver), when no other
sources are available.

DoDi

Marcel Bruinsma schrieb:

>> Nonetheless I enabled NTP now, and found in the
>> configuration display an hint:
>> "Undisciplined Local Clock (LOCAL)"
>> What does that mean?
>
> Different terminology. You call it RTC, NTP calls it
> "undisciplined local clock". This is not some sort of
> error message. I guess it's called undisciplined
> because it doesn't synchronize with anything.

I found it under "Synchronization Type" in the Advanced NTP Configuration.

For testing purposes, I removed the other (network based) sources.
Tomorrow I'll see what will happen on the next boot...

DoDi

Hans-Peter Diettrich wrote:
> According to your hint I've looked for NTP (was disabled). Unfortunately
> NTP requires access to an according network, and even if I have permanent
> Internet access in theory, in practice Linux fails to establish the
> connection to my WLAN every other day :-(

Install Chrony instead of Ntp.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

John Hasler schrieb:

> Install Chrony instead of Ntp.

I'd prefer to install nothing at all, and continue to use the RTC as was
working fine in the past decades. Then I know very soon, when it's time
to change the CMOS battery...

DoDi

Hans-Peter Diettrich writes:

>Unruh schrieb:

>> What is your /etc/ntp.conf file? It sounds to me like you are trying to use
>> the local clock as one of your reference clocks-- an very silly idea.
>> That has nothing to do with the rtc.

>ntp.conf states that it is the fallback (fake driver), when no other
>sources are available.

It is only of use (if then) if you are a server serving other machines. It
is of no use whatsoever for an ntp client. It should not be used for a
client.

Hans-Peter Diettrich wrote:
> Since some days my openSUSE 10.3 (64 bit) fails to set the system time
> to the (correct) BIOS time on startup, instead it seems to resume with
> the time of the last shutdown. Possibly with the correct date...
>
> On the same machine, Vista seems to continue to accept the BIOS time.
> The machine is half a year old, a battery problem is quite unlikely.
> Perhaps one of the latest updates prevents proper access to the RTC?
>
> In /var/log/boot.msg I found the following suspect entries:
>
> <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> <4>rtc_cmos: probe of 00:04 failed with error -16
>
> I have no idea what error -16 means, and how to cure that nasty
> behaviour at all :-(
>
> DoDi

The followin=g error message

> <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> <4>rtc_cmos: probe of 00:04 failed with error -16

Is most likely due to a differential syncing issue.

Fire Ant writes:

>Hans-Peter Diettrich wrote:
>> Since some days my openSUSE 10.3 (64 bit) fails to set the system time
>> to the (correct) BIOS time on startup, instead it seems to resume with
>> the time of the last shutdown. Possibly with the correct date...
>>
>> On the same machine, Vista seems to continue to accept the BIOS time.
>> The machine is half a year old, a battery problem is quite unlikely.
>> Perhaps one of the latest updates prevents proper access to the RTC?
>>
>> In /var/log/boot.msg I found the following suspect entries:
>>
>> <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
>> <4>rtc_cmos: probe of 00:04 failed with error -16
>>
>> I have no idea what error -16 means, and how to cure that nasty
>> behaviour at all :-(
>>
>> DoDi

>The followin=g error message

> > <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> > <4>rtc_cmos: probe of 00:04 failed with error -16

>Is most likely due to a differential syncing issue.

And what the hell does "differential syncing issue" mean? If you are
quoting from somewhere, tell us where. If this is your term, define it.

On 4 Jun, 07:41, Unruh wrote:
> Marcel Bruinsma writes:
> >Unruh wrote:
> >> What is your /etc/ntp.conf file? It sounds to me like you
> >> are trying to use the local clock as one of your reference
> >> clocks-- an very silly idea.
> >http://www.eecis.udel.edu/~mills/ntp...s/driver1.html
> >" Another application for this driver is if a particular
> >" server clock is to be used as the clock of last resort
> >" when all other normal synchronization sources have
> >" gone away.
>
> It is still an EXTREmELY silly thing to do. It is there so that if you are
> an ntp SERVER and for some reason all of your sync sources disappear, you
> can still report to the machines downline that you are synced to something.
> That something is absurd-- it is the clock itself. "My time is good because
> I checked with myself and my clock agrees with itself". Do NOT use the
> local as a server if you are a client, and do not use it if you are a
> server unless you absolutely must Ie you will have 1000 people coming to
> hang you because your server stopped serving ntp).

Silly or not, it's standard operating procedure. It's useful in
environments where, due to dial-up access or VPN access or irregular
wireless connectivity, your NTP connetion is not reliable, to prevent
NTP from having nothing at all to sycnrhonize to. The local clock is
considered a much lower 'stratum' than a normal external site, so will
not override it.

Nico Kadel-Garcia schrieb:

> Silly or not, it's standard operating procedure. It's useful in
> environments where, due to dial-up access or VPN access or irregular
> wireless connectivity, your NTP connetion is not reliable, to prevent
> NTP from having nothing at all to sycnrhonize to. The local clock is
> considered a much lower 'stratum' than a normal external site, so will
> not override it.

One of my problems seems to be a bug(?) in the RTC access, which
prevents to read out the RTC at boot time. At a later time hwclock
usually works, but then the system already has reverted to the time of
the last shutdown. And for more trouble, at every shutdown the current
(possibly wrong) system time is written into the RTC :-(

Where should I look, in order to disable writing back of the time at
shutdown?

DoDi

Fire Ant schrieb:

> The followin=g error message
>
> > <6>rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> > <4>rtc_cmos: probe of 00:04 failed with error -16
>
> Is most likely due to a differential syncing issue.

man hwclock says: "-16 clock not accessible", neither through the
installed driver, nor by direct IO. This may be a race condition, since
IMO direct IO should always work, and hwclock seems to work at some
later time.

DoDi