FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-27-2007, 08:36 AM
"Dean S. Messing"
 
Default Something Wicked (with my hdwr clock) This Way Comes

As root, I just tried doing: `hwclock --show' for the first time on my
new Dell Precision 490 running F7 and it just hung. Cntl-C broke me out.

I then tried `hwclock --show --debug' and got:

hwclock from util-linux-2.13-pre7
Using /dev/rtc interface to clock.
Last drift adjustment done at 1198717263 seconds after 1969
Last calibration done at 1198717263 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions.
Waiting in loop for time from /dev/rtc to change

and again the command hung.

I can't seem to set or read the hardware clock (except in the BIOS)
Anyone know what gives?

uname -a:

Linux medulla 2.6.23.8-34.fc7 #1 SMP Thu Nov 22 20:39:56 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

Dean

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-27-2007, 01:06 PM
Aaron Konstam
 
Default Something Wicked (with my hdwr clock) This Way Comes

On Thu, 2007-12-27 at 01:36 -0800, Dean S. Messing wrote:
> As root, I just tried doing: `hwclock --show' for the first time on my
> new Dell Precision 490 running F7 and it just hung. Cntl-C broke me out.
>
> I then tried `hwclock --show --debug' and got:
>
> hwclock from util-linux-2.13-pre7
> Using /dev/rtc interface to clock.
> Last drift adjustment done at 1198717263 seconds after 1969
> Last calibration done at 1198717263 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> /dev/rtc does not have interrupt functions.
> Waiting in loop for time from /dev/rtc to change
Yout problem is (compared to my results) on the line /dev/rtc does not
have interrupt function.
The end of my output is as follows:

>
--Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2007/12/27 08:00:14
Hw clock time : 2007/12/27 08:00:14 = 1198764014 seconds since 1969
Thu 27 Dec 2007 08:00:14 AM CST -0.605349 seconds

I would then look at the characteristics of /dev/rtc for the answer.
On my machine:
[root@cyrus ~]# ls -l /dev/rtc
crw-r--r-- 1 root root 10, 135 2007-12-27 01:37 /dev/rtc

================================================== =====================
The average income of the modern teenager is about 2 a.m.
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-27-2007, 10:18 PM
"Dean S. Messing"
 
Default Something Wicked (with my hdwr clock) This Way Comes

Aaron Konstam wrote:
: On Thu, 2007-12-27 at 01:36 -0800, Dean S. Messing wrote:
: > As root, I just tried doing: `hwclock --show' for the first time on my
: > new Dell Precision 490 running F7 and it just hung. Cntl-C broke me out.
: >
: > I then tried `hwclock --show --debug' and got:
: >
: > hwclock from util-linux-2.13-pre7
: > Using /dev/rtc interface to clock.
: > Last drift adjustment done at 1198717263 seconds after 1969
: > Last calibration done at 1198717263 seconds after 1969
: > Hardware clock is on UTC time
: > Assuming hardware clock is kept in UTC time.
: > Waiting for clock tick...
: > /dev/rtc does not have interrupt functions.
: > Waiting in loop for time from /dev/rtc to change
:
: Yout problem is (compared to my results) on the line /dev/rtc does not
: have interrupt function.
: The end of my output is as follows:
:
: --Hardware clock is on local time
: Assuming hardware clock is kept in local time.
: Waiting for clock tick...
: ...got clock tick
: Time read from Hardware Clock: 2007/12/27 08:00:14
: Hw clock time : 2007/12/27 08:00:14 = 1198764014 seconds since 1969
: Thu 27 Dec 2007 08:00:14 AM CST -0.605349 seconds
:
: I would then look at the characteristics of /dev/rtc for the answer.
: On my machine:
: [root@cyrus ~]# ls -l /dev/rtc
: crw-r--r-- 1 root root 10, 135 2007-12-27 01:37 /dev/rtc

On my system:

[root@medulla ~]# ls -l /dev/rtc
crw-r--r-- 1 root root 10, 135 2007-12-26 17:04 /dev/rtc

Would you post (or send me in private mail) the output of
uname -r please?

