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@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? > > -- Mike
