the clock stopped in F7 ?!
Mike
azmr at earthlink.net
Mon Aug 27 03:13:32 UTC 2007
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
More information about the users
mailing list