Mike wrote:
On Mon, 27 Aug 2007, Tim wrote:
On Sun, 2007-08-26 at 16:26 -0700, Mike wrote:
Try 'cat /proc/interrupts | grep timer' two times or more.
Look at the number just to the right of '0:'
This should have incremented a bunch in between cat's. If it didn't
then you likely have a hardware problem or the timer is failing to get
initialized. If it is incrementing then I'm stumped...
I don't have the original poster's problem, but I tried that command to
see what happens. The same results, each time:
[root@bigblack ~]# cat /proc/interrupts | grep timer
0: 180 IO-APIC-edge timer
Weird. I wonder if there is another interrupt used to 'bump' the
clock? Just for grins try it w/o the grep. There should be a list of
a dozen or so interrupts. See if the line associated with rtc is
'racing'. Or maybe there's yet another interrupt used (other than
ethX, ideX etc.).
I had to do some precision timing in a previous life and had to muck
with this stuff back then. At the time and even on the three machines
I have here all use the timer interrupt to run the software clock. I
'spose other motherboards may do it differently...
-- Mike
My clock is fine and never seems to be more than a few seconds off.
Here is my test:
[root@k5di ~]# cat /proc/interrupts | grep timer
0: 807 IO-APIC-edge timer
[root@k5di ~]# cat /proc/interrupts | grep timer
0: 807 IO-APIC-edge timer
[root@k5di ~]# cat /proc/interrupts | grep timer
0: 807 IO-APIC-edge timer
[root@k5di ~]# cat /proc/interrupts | grep timer
0: 807 IO-APIC-edge timer
[root@k5di ~]#
It is not changing either but my clock is accurate :-)
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
