the clock stopped in F7 ?!

[Lonni J Friedman]

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?

The timer in /proc/interrupts was not changing, and neither was the
timestamp in /proc/schedstat.  ugh.