Mine:

[root@medulla ~]# uname -r
2.6.23.8-34.fc7

I wonder if this is a kernel bug?

When I search in "/var/log/dmesg" for "Real Time" I get the
following (with surrounding context):

ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed00000 is busy
Non-volatile memory driver v1.2
Linux agpgart interface v0.102

Search on "clock" also turns up (with context):

hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
Time: tsc clocksource has been installed.
pnp: 00:01: ioport range 0x800-0x85f has been reserved
pnp: 00:01: ioport range 0xc00-0xc7f has been reserved
pnp: 00:01: ioport range 0x860-0x8ff has been reserved

I'm not sure what any this means. "hpet" is the "high precision timer"
and the

hpet_resources: 0xfed00000 is busy

line is suspicious. I don't know what AE_NOT_FOUND refers to.

Anyway, I'm at the end of my knowledge here, but would very much
like to find a solution.

Thanks for your help.

Dean

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-27-2007, 10:51 PM
Tom Horsley
 
Default Something Wicked (with my hdwr clock) This Way Comes

On Thu, 27 Dec 2007 15:18:23 -0800 (PST)
"Dean S. Messing" <deanm@sharplabs.com> wrote:

> I'm not sure what any this means. "hpet" is the "high precision timer"
> and the
>
> hpet_resources: 0xfed00000 is busy

HPET huh? I am absolutely ignorant of the issues on this, but
I'm pretty sure I remember much cursing coming from the linux
kernel guys at work over HPETs. You might want to see if you
can find a linux kernel mailing list archive you can search
on the topic of HPET, perhaps something useful will crop up
(though every time I try to search lkml all I get is 100000
or so hits in the bodies of patches which contain no useful
text - someday I need to figure out if google can be induced
to ignore hits from inside things that look like context diffs).

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 12:07 AM
"Dean S. Messing"
 
Default Something Wicked (with my hdwr clock) This Way Comes

Tom Horsley worte:
: On Thu, 27 Dec 2007 15:18:23 -0800 (PST)
: "Dean S. Messing" <deanm@sharplabs.com> wrote:
:
: > I'm not sure what any this means. "hpet" is the "high precision timer"
: > and the
: >
: > hpet_resources: 0xfed00000 is busy
:
: HPET huh? I am absolutely ignorant of the issues on this, but
: I'm pretty sure I remember much cursing coming from the linux
: kernel guys at work over HPETs. You might want to see if you
: can find a linux kernel mailing list archive you can search
: on the topic of HPET, perhaps something useful will crop up
: (though every time I try to search lkml all I get is 100000
: or so hits in the bodies of patches which contain no useful
: text - someday I need to figure out if google can be induced
: to ignore hits from inside things that look like context diffs).

That was my experience last evening when I was looking for an answer.
Lot's of useless hits. A few old posts (c. 2002) with what appeared
to be my symptoms, a few newer. But no solutions.

What I'm trying to determine is, is this a problem with my system,
alone, or it it due to a kernel bug in combo with it.

I'd be interested to see if anyone else on the list running

F7_x86_64 and using the 2.6.23.8-34.fc7 kernel

