the clock stopped in F7 ?!

[Mike]

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