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
