4:48 p.m.
I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
behavior about a week ago. Basically, the clock stopped working. If
I run 'date' it shows the date/time from a few days earlier, and it
*never* changes. If I touch a file, it has the date/timestamp from
the time/date in date output. The odd thing is that this behavior
only happens when the system sits relatively idle for a long chunk of
time (at least 24 hours). If i'm actively using it every day, then
its fine. If I reboot, then the problem goes away (and the system has
the correct time after rebooting).
The first time that this happened was last weekend (Aug 18), and I had
to reboot it last Monday (Aug 20) to fix the problem. Its now
happened again. At this moment in time, date claims that its Sat Aug
25, even though its actually Sun Aug 26 right now.
To make matters worse, the system behaves oddly when this problem
occurs. I suspect its because anything that relies on getting an
accurate (or changing) clock is failing. If I attempt to reboot
cleanly, it just never happens. The system acts frozen in time.
I've checked dmesg & messages, and there's nothing there. messages
just stops logging anything around the time that the clock appears to
have frozen.
Anyone ever seen this bizarre behavior, or have any ideas what might
be going on?
5:32 p.m.
Lonni J Friedman wrote:
I've got a Fedora 7 (x86) system that started exhibiting truly
bizarre
behavior about a week ago. Basically, the clock stopped working. If
I run 'date' it shows the date/time from a few days earlier, and it
*never* changes. If I touch a file, it has the date/timestamp from
the time/date in date output. The odd thing is that this behavior
only happens when the system sits relatively idle for a long chunk of
time (at least 24 hours). If i'm actively using it every day, then
its fine. If I reboot, then the problem goes away (and the system has
the correct time after rebooting).
The first time that this happened was last weekend (Aug 18), and I had
to reboot it last Monday (Aug 20) to fix the problem. Its now
happened again. At this moment in time, date claims that its Sat Aug
25, even though its actually Sun Aug 26 right now.
To make matters worse, the system behaves oddly when this problem
occurs. I suspect its because anything that relies on getting an
accurate (or changing) clock is failing. If I attempt to reboot
cleanly, it just never happens. The system acts frozen in time.
I've checked dmesg & messages, and there's nothing there. messages
just stops logging anything around the time that the clock appears to
have frozen.
Anyone ever seen this bizarre behavior, or have any ideas what might
be going on?
There is a battery on your motherboard and it has a clock that needs
the battery. Linux checks the computer battery every so often so check
that battery and replace if needed. I can cause all your problems.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
5:46 p.m.
On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
Lonni J Friedman wrote:
> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
> behavior about a week ago. Basically, the clock stopped working. If
> I run 'date' it shows the date/time from a few days earlier, and it
> *never* changes. If I touch a file, it has the date/timestamp from
> the time/date in date output. The odd thing is that this behavior
> only happens when the system sits relatively idle for a long chunk of
> time (at least 24 hours). If i'm actively using it every day, then
> its fine. If I reboot, then the problem goes away (and the system has
> the correct time after rebooting).
>
> The first time that this happened was last weekend (Aug 18), and I had
> to reboot it last Monday (Aug 20) to fix the problem. Its now
> happened again. At this moment in time, date claims that its Sat Aug
> 25, even though its actually Sun Aug 26 right now.
>
> To make matters worse, the system behaves oddly when this problem
> occurs. I suspect its because anything that relies on getting an
> accurate (or changing) clock is failing. If I attempt to reboot
> cleanly, it just never happens. The system acts frozen in time.
>
> I've checked dmesg & messages, and there's nothing there. messages
> just stops logging anything around the time that the clock appears to
> have frozen.
>
> Anyone ever seen this bizarre behavior, or have any ideas what might
> be going on?
>
>
There is a battery on your motherboard and it has a clock that needs
the battery. Linux checks the computer battery every so often so check
that battery and replace if needed. I can cause all your problems.
If it was the CMOS battery, why would it be working fine for days,
stop working, then start working again after a reboot?
Also, I've never heard of Linux being capable of checking the CMOS
battery. What specifically is doing this check?
Additionally, the CMOS battery is only needed when the system is
powered down and/or doesn't have external power. It certainly isn't
used to keep the system clock running while the system is running on
external power.
I appreciate your feedback, but what you're saying really doesn't make
any sense.
5:52 p.m.
Lonni J Friedman wrote:
On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
> Lonni J Friedman wrote:
>
>> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
>> behavior about a week ago. Basically, the clock stopped working. If
>> I run 'date' it shows the date/time from a few days earlier, and it
>> *never* changes. If I touch a file, it has the date/timestamp from
>> the time/date in date output. The odd thing is that this behavior
>> only happens when the system sits relatively idle for a long chunk of
>> time (at least 24 hours). If i'm actively using it every day, then
>> its fine. If I reboot, then the problem goes away (and the system has
>> the correct time after rebooting).
>>
>> The first time that this happened was last weekend (Aug 18), and I had
>> to reboot it last Monday (Aug 20) to fix the problem. Its now
>> happened again. At this moment in time, date claims that its Sat Aug
>> 25, even though its actually Sun Aug 26 right now.
>>
>> To make matters worse, the system behaves oddly when this problem
>> occurs. I suspect its because anything that relies on getting an
>> accurate (or changing) clock is failing. If I attempt to reboot
>> cleanly, it just never happens. The system acts frozen in time.
>>
>> I've checked dmesg & messages, and there's nothing there. messages
>> just stops logging anything around the time that the clock appears to
>> have frozen.
>>
>> Anyone ever seen this bizarre behavior, or have any ideas what might
>> be going on?
>>
>>
>>
> There is a battery on your motherboard and it has a clock that needs
> the battery. Linux checks the computer battery every so often so check
> that battery and replace if needed. I can cause all your problems.
>
If it was the CMOS battery, why would it be working fine for days,
stop working, then start working again after a reboot?
Also, I've never heard of Linux being capable of checking the CMOS
battery. What specifically is doing this check?
Additionally, the CMOS battery is only needed when the system is
powered down and/or doesn't have external power. It certainly isn't
used to keep the system clock running while the system is running on
external power.
I appreciate your feedback, but what you're saying really doesn't make
any sense.
Sorry but I wanted to say the battery runs a clock on your
motherboard that Linux reads from time to time. If the battery is dead
or weak it will not run the clock with accuracy.
Better?
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
6:21 p.m.
On Sun, 2007-08-26 at 16:52 -0600, Karl Larsen wrote:
>
Sorry but I wanted to say the battery runs a clock on your
motherboard that Linux reads from time to time. If the battery is dead
or weak it will not run the clock with accuracy.
Better?
That clock is only read on startup and set on shutdown or if directed to
by the user with the hwclock command. Once the system boots, a clock on
the CPU itself is the only one Linux cares about for time of day. If
NTP is enabled, it uses other sources on the local net or Internet to
help keep the CPU clock rate correct.
So dead motherboard "hardware clock" battery wouldn't explain issues
with the CPU "system clock".
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
6:26 p.m.
On Sun, 26 Aug 2007, Karl Larsen wrote:
Lonni J Friedman wrote:
> On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
>
>> Lonni J Friedman wrote:
>>
>>> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
>>> behavior about a week ago. Basically, the clock stopped working. If
>>> I run 'date' it shows the date/time from a few days earlier, and it
>>> *never* changes. If I touch a file, it has the date/timestamp from
>>> the time/date in date output. The odd thing is that this behavior
>>> only happens when the system sits relatively idle for a long chunk of
>>> time (at least 24 hours). If i'm actively using it every day, then
>>> its fine. If I reboot, then the problem goes away (and the system has
>>> the correct time after rebooting).
>>>
>>> The first time that this happened was last weekend (Aug 18), and I had
>>> to reboot it last Monday (Aug 20) to fix the problem. Its now
>>> happened again. At this moment in time, date claims that its Sat Aug
>>> 25, even though its actually Sun Aug 26 right now.
>>>
>>> To make matters worse, the system behaves oddly when this problem
>>> occurs. I suspect its because anything that relies on getting an
>>> accurate (or changing) clock is failing. If I attempt to reboot
>>> cleanly, it just never happens. The system acts frozen in time.
>>>
>>> I've checked dmesg & messages, and there's nothing there.
messages
>>> just stops logging anything around the time that the clock appears to
>>> have frozen.
>>>
>>> Anyone ever seen this bizarre behavior, or have any ideas what might
>>> be going on?
>>>
>>>
>>>
>> There is a battery on your motherboard and it has a clock that needs
>> the battery. Linux checks the computer battery every so often so check
>> that battery and replace if needed. I can cause all your problems.
>>
>
> If it was the CMOS battery, why would it be working fine for days,
> stop working, then start working again after a reboot?
>
> Also, I've never heard of Linux being capable of checking the CMOS
> battery. What specifically is doing this check?
>
> Additionally, the CMOS battery is only needed when the system is
> powered down and/or doesn't have external power. It certainly isn't
> used to keep the system clock running while the system is running on
> external power.
>
> I appreciate your feedback, but what you're saying really doesn't make
> any sense.
>
>
Sorry but I wanted to say the battery runs a clock on your motherboard
that Linux reads from time to time. If the battery is dead or weak it will
not run the clock with accuracy.
Better?
Nope, the battery backed CMOS clock is only read by the kernel at boot
time but never again. After that the "software" clock in the kernel is
updated by a hardware interrupt.
To the OP it almost sounds like a hardware problem.
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...
-- Mike
7:04 p.m.
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
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
7:26 p.m.
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
7:43 p.m.
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.
9:45 p.m.
Tim:
> 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
Mike:
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.).
[root@bigblack ~]# cat /proc/interrupts
CPU0
0: 179 IO-APIC-edge timer
1: 2 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc0
10: 0 IO-APIC-edge MPU401 UART
12: 4 IO-APIC-edge i8042
14: 13217 IO-APIC-edge libata
15: 1842 IO-APIC-edge libata
16: 3454 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2
17: 502 IO-APIC-fasteoi SiS SI7012, eth0
18: 17782 IO-APIC-fasteoi nvidia
20: 0 IO-APIC-fasteoi acpi
NMI: 0
LOC: 93114
ERR: 0
MIS: 0
I've rebooted since the last test, which probably accounts for the 179
where I previously had 180. But I get unchanging results, again. Each
iteration of the command produces the same results.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
10:13 p.m.
On Mon, 27 Aug 2007, Tim wrote:
Tim:
>> 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
Mike:
> 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.).
[root@bigblack ~]# cat /proc/interrupts
CPU0
0: 179 IO-APIC-edge timer
1: 2 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc0
10: 0 IO-APIC-edge MPU401 UART
12: 4 IO-APIC-edge i8042
14: 13217 IO-APIC-edge libata
15: 1842 IO-APIC-edge libata
16: 3454 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2
17: 502 IO-APIC-fasteoi SiS SI7012, eth0
18: 17782 IO-APIC-fasteoi nvidia
20: 0 IO-APIC-fasteoi acpi
NMI: 0
LOC: 93114
ERR: 0
MIS: 0
I've rebooted since the last test, which probably accounts for the 179
where I previously had 180. But I get unchanging results, again. Each
iteration of the command produces the same results.
So I guess I can write that off as a troubleshooting technique in newer
kernels. One more thing out of curiosity if you get a chance, does the
timestamp value in 'cat /proc/schedstat' change on subsequent views?
-- Mike
10:34 p.m.
On Sun, 2007-08-26 at 20:13 -0700, Mike wrote:
One more thing out of curiosity if you get a chance, does the
timestamp value in 'cat /proc/schedstat' change on subsequent views?
Yes:
[tim@bigblack ~]$ cat /proc/schedstat
version 14
timestamp 3094781
cpu0 0 76 0 120 0 1948477 247186 1023442 1023442 362174604379 42660632621 1701291
domain0 00000001 29836 29836 0 0 0 0 0 29836 2725 2725 0 0 0 0 0 2725 247186 247186 0 0 0
0 0 247186 0 0 0 0 0 0 0 0 0 0 0 0
[tim@bigblack ~]$
[tim@bigblack ~]$
[tim@bigblack ~]$ cat /proc/schedstat
version 14
timestamp 3096517
cpu0 0 76 0 120 0 1948978 247301 1023722 1023722 362224787115 42667340342 1701677
domain0 00000001 29841 29841 0 0 0 0 0 29841 2727 2727 0 0 0 0 0 2727 247301 247301 0 0 0
0 0 247301 0 0 0 0 0 0 0 0 0 0 0 0
[tim@bigblack ~]$ cat /proc/schedstat
version 14
timestamp 3098499
cpu0 0 76 0 120 0 1949378 247401 1023957 1023957 362264506717 42677219891 1701977
domain0 00000001 29846 29846 0 0 0 0 0 29846 2730 2730 0 0 0 0 0 2730 247401 247401 0 0 0
0 0 247401 0 0 0 0 0 0 0 0 0 0 0 0
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
3:41 a.m.
On Sun, 2007-08-26 at 20:13 -0700, Mike wrote:
On Mon, 27 Aug 2007, Tim wrote:
> Tim:
>>> 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
>
> Mike:
>> 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.).
>
> [root@bigblack ~]# cat /proc/interrupts
> CPU0
> 0: 179 IO-APIC-edge timer
> 1: 2 IO-APIC-edge i8042
> 6: 5 IO-APIC-edge floppy
> 7: 0 IO-APIC-edge parport0
> 8: 0 IO-APIC-edge rtc0
> 10: 0 IO-APIC-edge MPU401 UART
> 12: 4 IO-APIC-edge i8042
> 14: 13217 IO-APIC-edge libata
> 15: 1842 IO-APIC-edge libata
> 16: 3454 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2
> 17: 502 IO-APIC-fasteoi SiS SI7012, eth0
> 18: 17782 IO-APIC-fasteoi nvidia
> 20: 0 IO-APIC-fasteoi acpi
> NMI: 0
> LOC: 93114
> ERR: 0
> MIS: 0
>
> I've rebooted since the last test, which probably accounts for the 179
> where I previously had 180. But I get unchanging results, again. Each
> iteration of the command produces the same results.
>
So I guess I can write that off as a troubleshooting technique in newer
kernels. One more thing out of curiosity if you get a chance, does the
timestamp value in 'cat /proc/schedstat' change on subsequent views?
I guess you were expecting something more like this:
$ cat /proc/interrupts | grep timer
0: 611209 XT-PIC-XT timer
$ cat /proc/interrupts | grep timer
0: 611766 XT-PIC-XT timer
$ cat /proc/interrupts | grep timer
0: 612404 XT-PIC-XT timer
Now I wonder why mine isn't like the others. This is off a Thinkpad T41
running kernel-2.6.22.4-65.fc7.
Interestingly, an old P-III server in the closet looks more like the
above report:
0: 842 IO-APIC-edge timer
with no change over several checks.
-- Mike
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
9:22 a.m.
On 8/26/07, Mike <azmr(a)earthlink.net> wrote:
On Mon, 27 Aug 2007, Tim wrote:
> Tim:
>>> 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
>
> Mike:
>> 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.).
>
> [root@bigblack ~]# cat /proc/interrupts
> CPU0
> 0: 179 IO-APIC-edge timer
> 1: 2 IO-APIC-edge i8042
> 6: 5 IO-APIC-edge floppy
> 7: 0 IO-APIC-edge parport0
> 8: 0 IO-APIC-edge rtc0
> 10: 0 IO-APIC-edge MPU401 UART
> 12: 4 IO-APIC-edge i8042
> 14: 13217 IO-APIC-edge libata
> 15: 1842 IO-APIC-edge libata
> 16: 3454 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2
> 17: 502 IO-APIC-fasteoi SiS SI7012, eth0
> 18: 17782 IO-APIC-fasteoi nvidia
> 20: 0 IO-APIC-fasteoi acpi
> NMI: 0
> LOC: 93114
> ERR: 0
> MIS: 0
>
> I've rebooted since the last test, which probably accounts for the 179
> where I previously had 180. But I get unchanging results, again. Each
> iteration of the command produces the same results.
>
So I guess I can write that off as a troubleshooting technique in newer
kernels. One more thing out of curiosity if you get a chance, does the
timestamp value in 'cat /proc/schedstat' change on subsequent views?
The timer in /proc/interrupts was not changing, and neither was the
timestamp in /proc/schedstat. ugh.
2:27 p.m.
On Mon, 27 Aug 2007, Lonni J Friedman wrote:
The timer in /proc/interrupts was not changing, and neither was the
timestamp in /proc/schedstat. ugh.
Sorry for the confusion. Andy Green's posts clear this up and hopefully
this will clarify somewhat too.
For aeon's, well maybe centuries, ok really just decades the majority of
OS'es that run on PC's used IRQ0 to update the real time clock. What this
means is that 100 times a second (100 Hz) the kernel (in the case of
linux) is interrupted and the real time clock is updated among other
things then the kernel goes about it's business. To get better resolution
the 100 Hz parameter is changeable at compile time to 100, 250 or 1000 (I
believe). I think it defaulted to 1000Hz recently. In any case as Andy
Green pointed out modern kernels have gone "tickless". This is a very
good thing for laptops and saving power etc.
From what I have read HPET or High Precision Event Timer is what is
used
now (in the 2.6.21 or so kernel timeframe and beyond). HPET is a device
that is part of the chipsets on modern motherboards. From what I've been
told the HPET code is broken in some kernel versions (I mean hey it's
brand new code, sure could be buggy).
So to the original poster (Lonni J Friedman?) I'd suggest (as Andy
mentioned) check to see what your clocksource is:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
If it says 'hpet' reboot your machine and pass 'hpet=disable' to the
kernal via grub. I don't have a machine that I can reboot at the moment,
but IIRC at the grub prompt you press 'e' to edit the command before
booting. From there I forget but google should help find the syntax. Or
perhaps it's even self explanatory.
In any case this should force your machine to keep time the old fashioned
way which unless you're on a laptop should be just fine. And if this
works you can edit grub.conf (I believe) and 'hpet=disable' to make this
permanent.
-- Mike
2:32 p.m.
On 8/27/07, Mike <azmr(a)earthlink.net> wrote:
On Mon, 27 Aug 2007, Lonni J Friedman wrote:
>
> The timer in /proc/interrupts was not changing, and neither was the
> timestamp in /proc/schedstat. ugh.
>
Sorry for the confusion. Andy Green's posts clear this up and hopefully
this will clarify somewhat too.
For aeon's, well maybe centuries, ok really just decades the majority of
OS'es that run on PC's used IRQ0 to update the real time clock. What this
means is that 100 times a second (100 Hz) the kernel (in the case of
linux) is interrupted and the real time clock is updated among other
things then the kernel goes about it's business. To get better resolution
the 100 Hz parameter is changeable at compile time to 100, 250 or 1000 (I
believe). I think it defaulted to 1000Hz recently. In any case as Andy
Green pointed out modern kernels have gone "tickless". This is a very
good thing for laptops and saving power etc.
>From what I have read HPET or High Precision Event Timer is what is used
now (in the 2.6.21 or so kernel timeframe and beyond). HPET is a device
that is part of the chipsets on modern motherboards. From what I've been
told the HPET code is broken in some kernel versions (I mean hey it's
brand new code, sure could be buggy).
So to the original poster (Lonni J Friedman?) I'd suggest (as Andy
mentioned) check to see what your clocksource is:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
If it says 'hpet' reboot your machine and pass 'hpet=disable' to the
kernal via grub. I don't have a machine that I can reboot at the moment,
but IIRC at the grub prompt you press 'e' to edit the command before
booting. From there I forget but google should help find the syntax. Or
perhaps it's even self explanatory.
In any case this should force your machine to keep time the old fashioned
way which unless you're on a laptop should be just fine. And if this
works you can edit grub.conf (I believe) and 'hpet=disable' to make this
permanent.
My system doesn't have HPET. Also, to clarify, the problem only
happens after some unknown period of uptime. The system had been up
for like 100 days prior to the first occurance, and was up for just 3
days after the 2nd occurance. Its not always present. So clearly
something is very broken somewhere, and isn't going to be fixed just
by disabling hpet at boot. My best guess is flaky hardware. I'll be
running memtest86+ tonight. If that checks out, then I can only
assume that the CPU (Athlon64X2) is dying.
3:21 p.m.
On Monday August 27 2007 3:32:56 pm Lonni J Friedman wrote:
My best guess is flaky hardware. I'll be
running memtest86+ tonight. If that checks out, then I can
only assume that the CPU (Athlon64X2) is dying.
http://tinyurl.com/33b7ka
--
Claude Jones
Brunswick, MD, USA
4:05 p.m.
On 8/27/07, Claude Jones <cjones(a)levitjames.com> wrote:
On Monday August 27 2007 3:32:56 pm Lonni J Friedman wrote:
> My best guess is flaky hardware. I'll be
> running memtest86+ tonight. If that checks out, then I can
> only assume that the CPU (Athlon64X2) is dying.
http://tinyurl.com/33b7ka
How would the "AMD graphics products troubleshooter" help me with a
non-graphics product problem?
8:44 p.m.
On Mon August 27 2007, Lonni J Friedman wrote:
On Monday August 27 2007 3:32:56 pm Lonni J Friedman wrote:
> > .................................................... then I can
> > only assume that the CPU (Athlon64X2) is dying.
>
> http://tinyurl.com/33b7ka
How would the "AMD graphics products troubleshooter" help me with a
non-graphics product problem?
Was trying to turn a table and all I got was a bloody chair - but, I'm sure
you got it, wise one.
--
Claude Jones
Brunswick, MD, USA
11:51 a.m.
On 8/27/07, Lonni J Friedman <netllama(a)gmail.com> wrote:
On 8/27/07, Mike <azmr(a)earthlink.net> wrote:
> On Mon, 27 Aug 2007, Lonni J Friedman wrote:
>
> >
> > The timer in /proc/interrupts was not changing, and neither was the
> > timestamp in /proc/schedstat. ugh.
> >
>
> Sorry for the confusion. Andy Green's posts clear this up and hopefully
> this will clarify somewhat too.
>
> For aeon's, well maybe centuries, ok really just decades the majority of
> OS'es that run on PC's used IRQ0 to update the real time clock. What this
> means is that 100 times a second (100 Hz) the kernel (in the case of
> linux) is interrupted and the real time clock is updated among other
> things then the kernel goes about it's business. To get better resolution
> the 100 Hz parameter is changeable at compile time to 100, 250 or 1000 (I
> believe). I think it defaulted to 1000Hz recently. In any case as Andy
> Green pointed out modern kernels have gone "tickless". This is a very
> good thing for laptops and saving power etc.
>
> >From what I have read HPET or High Precision Event Timer is what is used
> now (in the 2.6.21 or so kernel timeframe and beyond). HPET is a device
> that is part of the chipsets on modern motherboards. From what I've been
> told the HPET code is broken in some kernel versions (I mean hey it's
> brand new code, sure could be buggy).
>
> So to the original poster (Lonni J Friedman?) I'd suggest (as Andy
> mentioned) check to see what your clocksource is:
>
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> If it says 'hpet' reboot your machine and pass 'hpet=disable' to
the
> kernal via grub. I don't have a machine that I can reboot at the moment,
> but IIRC at the grub prompt you press 'e' to edit the command before
> booting. From there I forget but google should help find the syntax. Or
> perhaps it's even self explanatory.
>
> In any case this should force your machine to keep time the old fashioned
> way which unless you're on a laptop should be just fine. And if this
> works you can edit grub.conf (I believe) and 'hpet=disable' to make this
> permanent.
My system doesn't have HPET. Also, to clarify, the problem only
happens after some unknown period of uptime. The system had been up
for like 100 days prior to the first occurance, and was up for just 3
days after the 2nd occurance. Its not always present. So clearly
something is very broken somewhere, and isn't going to be fixed just
by disabling hpet at boot. My best guess is flaky hardware. I'll be
running memtest86+ tonight. If that checks out, then I can only
assume that the CPU (Athlon64X2) is dying.
Just to close the loop, this turned out to be a kernel bug. Booting
with nohz=off completely eliminated the problem. This is a tickless
kernel bug.
2:30 p.m.
To return to this thread, i'm now seeing this same problem on a
*second* system running Fedora 7 (x86). So this is most definitely
not a hardware problem. The 2nd system does not have the same
motherboard as the 1st, so its not even a motherboard specific
problem. The only commonality between the two systems is that they
both have AMD CPUs, however one system is dual core, the other is not.
Again, this problem only seems to happen if the system is sitting idle
(like over the past 3 day weekend). Beyond that, I can't find any way
to deterministically trigger the behavior. Surely, I can't be in some
weird bermuda triangle where my systems all hit this weirdness, yet no
one else?
On 8/26/07, Mike <azmr(a)earthlink.net> wrote:
On Mon, 27 Aug 2007, Tim wrote:
> Tim:
>>> 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
>
> Mike:
>> 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.).
>
> [root@bigblack ~]# cat /proc/interrupts
> CPU0
> 0: 179 IO-APIC-edge timer
> 1: 2 IO-APIC-edge i8042
> 6: 5 IO-APIC-edge floppy
> 7: 0 IO-APIC-edge parport0
> 8: 0 IO-APIC-edge rtc0
> 10: 0 IO-APIC-edge MPU401 UART
> 12: 4 IO-APIC-edge i8042
> 14: 13217 IO-APIC-edge libata
> 15: 1842 IO-APIC-edge libata
> 16: 3454 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2
> 17: 502 IO-APIC-fasteoi SiS SI7012, eth0
> 18: 17782 IO-APIC-fasteoi nvidia
> 20: 0 IO-APIC-fasteoi acpi
> NMI: 0
> LOC: 93114
> ERR: 0
> MIS: 0
>
> I've rebooted since the last test, which probably accounts for the 179
> where I previously had 180. But I get unchanging results, again. Each
> iteration of the command produces the same results.
>
So I guess I can write that off as a troubleshooting technique in newer
kernels. One more thing out of curiosity if you get a chance, does the
timestamp value in 'cat /proc/schedstat' change on subsequent views?
-- Mike
9:23 a.m.
On Mon, 2007-08-27 at 09:34 +0930, 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:
I get different results. Maybe your
clock , Tim, is also not running :-)
--
=======================================================================
Power tends to corrupt, absolute power corrupts absolutely. -- Lord
Acton
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
10:45 a.m.
On Mon, 2007-08-27 at 09:23 -0500, Aaron Konstam wrote:
I get different results. Maybe your clock , Tim, is also not
running :-)
My personal clock? How did you know?! It stopped working about
9:40. ;-)
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
7:51 p.m.
Mike wrote:
Nope, the battery backed CMOS clock is only read by the kernel at boot
time but never again. After that the "software" clock in the kernel is
updated by a hardware interrupt.
You may want to read about some of the new power saving changes
being made to the kernel. I can not find the URL right now, but
there was a thread here talking about powertop, and it had a pointer
to the tickless kernel mods that let the kernel sleep when noting is
going on. It is my understanding that the kernel does not wake up
for clock ticks, and so it must re-read the hardware clock. Note
that this is for both laptops and servers. (It cuts down on both
power consumption and heat buildup...)
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
5:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/26/2007 05:46 PM, Lonni J Friedman wrote:
On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
> Lonni J Friedman wrote:
>> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
>> behavior about a week ago. Basically, the clock stopped working. If
>> I run 'date' it shows the date/time from a few days earlier, and it
>> *never* changes. If I touch a file, it has the date/timestamp from
>> the time/date in date output. The odd thing is that this behavior
>> only happens when the system sits relatively idle for a long chunk of
>> time (at least 24 hours). If i'm actively using it every day, then
>> its fine. If I reboot, then the problem goes away (and the system has
>> the correct time after rebooting).
>>
>> The first time that this happened was last weekend (Aug 18), and I had
>> to reboot it last Monday (Aug 20) to fix the problem. Its now
>> happened again. At this moment in time, date claims that its Sat Aug
>> 25, even though its actually Sun Aug 26 right now.
>>
>> To make matters worse, the system behaves oddly when this problem
>> occurs. I suspect its because anything that relies on getting an
>> accurate (or changing) clock is failing. If I attempt to reboot
>> cleanly, it just never happens. The system acts frozen in time.
>>
>> I've checked dmesg & messages, and there's nothing there. messages
>> just stops logging anything around the time that the clock appears to
>> have frozen.
>>
>> Anyone ever seen this bizarre behavior, or have any ideas what might
>> be going on?
>>
>>
> There is a battery on your motherboard and it has a clock that needs
> the battery. Linux checks the computer battery every so often so check
> that battery and replace if needed. I can cause all your problems.
If it was the CMOS battery, why would it be working fine for days,
stop working, then start working again after a reboot?
Also, I've never heard of Linux being capable of checking the CMOS
battery. What specifically is doing this check?
Additionally, the CMOS battery is only needed when the system is
powered down and/or doesn't have external power. It certainly isn't
used to keep the system clock running while the system is running on
external power.
I appreciate your feedback, but what you're saying really doesn't make
any sense.
Does your system go into a suspended mode when not being actively used
for some time?
(The real test for the CMOS is to see what the time is on boot in BIOS.
When Fedora boots, it will synch with a time server if ntpd is enabled.
However, I agree this is not likely to be a battery issue.)
- --
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG0gU5eERILVgMyvARAhvwAJ43172N6XWV4ERyhBKG7O4YwUcxDQCfcJnw
2ld1apnZJEmsXJwfwTI8RY8=
=2kxn
-----END PGP SIGNATURE-----
6:13 p.m.
On 8/26/07, Steven Stern <subscribed-lists(a)sterndata.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/26/2007 05:46 PM, Lonni J Friedman wrote:
> On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
>> Lonni J Friedman wrote:
>>> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
>>> behavior about a week ago. Basically, the clock stopped working. If
>>> I run 'date' it shows the date/time from a few days earlier, and it
>>> *never* changes. If I touch a file, it has the date/timestamp from
>>> the time/date in date output. The odd thing is that this behavior
>>> only happens when the system sits relatively idle for a long chunk of
>>> time (at least 24 hours). If i'm actively using it every day, then
>>> its fine. If I reboot, then the problem goes away (and the system has
>>> the correct time after rebooting).
>>>
>>> The first time that this happened was last weekend (Aug 18), and I had
>>> to reboot it last Monday (Aug 20) to fix the problem. Its now
>>> happened again. At this moment in time, date claims that its Sat Aug
>>> 25, even though its actually Sun Aug 26 right now.
>>>
>>> To make matters worse, the system behaves oddly when this problem
>>> occurs. I suspect its because anything that relies on getting an
>>> accurate (or changing) clock is failing. If I attempt to reboot
>>> cleanly, it just never happens. The system acts frozen in time.
>>>
>>> I've checked dmesg & messages, and there's nothing there.
messages
>>> just stops logging anything around the time that the clock appears to
>>> have frozen.
>>>
>>> Anyone ever seen this bizarre behavior, or have any ideas what might
>>> be going on?
>>>
>>>
>> There is a battery on your motherboard and it has a clock that needs
>> the battery. Linux checks the computer battery every so often so check
>> that battery and replace if needed. I can cause all your problems.
>
> If it was the CMOS battery, why would it be working fine for days,
> stop working, then start working again after a reboot?
>
> Also, I've never heard of Linux being capable of checking the CMOS
> battery. What specifically is doing this check?
>
> Additionally, the CMOS battery is only needed when the system is
> powered down and/or doesn't have external power. It certainly isn't
> used to keep the system clock running while the system is running on
> external power.
>
> I appreciate your feedback, but what you're saying really doesn't make
> any sense.
>
Does your system go into a suspended mode when not being actively used
for some time?
No, it doesn't. I should note that I've been using this same system
for nearly a year now, and its been rock solid stable until last
weekend.
(The real test for the CMOS is to see what the time is on boot in BIOS.
When Fedora boots, it will synch with a time server if ntpd is enabled.
However, I agree this is not likely to be a battery issue.)
The time is accurate when the system POSTs (and in the SBIOS), so I'm
pretty confident that this isn't the CMOS battery dying.
7:44 p.m.
On Sun, 2007-08-26 at 16:13 -0700, Lonni J Friedman wrote:
On 8/26/07, Steven Stern <subscribed-lists(a)sterndata.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/26/2007 05:46 PM, Lonni J Friedman wrote:
> > On 8/26/07, Karl Larsen <k5di(a)zianet.com> wrote:
> >> Lonni J Friedman wrote:
> >>> I've got a Fedora 7 (x86) system that started exhibiting truly
bizarre
> >>> behavior about a week ago. Basically, the clock stopped working. If
> >>> I run 'date' it shows the date/time from a few days earlier,
and it
> >>> *never* changes. If I touch a file, it has the date/timestamp from
> >>> the time/date in date output. The odd thing is that this behavior
> >>> only happens when the system sits relatively idle for a long chunk of
> >>> time (at least 24 hours). If i'm actively using it every day,
then
> >>> its fine. If I reboot, then the problem goes away (and the system has
> >>> the correct time after rebooting).
> >>>
> >>> The first time that this happened was last weekend (Aug 18), and I had
> >>> to reboot it last Monday (Aug 20) to fix the problem. Its now
> >>> happened again. At this moment in time, date claims that its Sat Aug
> >>> 25, even though its actually Sun Aug 26 right now.
> >>>
> >>> To make matters worse, the system behaves oddly when this problem
> >>> occurs. I suspect its because anything that relies on getting an
> >>> accurate (or changing) clock is failing. If I attempt to reboot
> >>> cleanly, it just never happens. The system acts frozen in time.
> >>>
> >>> I've checked dmesg & messages, and there's nothing there.
messages
> >>> just stops logging anything around the time that the clock appears to
> >>> have frozen.
> >>>
> >>> Anyone ever seen this bizarre behavior, or have any ideas what might
> >>> be going on?
> >>>
> >>>
> >> There is a battery on your motherboard and it has a clock that needs
> >> the battery. Linux checks the computer battery every so often so check
> >> that battery and replace if needed. I can cause all your problems.
> >
> > If it was the CMOS battery, why would it be working fine for days,
> > stop working, then start working again after a reboot?
> >
> > Also, I've never heard of Linux being capable of checking the CMOS
> > battery. What specifically is doing this check?
> >
> > Additionally, the CMOS battery is only needed when the system is
> > powered down and/or doesn't have external power. It certainly isn't
> > used to keep the system clock running while the system is running on
> > external power.
> >
> > I appreciate your feedback, but what you're saying really doesn't make
> > any sense.
> >
>
> Does your system go into a suspended mode when not being actively used
> for some time?
No, it doesn't. I should note that I've been using this same system
for nearly a year now, and its been rock solid stable until last
weekend.
>
> (The real test for the CMOS is to see what the time is on boot in BIOS.
> When Fedora boots, it will synch with a time server if ntpd is enabled.
> However, I agree this is not likely to be a battery issue.)
The time is accurate when the system POSTs (and in the SBIOS), so I'm
pretty confident that this isn't the CMOS battery dying.
On most systems the battery only comes into play when the system power
is off. The battery is on charge the rest of the time, and if the
battery is shorted, it can load the powersupply and affect the clock and
CMOS stuff (If there is CMOS stuff any more?)
Regards,
Les H
9:49 p.m.
On Sun, 2007-08-26 at 17:44 -0700, Les wrote:
On most systems the battery only comes into play when the system
power
is off. The battery is on charge the rest of the time,
It's been a very long time since I've seen a rechargable battery for the
BIOS memory power on a PC. All the ones I've seen use a watch battery
cell.
NB: I mean Personal Computer, when I say PC. I don't work with real
servers, and I wouldn't call them a PC.
and if the battery is shorted, it can load the powersupply and
affect
the clock and CMOS stuff (If there is CMOS stuff any more?)
There's still plenty of CMOS technology around, but I haven't looked
into what's actually used with the BIOS, these days.
Out of the motherboards that I've looked at, the power to that section
has been diode and resistor coupled. It'd be difficult to produce a
dead short to the supply from the battery terminals.
You wouldn't want to short some of those button cell batteries, they can
get damn hot.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
4:22 a.m.
Somebody in the thread at some point said:
I've got a Fedora 7 (x86) system that started exhibiting truly
bizarre
behavior about a week ago. Basically, the clock stopped working. If
I run 'date' it shows the date/time from a few days earlier, and it
Recent kernels have become "tickless", a neat idea to stop regular
wakeups hundreds of times a second and save on power. AIUI to track
time it now refers to a hardware "clocksource" to find out time instead
of counting the "tick" interrupts.
You can find out what hardware clocksources you have on your machine
like this
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
For example I get
hpet hpet acpi_pm jiffies tsc
(hpet twice? maybe due to dualcore?). You can find out the clocksource
you are currently using here
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet is the latest and greatest, but what I would try is to force the
kernel to use something other than it is using at the moment, by
something like this
clocksource=tsc
on the kernel commandline, and see if that makes any odds.
-Andy
5:30 a.m.
Andy Green wrote:
Somebody in the thread at some point said:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
For interest, Asus a7n8x gives: tsc acpi_pm pit jiffies
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
Which is tracking time OK, machine not touched for 7 hours overnight,
and 10 hours today.
DaveT.
9:36 a.m.
On Mon, 2007-08-27 at 10:22 +0100, Andy Green wrote:
Somebody in the thread at some point said:
> I've got a Fedora 7 (x86) system that started exhibiting truly bizarre
> behavior about a week ago. Basically, the clock stopped working. If
> I run 'date' it shows the date/time from a few days earlier, and it
Recent kernels have become "tickless", a neat idea to stop regular
wakeups hundreds of times a second and save on power. AIUI to track
time it now refers to a hardware "clocksource" to find out time instead
of counting the "tick" interrupts.
You can find out what hardware clocksources you have on your machine
like this
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
For example I get
hpet hpet acpi_pm jiffies tsc
(hpet twice? maybe due to dualcore?). You can find out the clocksource
you are currently using here
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet is the latest and greatest, but what I would try is to force the
kernel to use something other than it is using at the moment, by
something like this
clocksource=tsc
on the kernel commandline, and see if that makes any odds.
-Andy
But what does the result mean? The result of:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
is: acpi_pm pit jiffies tsc
What does that tell me?
--
=======================================================================
Be wary of strong drink. It can make you shoot at tax collectors and
miss. -- Lazarus Long, "Time Enough for Love"
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
9:19 a.m.
On Sun, 2007-08-26 at 14:48 -0700, Lonni J Friedman wrote:
I've got a Fedora 7 (x86) system that started exhibiting truly
bizarre
behavior about a week ago. Basically, the clock stopped working. If
I run 'date' it shows the date/time from a few days earlier, and it
*never* changes. If I touch a file, it has the date/timestamp from
the time/date in date output. The odd thing is that this behavior
only happens when the system sits relatively idle for a long chunk of
time (at least 24 hours). If i'm actively using it every day, then
its fine. If I reboot, then the problem goes away (and the system has
the correct time after rebooting).
The first time that this happened was last weekend (Aug 18), and I had
to reboot it last Monday (Aug 20) to fix the problem. Its now
happened again. At this moment in time, date claims that its Sat Aug
25, even though its actually Sun Aug 26 right now.
To make matters worse, the system behaves oddly when this problem
occurs. I suspect its because anything that relies on getting an
accurate (or changing) clock is failing. If I attempt to reboot
cleanly, it just never happens. The system acts frozen in time.
I've checked dmesg & messages, and there's nothing there. messages
just stops logging anything around the time that the clock appears to
have frozen.
Anyone ever seen this bizarre behavior, or have any ideas what might
be going on?
If the clock goes screwey when the system is powered up then the BIOS
battery or clock is not the problem. For that to happen it must be the
program maintaining the system clock , but what program is that? It is a
mystery.
--
=======================================================================
The assertion that "all men are created equal" was of no practical use
in effecting our separation from Great Britain and it was placed in the
Declaration not for that, but for future use. -- Abraham Lincoln
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
6083
days inactive
6102
days old
31 comments
12 participants
participants (12)
-
Aaron Konstam -
Andy Green -
Claude Jones -
Development discussions related to Fedora -
Howard Howell -
Karl Larsen -
Lonni J Friedman -
Matthew Saltzman -
Mike -
Mikkel -
SternData -
Tim