1. 11 7月, 2008 1 次提交
    • H
      nohz: don't stop idle tick if softirqs are pending. · 857f3fd7
      Heiko Carstens 提交于
      In case a cpu goes idle but softirqs are pending only an error message is
      printed to the console. It may take a very long time until the pending
      softirqs will finally be executed. Worst case would be a hanging system.
      
      With this patch the timer tick just continues and the softirqs will be
      executed after the next interrupt. Still a delay but better than a
      hanging system.
      
      Currently we have at least two device drivers on s390 which under certain
      circumstances schedule a tasklet from process context. This is a reason
      why we can end up with pending softirqs when going idle. Fixing these
      drivers seems to be non-trivial.
      However there is no question that the drivers should be fixed.
      This patch shouldn't be considered as a bug fix. It just is intended to
      keep a system running even if device drivers are buggy.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Jan Glauber <jan.glauber@de.ibm.com>
      Cc: Stefan Weinhuber <wein@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      857f3fd7
  2. 30 5月, 2008 1 次提交
  3. 04 5月, 2008 2 次提交
  4. 01 5月, 2008 10 次提交
  5. 29 4月, 2008 1 次提交
  6. 25 4月, 2008 1 次提交
    • I
      softlockup: fix NOHZ wakeup · 126e01bf
      Ingo Molnar 提交于
      David Miller reported:
      
      |--------------->
      the following commit:
      
      | commit 27ec4407
      | Author: Ingo Molnar <mingo@elte.hu>
      | Date:   Thu Feb 28 21:00:21 2008 +0100
      |
      |     sched: make cpu_clock() globally synchronous
      |
      |     Alexey Zaytsev reported (and bisected) that the introduction of
      |     cpu_clock() in printk made the timestamps jump back and forth.
      |
      |     Make cpu_clock() more reliable while still keeping it fast when it's
      |     called frequently.
      |
      |     Signed-off-by: Ingo Molnar <mingo@elte.hu>
      
      causes watchdog triggers when a cpu exits NOHZ state when it has been
      there for >= the soft lockup threshold, for example here are some
      messages from a 128 cpu Niagara2 box:
      
      [  168.106406] BUG: soft lockup - CPU#11 stuck for 128s! [dd:3239]
      [  168.989592] BUG: soft lockup - CPU#21 stuck for 86s! [swapper:0]
      [  168.999587] BUG: soft lockup - CPU#29 stuck for 91s! [make:4511]
      [  168.999615] BUG: soft lockup - CPU#2 stuck for 85s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#37 stuck for 91s! [swapper:0]
      [  169.020514] BUG: soft lockup - CPU#45 stuck for 91s! [sh:4515]
      [  169.020515] BUG: soft lockup - CPU#69 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#77 stuck for 92s! [swapper:0]
      [  169.020515] BUG: soft lockup - CPU#61 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#85 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#101 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#109 stuck for 92s! [swapper:0]
      [  169.112554] BUG: soft lockup - CPU#117 stuck for 92s! [swapper:0]
      [  169.171483] BUG: soft lockup - CPU#40 stuck for 80s! [dd:3239]
      [  169.331483] BUG: soft lockup - CPU#13 stuck for 86s! [swapper:0]
      [  169.351500] BUG: soft lockup - CPU#43 stuck for 101s! [dd:3239]
      [  169.531482] BUG: soft lockup - CPU#9 stuck for 129s! [mkdir:4565]
      [  169.595754] BUG: soft lockup - CPU#20 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#52 stuck for 93s! [swapper:0]
      [  169.626787] BUG: soft lockup - CPU#84 stuck for 92s! [swapper:0]
      [  169.636812] BUG: soft lockup - CPU#116 stuck for 94s! [swapper:0]
      
      It's simple enough to trigger this by doing a 10 minute sleep after a
      fresh bootup then starting a parallel kernel build.
      
      I suspect this might be reintroducing a problem we've had and fixed
      before, see the thread:
      
      http://marc.info/?l=linux-kernel&m=119546414004065&w=2
      <---------------|
      
      touch the softlockup watchdog when exiting NOHZ state - we are
      obviously not locked up.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      126e01bf
  7. 21 4月, 2008 1 次提交
  8. 20 4月, 2008 2 次提交
    • P
      sched: rt-group: synchonised bandwidth period · d0b27fa7
      Peter Zijlstra 提交于
      Various SMP balancing algorithms require that the bandwidth period
      run in sync.
      
      Possible improvements are moving the rt_bandwidth thing into root_domain
      and keeping a span per rt_bandwidth which marks throttled cpus.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d0b27fa7
    • T
      x86: tsc prevent time going backwards · d8bb6f4c
      Thomas Gleixner 提交于
      We already catch most of the TSC problems by sanity checks, but there
      is a subtle bug which has been in the code forever. This can cause
      time jumps in the range of hours.
      
      This was reported in:
           http://lkml.org/lkml/2007/8/23/96
      and
           http://lkml.org/lkml/2008/3/31/23
      
      I was able to reproduce the problem with a gettimeofday loop test on a
      dual core and a quad core machine which both have sychronized
      TSCs. The TSCs seems not to be perfectly in sync though, but the
      kernel is not able to detect the slight delta in the sync check. Still
      there exists an extremly small window where this delta can be observed
      with a real big time jump. So far I was only able to reproduce this
      with the vsyscall gettimeofday implementation, but in theory this
      might be observable with the syscall based version as well.
      
      CPU 0 updates the clock source variables under xtime/vyscall lock and
      CPU1, where the TSC is slighty behind CPU0, is reading the time right
      after the seqlock was unlocked.
      
      The clocksource reference data was updated with the TSC from CPU0 and
      the value which is read from TSC on CPU1 is less than the reference
      data. This results in a huge delta value due to the unsigned
      subtraction of the TSC value and the reference value. This algorithm
      can not be changed due to the support of wrapping clock sources like
      pm timer.
      
      The huge delta is converted to nanoseconds and added to xtime, which
      is then observable by the caller. The next gettimeofday call on CPU1
      will show the correct time again as now the TSC has advanced above the
      reference value.
      
      To prevent this TSC specific wreckage we need to compare the TSC value
      against the reference value and return the latter when it is larger
      than the actual TSC value.
      
      I pondered to mark the TSC unstable when the readout is smaller than
      the reference value, but this would render an otherwise good and fast
      clocksource unusable without a real good reason.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8bb6f4c
  9. 18 4月, 2008 1 次提交
  10. 17 4月, 2008 3 次提交
    • A
      clocksource: make clocksource watchdog cycle through online CPUs · 6993fc5b
      Andi Kleen 提交于
      This way it checks if the clocks are synchronized between CPUs too.
      This might be able to detect slowly drifting TSCs which only
      go wrong over longer time.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6993fc5b
    • K
      clockevents: optimise tick_nohz_stop_sched_tick() a bit · 903b8a8d
      Karsten Wiese 提交于
      Call
      	ts = &per_cpu(tick_cpu_sched, cpu);
      and
      	cpu = smp_processor_id();
      once instead of twice.
      
      No functional change done, as changed code runs with local irq off.
      Reduces source lines and text size (20bytes on x86_64).
      
      [ akpm@linux-foundation.org: Build fix ]
      Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      903b8a8d
    • R
      [S390] genirq/clockevents: move irq affinity prototypes/inlines to interrupt.h · d7b90689
      Russell King 提交于
      > Generic code is not supposed to include irq.h. Replace this include
      > by linux/hardirq.h instead and add/replace an include of linux/irq.h
      > in asm header files where necessary.
      > This change should only matter for architectures that make use of
      > GENERIC_CLOCKEVENTS.
      > Architectures in question are mips, x86, arm, sh, powerpc, uml and sparc64.
      >
      > I did some cross compile tests for mips, x86_64, arm, powerpc and sparc64.
      > This patch fixes also build breakages caused by the include replacement in
      > tick-common.h.
      
      I generally dislike adding optional linux/* includes in asm/* includes -
      I'm nervous about this causing include loops.
      
      However, there's a separate point to be discussed here.
      
      That is, what interfaces are expected of every architecture in the kernel.
      If generic code wants to be able to set the affinity of interrupts, then
      that needs to become part of the interfaces listed in linux/interrupt.h
      rather than linux/irq.h.
      
      So what I suggest is this approach instead (against Linus' tree of a
      couple of days ago) - we move irq_set_affinity() and irq_can_set_affinity()
      to linux/interrupt.h, change the linux/irq.h includes to linux/interrupt.h
      and include asm/irq_regs.h where needed (asm/irq_regs.h is supposed to be
      rarely used include since not much touches the stacked parent context
      registers.)
      
      Build tested on ARM PXA family kernels and ARM's Realview platform
      kernels which both use genirq.
      
      [ tglx@linutronix.de: add GENERIC_HARDIRQ dependencies ]
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      d7b90689
  11. 26 3月, 2008 1 次提交
  12. 25 3月, 2008 1 次提交
  13. 20 3月, 2008 1 次提交
  14. 09 3月, 2008 3 次提交
  15. 01 3月, 2008 1 次提交
  16. 18 2月, 2008 1 次提交
  17. 10 2月, 2008 1 次提交
  18. 09 2月, 2008 4 次提交
  19. 07 2月, 2008 1 次提交
    • M
      time: fix sysfs_show_{available,current}_clocksources() buffer overflow problem · 5e2cb101
      Miao Xie 提交于
      I found that there is a buffer overflow problem in the following code.
      
      Version:	2.6.24-rc2,
      File:		kernel/time/clocksource.c:417-432
      --------------------------------------------------------------------
      static ssize_t
      sysfs_show_available_clocksources(struct sys_device *dev, char *buf)
      {
      	struct clocksource *src;
      	char *curr = buf;
      
      	spin_lock_irq(&clocksource_lock);
      	list_for_each_entry(src, &clocksource_list, list) {
      		curr += sprintf(curr, "%s ", src->name);
      	}
      	spin_unlock_irq(&clocksource_lock);
      
      	curr += sprintf(curr, "\n");
      
      	return curr - buf;
      }
      -----------------------------------------------------------------------
      
      sysfs_show_current_clocksources() also has the same problem though in practice
      the size of current clocksource's name won't exceed PAGE_SIZE.
      
      I fix the bug by using snprintf according to the specification of the kernel
      (Version:2.6.24-rc2,File:Documentation/filesystems/sysfs.txt)
      
      Fix sysfs_show_available_clocksources() and sysfs_show_current_clocksources()
      buffer overflow problem with snprintf().
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: john stultz <johnstul@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5e2cb101
  20. 02 2月, 2008 2 次提交
  21. 30 1月, 2008 1 次提交