Re: the clock stopped in F7 ?!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux