1. 14 Oct, 2009 1 commit
  2. 12 Oct, 2009 1 commit
  3. 11 Oct, 2009 2 commits
  4. 08 Oct, 2009 1 commit
    • Arjan van de Ven's avatar
      x86, timers: Check for pending timers after (device) interrupts · 9bcbdd9c
      Arjan van de Ven authored
      Now that range timers and deferred timers are common, I found a
      problem with these using the "perf timechart" tool. Frans Pop also
      reported high scheduler latencies via LatencyTop, when using
      It turns out that on x86, these two 'opportunistic' timers only get
      checked when another "real" timer happens. These opportunistic
      timers have the objective to save power by hitchhiking on other
      wakeups, as to avoid CPU wakeups by themselves as much as possible.
      The change in this patch runs this check not only at timer
      interrupts, but at all (device) interrupts. The effect is that:
       1) the deferred timers/range timers get delayed less
       2) the range timers cause less wakeups by themselves because
          the percentage of hitchhiking on existing wakeup events goes up.
      I've verified the working of the patch using "perf timechart", the
      original exposed bug is gone with this patch. Frans also reported
      success - the latencies are now down in the expected ~10 msec
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Tested-by: default avatarFrans Pop <elendil@planet.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mike Galbraith <efault@gmx.de>
      LKML-Reference: <20091008064041.67219b13@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  5. 04 Oct, 2009 8 commits
  6. 03 Oct, 2009 1 commit
  7. 02 Oct, 2009 2 commits
    • Arjan van de Ven's avatar
      x86: Simplify bound checks in the MTRR code · 11879ba5
      Arjan van de Ven authored
      The current bound checks for copy_from_user in the MTRR driver are
      not as obvious as they could be, and gcc agrees with that.
      This patch simplifies the boundary checks to the point that gcc can
      now prove to itself that the copy_from_user() is never going past
      its bounds.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090926205150.30797709@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Ingo Molnar's avatar
      x86: EDAC: MCE: Fix MCE decoding callback logic · f436f8bb
      Ingo Molnar authored
      Make decoding of MCEs happen only on AMD hardware by registering a
      non-default callback only on CPU families which support it.
      While looking at the interaction of decode_mce() with the other MCE
      code i also noticed a few other things and made the following
       - Fixed the mce_decode() weak alias - a weak alias is really not
         good here, it should be a proper callback. A weak alias will be
         overriden if a piece of code is built into the kernel - not
         good, obviously.
       - The patch initializes the callback on AMD family 10h and 11h.
       - Added the more correct fallback printk of:
      	No support for human readable MCE decoding on this CPU type.
      	Transcribe the message and run it through 'mcelog --ascii' to decode.
         On CPUs that dont have a decoder.
       - Made the surrounding code more readable.
      Note that the callback allows us to have a default fallback -
      without having to check the CPU versions during the printout
      itself. When an EDAC module registers itself, it can install the
      decode-print function.
      (there's no unregister needed as this is core code.)
      version -v2 by Borislav Petkov:
       - add K8 to the set of supported CPUs
       - always build in edac_mce_amd since we use an early_initcall now
       - fix checkpatch warnings
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      LKML-Reference: <20091001141432.GA11410@aftab>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  8. 01 Oct, 2009 8 commits
  9. 30 Sep, 2009 2 commits
  10. 27 Sep, 2009 3 commits
  11. 24 Sep, 2009 10 commits
  12. 23 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      x86: mce: Use safer ways to access MCE registers · 11868a2d
      Ingo Molnar authored
      Use rdmsrl_safe() when accessing MCE registers. While in
      theory we always 'know' which ones are safe to access from
      the capability bits, there's a lot of hardware variations
      and reality might differ from theory, as it did in this case:
      [    0.010016] mce: CPU supports 5 MCE banks
      [    0.011029] general protection fault: 0000 [#1]
      [    0.011998] last sysfs file:
      [    0.011998] Modules linked in:
      [    0.011998]
      [    0.011998] Pid: 0, comm: swapper Not tainted (2.6.31_router #1
      ) HP Vectra
      [    0.011998] EIP: 0060:[<c100d9b9>] EFLAGS: 00010246 CPU: 0
      [    0.011998] EIP is at mce_rdmsrl+0x19/0x60
      [    0.011998] EAX: 00000000 EBX: 00000001 ECX: 00000407 EDX: 08000000
      [    0.011998] ESI: 00000000 EDI: 8c000000 EBP: 00000405 ESP: c17d5eac
      So WARN_ONCE() instead of crashing the box.
      ( also fix a number of stylistic inconsistencies in the code. )
      Note, we might still crash in wrmsrl() if we get that far, but
      we shouldnt if the registers are truly inaccessible.
      Reported-by: default avatarGNUtoo <GNUtoo@no-log.org>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <bug-14204-5438@http.bugzilla.kernel.org/>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>