is seeing `hwclock --show' hang.

Ok, something's going on here.

I just (as root) tried it twice in a row and:

[root@medulla ~]# hwclock --show
Thu 27 Dec 2007 12:55:36 AM PST -4.135175 seconds
[root@medulla ~]# hwclock --show
Timed out waiting for time change.

The first one took about 4 seconds to return by the bye.
The second one took much longer, maybe 50 seconds.
My CPU (on this quad CPU system) usage also shot up.
During that time the entire system became sluggish.

I currently have three parallel jigdo downloads running.
But they are eating almost no CPU of themselves.
I wonder if they might be involved.

Just killed them.

Nope. Made no difference. The command still hangs.

Arrrg!

Dean


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 02:27 AM
Tim
 
Default Something Wicked (with my hdwr clock) This Way Comes

On Thu, 2007-12-27 at 18:51 -0500, Tom Horsley wrote:
> someday I need to figure out if google can be induced to ignore hits
> from inside things that look like context diffs

You want to look at the advanced Google page, and their help guides, for
doing searches with multiple keywords using "and" or "not" operators.

Then you've got to figure out just what those keywords should be.
That's probably the harder part. "some keyword -diffs" probably isn't
going to be too good, as you can discard something inappropriately.

--
(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 11:50 AM
Aaron Konstam
 
Default Something Wicked (with my hdwr clock) This Way Comes

On Thu, 2007-12-27 at 15:18 -0800, Dean S. Messing wrote:
> Aaron Konstam wrote:
> : On Thu, 2007-12-27 at 01:36 -0800, Dean S. Messing wrote:
> : > As root, I just tried doing: `hwclock --show' for the first time on my
> : > new Dell Precision 490 running F7 and it just hung. Cntl-C broke me out.
> : >
> : > I then tried `hwclock --show --debug' and got:
> : >
> : > hwclock from util-linux-2.13-pre7
> : > Using /dev/rtc interface to clock.
> : > Last drift adjustment done at 1198717263 seconds after 1969
> : > Last calibration done at 1198717263 seconds after 1969
> : > Hardware clock is on UTC time
> : > Assuming hardware clock is kept in UTC time.
> : > Waiting for clock tick...
> : > /dev/rtc does not have interrupt functions.
> : > Waiting in loop for time from /dev/rtc to change
> :
> : Yout problem is (compared to my results) on the line /dev/rtc does not
> : have interrupt function.
> : The end of my output is as follows:
> :
> : --Hardware clock is on local time
> : Assuming hardware clock is kept in local time.
> : Waiting for clock tick...
> : ...got clock tick
> : Time read from Hardware Clock: 2007/12/27 08:00:14
> : Hw clock time : 2007/12/27 08:00:14 = 1198764014 seconds since 1969
> : Thu 27 Dec 2007 08:00:14 AM CST -0.605349 seconds
> :
> : I would then look at the characteristics of /dev/rtc for the answer.
> : On my machine:
> : [root@cyrus ~]# ls -l /dev/rtc
> : crw-r--r-- 1 root root 10, 135 2007-12-27 01:37 /dev/rtc
>
> On my system:
>
> [root@medulla ~]# ls -l /dev/rtc
> crw-r--r-- 1 root root 10, 135 2007-12-26 17:04 /dev/rtc
>
> Would you post (or send me in private mail) the output of
> uname -r please?
>
> Mine:
>
> [root@medulla ~]# uname -r
> 2.6.23.8-34.fc7

Mine is:
2.6.23.8-34.fc7

So there the same.
--
================================================== =====================
It'll be a nice world if they ever get it finished.
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 11:59 AM
Aaron Konstam
 
Default Something Wicked (with my hdwr clock) This Way Comes

>
> When I search in "/var/log/dmesg" for "Real Time" I get the
> following (with surrounding context):
>
> ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
> ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
> ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
> ACPI Exception (processor_core-0818): AE_NOT_FOUND, Processor Device is not present [20070126]
> Real Time Clock Driver v1.12ac
> hpet_resources: 0xfed00000 is busy
> Non-volatile memory driver v1.2
> Linux agpgart interface v0.102
I get just:Real Time Clock Driver v1.12ac
and no hpet entry.
--
================================================== =====================
The lion and the calf shall lie down together but the calf won't get
much sleep. -- Woody Allen
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
et just:

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 03:44 PM
"Jon Stanley"
 
Default Something Wicked (with my hdwr clock) This Way Comes

On 12/27/07, Dean S. Messing <deanm@sharplabs.com> wrote:

> I'd be interested to see if anyone else on the list running
>
> F7_x86_64 and using the 2.6.23.8-34.fc7 kernel

Fine here. This is F7 on a Dell Precision 390 (close to the OP's
hardware of a 490)

[root@rugrat ~]# uname -a
Linux rugrat.rmrf.net 2.6.23.8-34.fc7 #1 SMP Thu Nov 22 20:39:56 EST
2007 x86_64 x86_64 x86_64 GNU/Linux
[root@rugrat ~]# hwclock --show --debug
hwclock from util-linux-2.13-pre7
Using /dev/rtc interface to clock.
Last drift adjustment done at 1197746996 seconds after 1969
Last calibration done at 1197746996 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2007/12/28 16:43:54
Hw clock time : 2007/12/28 16:43:54 = 1198860234 seconds since 1969
Fri 28 Dec 2007 11:43:54 AM EST -0.371252 seconds
[root@rugrat ~]# hwclock --show --debug
hwclock from util-linux-2.13-pre7
Using /dev/rtc interface to clock.
Last drift adjustment done at 1197746996 seconds after 1969
Last calibration done at 1197746996 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2007/12/28 16:43:56
Hw clock time : 2007/12/28 16:43:56 = 1198860236 seconds since 1969
Fri 28 Dec 2007 11:43:56 AM EST -0.483039 seconds
[root@rugrat ~]#

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-28-2007, 10:23 PM
"Dean S. Messing"
 
Default Something Wicked (with my hdwr clock) This Way Comes

First, apologies for the long post!

On 12/27/07, Dean S. Messing <deanm@sharplabs.com> wrote:
> I'd be interested to see if anyone else on the list running
>
> F7_x86_64 and using the 2.6.23.8-34.fc7 kernel

Thanks you Aaron Konstam and Jon Stanley for confirming that `hwclock
--show' is working properly on your systems.

