1. 06 Sep, 2008 4 commits
    • Maciej W. Rozycki's avatar
      ntp: fix calculation of the next jiffie to trigger RTC sync · 4ff4b9e1
      Maciej W. Rozycki authored
      We have a bug in the calculation of the next jiffie to trigger the RTC
      synchronisation.  The aim here is to run sync_cmos_clock() as close as
      possible to the middle of a second.  Which means we want this function to
      be called less than or equal to half a jiffie away from when now.tv_nsec
      equals 5e8 (500000000).
      
      If this is not the case for a given call to the function, for this purpose
      instead of updating the RTC we calculate the offset in nanoseconds to the
      next point in time where now.tv_nsec will be equal 5e8.  The calculated
      offset is then converted to jiffies as these are the unit used by the
      timer.
      
      Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode,
      where the resulting value is rounded up.  As a result the range of
      now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC
      rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2.
      
      As a result if for example sync_cmos_clock() happens to be called at the
      time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 +
      TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the
      same range of now.tv_nsec again.  Similarly for cases offsetted by an
      integer multiple of TICK_NSEC.
      
      This change addresses the problem by subtracting TICK_NSEC / 2 from the
      nanosecond offset to the next point in time where now.tv_nsec will be
      equal 5e8, effectively shifting the following rounding in
      timespec_to_jiffies() so that it produces a rounded-to-nearest result.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4ff4b9e1
    • Thomas Gleixner's avatar
      x86: HPET: read back compare register before reading counter · 72d43d9b
      Thomas Gleixner authored
      After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
      with small deltas. There seems to be a delay between writing the compare
      register and the transffer to the internal register which triggers the
      interrupt. Reading back the value makes sure, that it hit the internal
      match register befor we compare against the counter value.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      72d43d9b
    • Thomas Gleixner's avatar
      x86: HPET fix moronic 32/64bit thinko · f7676254
      Thomas Gleixner authored
      We use the HPET only in 32bit mode because:
      1) some HPETs are 32bit only
      2) on i386 there is no way to read/write the HPET atomic 64bit wide
      
      The HPET code unification done by the "moron of the year" did
      not take into account that unsigned long is different on 32 and
      64 bit.
      
      This thinko results in a possible endless loop in the clockevents
      code, when the return comparison fails due to the 64bit/332bit
      unawareness. 
      
      unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit.
      but the final compare will fail and return -ETIME causing endless
      loops.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f7676254
    • Thomas Gleixner's avatar
      clockevents: broadcast fixup possible waiters · 7300711e
      Thomas Gleixner authored
      Until the C1E patches arrived there where no users of periodic broadcast
      before switching to oneshot mode. Now we need to trigger a possible
      waiter for a periodic broadcast when switching to oneshot mode.
      Otherwise we can starve them for ever.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      7300711e
  2. 05 Sep, 2008 6 commits
    • Thomas Gleixner's avatar
      HPET: make minimum reprogramming delta useful · 7cfb0435
      Thomas Gleixner authored
      The minimum reprogramming delta was hardcoded in HPET ticks,
      which is stupid as it does not work with faster running HPETs.
      The C1E idle patches made this prominent on AMD/RS690 chipsets,
      where the HPET runs with 25MHz. Set it to 5us which seems to be
      a reasonable value and fixes the problems on the bug reporters
      machines. We have a further sanity check now in the clock events,
      which increases the delta when it is not sufficient.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarLuiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
      Tested-by: default avatarDmitry Nezhevenko <dion@inhex.net>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7cfb0435
    • Thomas Gleixner's avatar
      clockevents: prevent endless loop lockup · 1fb9b7d2
      Thomas Gleixner authored
      The C1E/HPET bug reports on AMDX2/RS690 systems where tracked down to a
      too small value of the HPET minumum delta for programming an event.
      
      The clockevents code needs to enforce an interrupt event on the clock event
      device in some cases. The enforcement code was stupid and naive, as it just
      added the minimum delta to the current time and tried to reprogram the device.
      When the minimum delta is too small, then this loops forever.
      
      Add a sanity check. Allow reprogramming to fail 3 times, then print a warning
      and double the minimum delta value to make sure, that this does not happen again.
      Use the same function for both tick-oneshot and tick-broadcast code.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1fb9b7d2
    • Thomas Gleixner's avatar
      clockevents: prevent multiple init/shutdown · 9c17bcda
      Thomas Gleixner authored
      While chasing the C1E/HPET bugreports I went through the clock events
      code inch by inch and found that the broadcast device can be initialized
      and shutdown multiple times. Multiple shutdowns are not critical, but
      useless waste of time. Multiple initializations are simply broken. Another
      CPU might have the device in use already after the first initialization and
      the second init could just render it unusable again.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9c17bcda
    • Thomas Gleixner's avatar
      clockevents: enforce reprogram in oneshot setup · 7205656a
      Thomas Gleixner authored
      In tick_oneshot_setup we program the device to the given next_event,
      but we do not check the return value. We need to make sure that the
      device is programmed enforced so the interrupt handler engine starts
      working. Split out the reprogramming function from tick_program_event()
      and call it with the device, which was handed in to tick_setup_oneshot().
      Set the force argument, so the devices is firing an interrupt.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7205656a
    • Thomas Gleixner's avatar
      clockevents: prevent endless loop in periodic broadcast handler · d4496b39
      Thomas Gleixner authored
      The reprogramming of the periodic broadcast handler was broken,
      when the first programming returned -ETIME. The clockevents code
      stores the new expiry value in the clock events device next_event field
      only when the programming time has not been elapsed yet. The loop in
      question calculates the new expiry value from the next_event value
      and therefor never increases.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d4496b39
    • Venkatesh Pallipadi's avatar
      clockevents: prevent clockevent event_handler ending up handler_noop · 7c1e7689
      Venkatesh Pallipadi authored
      There is a ordering related problem with clockevents code, due to which
      clockevents_register_device() called after tickless/highres switch
      will not work. The new clockevent ends up with clockevents_handle_noop as
      event handler, resulting in no timer activity.
      
      The problematic path seems to be
      
      * old device already has hrtimer_interrupt as the event_handler
      * new clockevent device registers with a higher rating
      * tick_check_new_device() is called
        * clockevents_exchange_device() gets called
          * old->event_handler is set to clockevents_handle_noop
        * tick_setup_device() is called for the new device
          * which sets new->event_handler using the old->event_handler which is noop.
      
      Change the ordering so that new device inherits the proper handler.
      
      This does not have any issue in normal case as most likely all the clockevent
      devices are setup before the highres switch. But, can potentially be affecting
      some corner case where HPET force detect happens after the highres switch.
      This was a problem with HPET in MSI mode code that we have been experimenting
      with.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7c1e7689
  3. 04 Sep, 2008 2 commits
  4. 03 Sep, 2008 28 commits