On 8/26/07, Mike <azmr@xxxxxxxxxxxxx> 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.
