Linus,

Please pull the latest timers-fixes-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers-fixes-for-linus

This is a rather large update that late in the rc cycle, but it's all
really important bugfixes around the timers/timekeeping code.

The C1E idle support (added in .27) made some long standing bugs in
the timers code more prominent and I spent almost two weeks now going
through the code with a fine comb, creating debug patches and tracking
down the last (and for me most embarrassing) bug in the hpet code
along with a new workaround for hardware bugs^Wfeatures in ATI HPETs
which need a readback of the compare value _before_ reading the count
register to verify that we did not miss the event.

The patches are confirmed by various testers and close a couple of
entries in the regression list [BZ #11145 #11191 #11279] and some
other related bug reports.

Also passed in -tip testing on a broad range of x86 boxes.

I thought about disabling C1E for .27, but the bugs are real and
affect non C1E systems as well. So fixing them is better than hiding
them and hope they wont trigger.

The timekeeping patches vs. acpi_pm and ntp were collected and tested
by Andrew and have been in -mm for some time.

Thanks,

	tglx

------------------>
Dominik Brodowski (2):
      clocksource, acpi_pm.c: use proper read function also in errata mode
      clocksource, acpi_pm.c: check for monotonicity

Maciej W. Rozycki (1):
      ntp: fix calculation of the next jiffie to trigger RTC sync

Thomas Gleixner (8):
      clockevents: prevent endless loop in periodic broadcast handler
      clockevents: enforce reprogram in oneshot setup
      clockevents: prevent multiple init/shutdown
      clockevents: prevent endless loop lockup
      HPET: make minimum reprogramming delta useful
      clockevents: broadcast fixup possible waiters
      x86: HPET fix moronic 32/64bit thinko
      x86: HPET: read back compare register before ...
[ message continues ]

Hi,

I made some comments about this patch which were never answered:

    http://lkml.org/lkml/2008/8/23/28

Not sure whether this was because they were irrelevant or overlooked.
300*10000 microseconds seems like a long time to me.  Is this the
If the inner loop runs out once, you alreay know that you will later
abort here.  Maybe move the check directly after the inner loop to
avoid the additional delay (10*10000*300 microseconds = 30 seconds) in

I hope this helps,
Jochen
-- 
http://seehuhn.de/
--

[ message continues ]