Skip to content

L
linux
Switch branch/tag
  1. 23 Mar, 2012 3 commits
    • John Stultz's avatar
      time: Avoid scary backtraces when warning of > 11% adj · e919cfd4
      John Stultz authored 
      Folks have been getting a number of warnings about time
adjustments > 11%. The WARN_ON leaves a big useless backtrace
so this patch removes it for a printk_once().

I'm still working to narrow down the cause of the > 11% adjustment.
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      e919cfd4
    • John Stultz's avatar
      alarmtimer: Make sure we initialize the rtctimer · ad30dfa9
      John Stultz authored 
      jonghwan Choi reported seeing warnings with the alarmtimer
code at suspend/resume time, and pointed out that the
rtctimer isn't being properly initialized.

This patch corrects this issue.
Reported-by: default avatarjonghwan Choi <jhbird.choi@gmail.com>
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      ad30dfa9
    • John Stultz's avatar
      ntp: Fix leap-second hrtimer livelock · 6b43ae8a
      John Stultz authored 
      Since commit 7dffa3c6 the ntp
subsystem has used an hrtimer for triggering the leapsecond
adjustment. However, this can cause a potential livelock.

Thomas diagnosed this as the following pattern:
CPU 0                                                    CPU 1
do_adjtimex()
  spin_lock_irq(&ntp_lock);
    process_adjtimex_modes();				 timer_interrupt()
      process_adj_status();                                do_timer()
        ntp_start_leap_timer();                             write_lock(&xtime_lock);
          hrtimer_start();                                  update_wall_time();
             hrtimer_reprogram();                            ntp_tick_length()
               tick_program_event()                            spin_lock(&ntp_lock);
                 clockevents_program_event()
		   ktime_get()
                     seq = req_seqbegin(xtime_lock);

This patch tries to avoid the problem by reverting back to not using
an hrtimer to inject leapseconds, and instead we handle the leapsecond
processing in the second_overflow() function.

The downside to this change is that on systems that support highres
timers, the leap second processing will occur on a HZ tick boundary,
(ie: ~1-10ms, depending on HZ)  after the leap second instead of
possibly sooner (~34us in my tests w/ x86_64 lapic).

This patch applies on top of tip/timers/core.

CC: Sasha Levin <levinsasha928@gmail.com>
CC: Thomas Gleixner <tglx@linutronix.de>
Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
Diagnoised-by: default avatarThomas Gleixner <tglx@linutronix.de>
Tested-by: default avatarSasha Levin <levinsasha928@gmail.com>
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      6b43ae8a
  3. 16 Mar, 2012 8 commits
  5. 15 Mar, 2012 2 commits
  7. 06 Mar, 2012 2 commits
  9. 27 Feb, 2012 1 commit
  11. 22 Feb, 2012 2 commits
    • Ingo Molnar's avatar
      clocksource: scx200_hrt: Fix the build · 10ea9d6f
      Ingo Molnar authored 
      This commit:

  12d6d412: clocksource: scx200_hrt: Convert scx200 to use clocksource_register_hz

Breaks the build on x86-32:

  drivers/clocksource/scx200_hrt.c: In function ‘init_hrt_clocksource’:
  drivers/clocksource/scx200_hrt.c:95:0: error: unterminated argument list invoking macro "pr_info"
  drivers/clocksource/scx200_hrt.c:84:2: error: ‘pr_info’ undeclared (first use in this function)

It could not possibly have been build tested, because it had this mismerge:

	pr_info("enabling scx200 high-res timer (%s MHz +%d ppm)\n",
	printk(KERN_INFO "enabling scx200 high-res timer (%s MHz +%d ppm)\n",
		mhz27 ? "27":"1", ppm);

Cc: Jim Cromie <jim.cromie@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/n/tip-jceb26fns5w7tv8edlivhxpa@git.kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      10ea9d6f
    • Suresh Siddha's avatar
      x86/tsc: Reduce the TSC sync check time for core-siblings · b0e5c779
      Suresh Siddha authored 
      For each logical CPU that is coming online, we spend 20msec for
checking the TSC synchronization. And as this is done
sequentially for each logical CPU boot, this time gets added up
depending on the number of logical CPU's supported by the
platform.

Minimize this by using the socket topology information.

If the target CPU coming online doesn't have any of its
core-siblings online, a timeout of 20msec will be used for the
TSC-warp measurement loop. Otherwise a smaller timeout of 2msec
will be used, as we have some information about this socket
already (and this information grows as we have more and more
logical-siblings in that socket).

Ideally we should be able to skip the TSC sync check on the
other core-siblings, if the first logical CPU in a socket passed
the sync test. But as the TSC is per-logical CPU and can
potentially be modified wrongly by the bios before the OS boot,
TSC sync test for smaller duration should be able to catch such
errors. Also this will catch the condition where all the cores
in the socket doesn't get reset at the same time.

For example, with this modification, time spent in TSC sync
checks on a 4 socket 10-core with HT system gets reduced from
1580msec to 212msec.
Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Jack Steiner <steiner@sgi.com>
Cc: venki@google.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1328581940.29790.20.camel@sbsiddha-desk.sc.intel.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b0e5c779
  13. 15 Feb, 2012 7 commits
  15. 14 Feb, 2012 15 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7