the clock stopped in F7 ?!

[Lonni J Friedman]

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 at 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 at 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 at 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