1. 15 7月, 2006 1 次提交
  2. 11 7月, 2006 1 次提交
  3. 04 7月, 2006 3 次提交
  4. 28 6月, 2006 2 次提交
  5. 27 6月, 2006 6 次提交
  6. 26 6月, 2006 1 次提交
  7. 23 6月, 2006 2 次提交
    • P
      [PATCH] When CONFIG_BASE_SMALL=1, cascade() may enter an infinite loop · 3439dd86
      Porpoise 提交于
      When CONFIG_BASE_SAMLL=1, cascade() in may enter the infinite loop.
      Because of CONFIG_BASE_SMALL=1(TVR_BITS=6 and TVN_BITS=4), the list
      base->tv5 may cascade into base->tv5.  So, the kernel enters the infinite
      loop in the function cascade().
      
      I created a test module to verify this bug, and a patch to fix it.
      
      #include <linux/kernel.h>
      #include <linux/module.h>
      #include <linux/init.h>
      #include <linux/timer.h>
      #if 0
      #include <linux/kdb.h>
      #else
      #define kdb_printf printk
      #endif
      
      #define TVN_BITS (CONFIG_BASE_SMALL ? 4 : 6)
      #define TVR_BITS (CONFIG_BASE_SMALL ? 6 : 8)
      #define TVN_SIZE (1 << TVN_BITS)
      #define TVR_SIZE (1 << TVR_BITS)
      #define TVN_MASK (TVN_SIZE - 1)
      #define TVR_MASK (TVR_SIZE - 1)
      
      #define TV_SIZE(N)  (N*TVN_BITS  + TVR_BITS)
      
      struct timer_list timer0;
      struct timer_list dummy_timer1;
      struct timer_list dummy_timer2;
      
      void dummy_timer_fun(unsigned long data) {
      }
      unsigned long j=0;
      void check_timer_base(unsigned long data)
      {
              kdb_printf("check_timer_base %08x\n",jiffies);
              mod_timer(&timer0,(jiffies & (~0xFFF)) + 0x1FFF);
      }
      
      int init_module(void)
      {
              init_timer(&timer0);
              timer0.data = (unsigned long)0;
              timer0.function = check_timer_base;
              mod_timer(&timer0,jiffies+1);
      
              init_timer(&dummy_timer1);
              dummy_timer1.data = (unsigned long)0;
              dummy_timer1.function = dummy_timer_fun;
      
              init_timer(&dummy_timer2);
              dummy_timer2.data = (unsigned long)0;
              dummy_timer2.function = dummy_timer_fun;
      
              j=jiffies;
              j&=(~((1<<TV_SIZE(3))-1));
              j+=(1<<TV_SIZE(3));
              j+=(1<<TV_SIZE(4));
      
              kdb_printf("mod_timer %08x\n",j);
      
              mod_timer(&dummy_timer1, j );
              mod_timer(&dummy_timer2, j );
      
              return 0;
      }
      
      void cleanup_module()
      {
              del_timer_sync(&timer0);
              del_timer_sync(&dummy_timer1);
              del_timer_sync(&dummy_timer2);
      }
      
      (Cleanups from Oleg)
      
      [oleg@tv-sign.ru: use list_replace_init()]
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Matt Mackall <mpm@selenic.com>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3439dd86
    • O
      [PATCH] list: use list_replace_init() instead of list_splice_init() · 626ab0e6
      Oleg Nesterov 提交于
      list_splice_init(list, head) does unneeded job if it is known that
      list_empty(head) == 1.  We can use list_replace_init() instead.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      626ab0e6
  8. 22 5月, 2006 1 次提交
    • Z
      [PATCH] Fix a NO_IDLE_HZ timer bug · 0662b713
      Zachary Amsden 提交于
      Under certain timing conditions, a race during boot occurs where timer
      ticks are being processed on remote CPUs.  The remote timer ticks can
      increment jiffies, and if this happens during a window when a timeout is
      very close to expiring but a local tick has not yet been delivered, you can
      end up with
      
      1) No softirq pending
      2) A local timer wheel which is not synced to jiffies
      3) No high resolution timer active
      4) A local timer which is supposed to fire before the current jiffies value.
      
      In this circumstance, the comparison in next_timer_interrupt overflows,
      because the base of the comparison for high resolution timers is jiffies,
      but for the softirq timer wheel, it is relative the the current base of the
      wheel (jiffies_base).
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0662b713
  9. 26 4月, 2006 2 次提交
  10. 11 4月, 2006 1 次提交
    • A
      [PATCH] timer initialisation fix · ba6edfcd
      Andrew Morton 提交于
      We need the boot CPU's tvec_bases[] entry to be initialised super-early in
      boot, for early_serial_setup().  That runs within setup_arch(), before even
      per-cpu areas are initialised.
      
      The patch changes tvec_bases to use compile-time initialisation, and adds a
      separate array `tvec_base_done' to keep track of which CPU has had its
      tvec_bases[] entry initialised (because we can no longer use the zeroness of
      that tvec_bases[] entry to determine whether it has been initialised).
      
      Thanks to Eugene Surovegin <ebs@ebshome.net> for diagnosing this.
      
      Cc: Eugene Surovegin <ebs@ebshome.net>
      Cc: Jan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ba6edfcd
  11. 10 4月, 2006 1 次提交
    • J
      [PATCH] x86_64: Fix drift with HPET timer enabled · b20367a6
      Jordan Hargrave 提交于
      If the HPET timer is enabled, the clock can drift by ~3 seconds a day.
      This is due to the HPET timer not being initialized with the correct
      setting (still using PIT count).
      
      If HZ changes, this drift can become even more pronounced.
      
      HPET patch initializes tick_nsec with correct tick_nsec settings for
      HPET timer.
      
      Vojtech comments:
      
        "It's not entirely correct (it assumes the HPET ticks totally
         exactly), but it's significantly better than assuming the PIT error
         there."
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b20367a6
  12. 02 4月, 2006 1 次提交
  13. 01 4月, 2006 3 次提交
  14. 26 3月, 2006 2 次提交
    • R
      [PATCH] remove pps support · 5ddcfa87
      Roman Zippel 提交于
      This removes the support for pps.  It's completely unused within the kernel
      and is basically in the way for further cleanups.  It should be easier to
      readd proper support for it after the rest has been converted to NTP4
      (where the pps mechanisms are quite different from NTP3 anyway).
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5ddcfa87
    • T
      [PATCH] sys_alarm() unsigned signed conversion fixup · c08b8a49
      Thomas Gleixner 提交于
      alarm() calls the kernel with an unsigend int timeout in seconds.  The
      value is stored in the tv_sec field of a struct timeval to setup the
      itimer.  The tv_sec field of struct timeval is of type long, which causes
      the tv_sec value to be negative on 32 bit machines if seconds > INT_MAX.
      
      Before the hrtimer merge (pre 2.6.16) such a negative value was converted
      to the maximum jiffies timeout by the timeval_to_jiffies conversion.  It's
      not clear whether this was intended or just happened to be done by the
      timeval_to_jiffies code.
      
      hrtimers expect a timeval in canonical form and treat a negative timeout as
      already expired.  This breaks the legitimate usage of alarm() with a
      timeout value > INT_MAX seconds.
      
      For 32 bit machines it is therefor necessary to limit the internal seconds
      value to avoid API breakage.  Instead of doing this in all implementations
      of sys_alarm the duplicated sys_alarm code is moved into a common function
      in itimer.c
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c08b8a49
  15. 24 3月, 2006 2 次提交
  16. 17 3月, 2006 1 次提交
  17. 07 3月, 2006 2 次提交
  18. 03 3月, 2006 1 次提交
  19. 18 2月, 2006 1 次提交
    • P
      [PATCH] Provide an interface for getting the current tick length · 726c14bf
      Paul Mackerras 提交于
      This provides an interface for arch code to find out how many
      nanoseconds are going to be added on to xtime by the next call to
      do_timer.  The value returned is a fixed-point number in 52.12 format
      in nanoseconds.  The reason for this format is that it gives the
      full precision that the timekeeping code is using internally.
      
      The motivation for this is to fix a problem that has arisen on 32-bit
      powerpc in that the value returned by do_gettimeofday drifts apart
      from xtime if NTP is being used.  PowerPC is now using a lockless
      do_gettimeofday based on reading the timebase register and performing
      some simple arithmetic.  (This method of getting the time is also
      exported to userspace via the VDSO.)  However, the factor and offset
      it uses were calculated based on the nominal tick length and weren't
      being adjusted when NTP varied the tick length.
      
      Note that 64-bit powerpc has had the lockless do_gettimeofday for a
      long time now.  It also had an extremely hairy routine that got called
      from the 32-bit compat routine for adjtimex, which adjusted the
      factor and offset according to what it thought the timekeeping code
      was going to do.  Not only was this only called if a 32-bit task did
      adjtimex (i.e. not if a 64-bit task did adjtimex), it was also
      duplicating computations from kernel/timer.c and it wasn't clear that
      it was (still) correct.
      
      The simple solution is to ask the timekeeping code how long the
      current jiffy will be on each timer interrupt, after calling
      do_timer.  If this jiffy will be a different length from the last one,
      we then need to compute new values for the factor and offset used in
      the lockless do_gettimeofday.  In this way we can keep xtime and
      do_gettimeofday in sync, even when NTP is varying the tick length.
      
      Note that when adjtimex varies the tick length, it almost always
      introduces the variation from the next tick on.  The only case I could
      see where adjtimex would vary the length of the current tick is when
      an old-style adjtime adjustment is being cancelled.  (It's not clear
      to me why the adjustment has to be cancelled immediately rather than
      from the next tick on.)  Thus I don't see any real need for a hook in
      adjtimex; the rare case of an old-style adjustment being cancelled can
      be fixed up at the next tick.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: Njohn stultz <johnstul@us.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      726c14bf
  20. 08 2月, 2006 1 次提交
  21. 11 1月, 2006 2 次提交
  22. 09 1月, 2006 1 次提交
  23. 31 10月, 2005 2 次提交