Somehow, my Real Time Clock got mangled. I'm not sure how. I had been
running some measurements with `adjtimex' and the output was going
totally bonkers. That's when I noticed my `hwclock' problem.

Upon shutting down, bringing up the BIOS, I saw that the RTC was
nearly 10 hours off of UTC.

So I reset it, rebooted, and now `hwclock --show' works correctly. I
don't understand why I (and you Jon) get the "/dev/rtc does not have
interrupt functions" but it _is_ getting the clock tick after all.

Still, there is some real strangeness going on which I explain
below.

Let me preface this by saying that I am not a n00bie at NTP, adjusting
kernel parameters related to time-keeping via `adjtimex', &c. I've
worked with this stuff for several years.

Jon, Aaron, I'd like to ask you both to run another test. (Thanks in
advance.) As root, what does

adjtimex --utc --compare=20 --interval=10 > /tmp/adj_file.txt

give you? (It will take about 3.5 minutes for this to run)
For the F7 machine on which I'm seeing the weird behaviour,
I get:


[root@medulla ~]# adjtimex --utc --compare=20 --interval=10
--- current --- -- suggested --
cmos time system-cmos error_ppm tick freq tick freq
1198880050 0.798082
1198880059 0.900194 10211.2 10000 10426576
1198880069 0.002171 -89802.3 10000 10426576 10899 4022989
1198880078 0.104114 10194.3 10000 10426576 9899 4246426
1198880087 0.206065 10195.1 10000 10426576 9899 4194864
1198880096 0.308030 10196.5 10000 10426576 9899 4102676
1198880105 0.409981 10195.1 10000 10426576 9899 4193301
1198880114 0.511942 10196.1 10000 10426576 9899 4129239
1198880123 0.612893 10095.1 10000 10426576 9900 4192826
1198880132 0.714856 10196.3 10000 10426576 9899 4116739
1198880141 0.816836 10198.0 10000 10426576 9899 4002676
1198880150 0.918770 10193.4 10000 10426576 9899 4305801
1198880160 0.020729 -89804.1 10000 10426576 10899 4141739
1198880169 0.122682 10195.3 10000 10426576 9899 4180801
1198880178 0.224641 10195.9 10000 10426576 9899 4141739
1198880187 0.326589 10194.8 10000 10426576 9899 4213614
1198880196 0.428548 10195.9 10000 10426576 9899 4141739
1198880205 0.530505 10195.7 10000 10426576 9899 4155801
1198880214 0.632459 10195.4 10000 10426576 9899 4174551
1198880223 0.734426 10196.7 10000 10426576 9899 4088614

