Re: the clock stopped in F7 ?!

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

 



On 8/27/07, Mike <azmr@xxxxxxxxxxxxx> wrote:
> On Mon, 27 Aug 2007, Lonni J Friedman wrote:
>
> >
> > The timer in /proc/interrupts was not changing, and neither was the
> > timestamp in /proc/schedstat.  ugh.
> >
>
> Sorry for the confusion.  Andy Green's posts clear this up and hopefully
> this will clarify somewhat too.
>
> For aeon's, well maybe centuries, ok really just decades the majority of
> OS'es that run on PC's used IRQ0 to update the real time clock.  What this
> means is that 100 times a second (100 Hz) the kernel (in the case of
> linux) is interrupted and the real time clock is updated among other
> things then the kernel goes about it's business.  To get better resolution
> the 100 Hz parameter is changeable at compile time to 100, 250 or 1000 (I
> believe).  I think it defaulted to 1000Hz recently.  In any case as Andy
> Green pointed out modern kernels have gone "tickless".  This is a very
> good thing for laptops and saving power etc.
>
> >From what I have read HPET or High Precision Event Timer is what is used
> now (in the 2.6.21 or so kernel timeframe and beyond).  HPET is a device
> that is part of the chipsets on modern motherboards.  From what I've been
> told the HPET code is broken in some kernel versions (I mean hey it's
> brand new code, sure could be buggy).
>
> So to the original poster (Lonni J Friedman?) I'd suggest (as Andy
> mentioned) check to see what your clocksource is:
>
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> If it says 'hpet' reboot your machine and pass 'hpet=disable' to the
> kernal via grub.  I don't have a machine that I can reboot at the moment,
> but IIRC at the grub prompt you press 'e' to edit the command before
> booting.  From there I forget but google should help find the syntax.  Or
> perhaps it's even self explanatory.
>
> In any case this should force your machine to keep time the old fashioned
> way which unless you're on a laptop should be just fine.  And if this
> works you can edit grub.conf (I believe) and 'hpet=disable' to make this
> permanent.

My system doesn't have HPET.  Also, to clarify, the problem only
happens after some unknown period of uptime.  The system had been up
for like 100 days prior to the first occurance, and was up for just 3
days after the 2nd occurance.  Its not always present.  So clearly
something is very broken somewhere, and isn't going to be fixed just
by disabling hpet at boot.  My best guess is flaky hardware.  I'll be
running memtest86+ tonight.  If that checks out, then I can only
assume that the CPU (Athlon64X2) is dying.

-- 
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