The second column is in seconds and is the delta between the system
clock and the RTC. On a well tuned machine with an accurate RTC and a
system clock adjusted to run in sync with UTC (say, via NTP) this
number should be small (less than 1 second) and nearly constant.

The third column is the change in Parts per Million of the number in
Column 2 from one line to the next. It tells you how much the RTC is
deviating relative to the system clock. (100 ppm is 8.64 seconds per
day.)

As you can see, the system time appears to be advancing by almost
exactly 0.1 seconds every 10 seconds relative to the RTC (cmos clock).
Then, just as they are about to get out of phase by 1 second, something
causes either the system clock to "jump back" by ~1 second or the RTC
to jump forward.

It is certainly _not_ the system time doing the jumping. In fact:

[root@medulla ~]# ntpdate -q montpelier.ilan.caltech.edu
server 192.12.19.20, stratum 1, offset -0.001485, delay 0.05589
28 Dec 14:23:03 ntpdate[29445]: adjust time server 192.12.19.20 offset -0.001485 sec

which says that my system is about 1 ms ahead of
"montpelier.ilan.caltech.edu" which is a highly accurate Statum 1 time
server.

This delta is nearly constant so my system clock is not jumping
around.

That leaves the RTC doing the jumping. But having an RTC that is
runing nearly 10000 ppm slower than my system clock and which "jumps
ahead" every 10 seconds or so seems absurd.

Furthermore, when I halt the system, boot into the bios, and watch the
RTC time evolve I see no jumps and it is certainly not running 1/10
second slower than wall time.

That leaves two other possibilities: a bug in adjtimex or a bug in the
kernel. That's where I am right now.

Couple of other items:

If I increase the --interval, above, to 20 seconds, I get (in part)

[root@medulla ~]# adjtimex --utc --compare=20 --interval=20
--- current --- -- suggested --
cmos time system-cmos error_ppm tick freq tick freq
1198882092 0.313780
1198882111 0.415686 5095.3 10000 10426576
1198882130 0.516580 5044.7 10000 10426576 9951 942820
1198882149 0.617472 5044.6 10000 10426576 9951 950633
1198882168 0.718367 5044.8 10000 10426576 9951 939695
1198882187 0.820270 5095.1 10000 10426576 9950 4190951
1198882206 0.921165 5044.7 10000 10426576 9951 940476
1198882226 0.022069 -44954.8 10000 10426576 10451 910789
1198882245 0.122960 5044.6 10000 10426576 9951 952976
1198882264 0.224865 5095.2 10000 10426576 9950 4184701

The really odd thing is that the change in "system-cmos" from
line to line is still about 0.1 seconds! If the RTC were really
running slowly, it should be 0.2 seconds. In fact, no matter what
I make the interval, the 0.1 seconds remains the same.

So I vote for this being a bug in adjtimex (or the kernel).

Just as a reference here's the output of the same commond on my FC6 laptop
(whose sytem clock is also well sychronised with UTC):

[root@axon ~]# adjtimex --utc --compare=20 --interval=20
--- current --- -- suggested --
cmos time system-cmos error_ppm tick freq tick freq
1198882771 0.000563
1198882791 0.001026 23.1 10000 -580512
1198882811 0.000995 -1.5 10000 -580512 9999 6072345
1198882831 0.001093 4.9 10000 -580512 9999 5652814
1198882851 0.000830 -13.2 10000 -580512 10000 282026
1198882871 0.001060 11.5 10000 -580512 9999 5220782
1198882891 0.000850 -10.5 10000 -580512 10000 104683
1198882911 0.001099 12.4 10000 -580512 9999 5158282
1198882931 0.001014 -4.3 10000 -580512 9999 6252033
1198882951 0.001111 4.8 10000 -580512 9999 5656720


As you can see, the drift between the RTC and the system is quite low,
less than plus or minus 25ppm, and there's no wierd "jumping" going
on. (Well there _is_ the "11 minute kernel correction" but that's
another bedtime story.)

I have no idea what's happening on my F7 system to cause the strange
behaviour. Does anyone else?


Dean

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 01:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org