1. 23 9月, 2009 1 次提交
    • H
      x86: mce, inject: Use real inject-msg in raise_local · 14c0abf1
      Huang Ying 提交于
      Current raise_local() uses a struct mce that comes from mce_write()
      as a parameter instead of the real inject-msg, so when we set
      mce.finished = 0 to clear injected MCE, the real inject stays
      valid.
      
      This will cause the remaining inject-msg affect the next injection,
      which is not desired.
      
      To fix this, real inject-msg is used in raise_local instead of the
      one on the stack.
      
      This patch is based on the diagnosis and the fixes by Dean Nelson.
      Reported-by: NDean Nelson <dnelson@redhat.com>
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <1253601357.15717.757.camel@yhuang-dev.sh.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      14c0abf1
  2. 22 9月, 2009 4 次提交
    • I
      x86: mce: Fix thermal throttling message storm · b417c9fd
      Ingo Molnar 提交于
      If a system switches back and forth between hot and cold mode,
      the MCE code will print a stream of critical kernel messages.
      
      Extend the throttling code to properly notice this, by
      only printing the first hot + cold transition and omitting
      the rest up to CHECK_INTERVAL (5 minutes).
      
      This way we'll only get a single incident of:
      
       [  102.356584] CPU0: Temperature above threshold, cpu clock throttled (total events = 1)
       [  102.357000] Disabling lock debugging due to kernel taint
       [  102.369223] CPU0: Temperature/speed normal
      
      Every 5 minutes. The 'total events' count tells the number of cold/hot
      transitions detected, should overheating occur after 5 minutes again:
      
      [  402.357580] CPU0: Temperature above threshold, cpu clock throttled (total events = 24891)
      [  402.358001] CPU0: Temperature/speed normal
      [  450.704142] Machine check events logged
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b417c9fd
    • I
      x86: mce: Clean up thermal throttling state tracking code · 39676840
      Ingo Molnar 提交于
      Instead of a mess of three separate percpu variables, consolidate
      the state into a single structure.
      
      Also clean up therm_throt_process(), use cleaner and more
      understandable variable names and a clearer logic.
      
      This, without changing the logic, makes the code more
      streamlined, more readable and smaller as well:
      
         text	   data	    bss	    dec	    hex	filename
         1487	    169	      4	   1660	    67c	therm_throt.o.before
         1432	    176	      4	   1612	    64c	therm_throt.o.after
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39676840
    • J
      x86: split NX setup into separate file to limit unstack-protected code · c44c9ec0
      Jeremy Fitzhardinge 提交于
      Move the NX setup into a separate file so that it can be compiled
      without stack-protection while leaving the rest of the mm/init code
      protected.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      c44c9ec0
    • J
      xen: check EFER for NX before setting up GDT mapping · b75fe4e5
      Jeremy Fitzhardinge 提交于
      x86-64 assumes NX is available by default, so we need to
      explicitly check for it before using NX.  Some first-generation
      Intel x86-64 processors didn't support NX, and even recent systems
      allow it to be disabled in BIOS.
      
      [ Impact: prevent Xen crash on NX-less 64-bit machines ]
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stable Kernel <stable@kernel.org>
      b75fe4e5
  3. 21 9月, 2009 10 次提交
  4. 20 9月, 2009 7 次提交
  5. 19 9月, 2009 3 次提交
  6. 18 9月, 2009 6 次提交
    • J
      x86: SGI UV: Map MMIO-High memory range · daf7b9c9
      Jack Steiner 提交于
      UV depends on the MMRHI space being identity mapped. The patch:
      
      	x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
      
      changed this to make efi regions at a different address using
      ioremap. Add the identity mapping to uv_system_init.
      
      ( Note this code was previously present but was deleted when BIOS
        added the ranges to the EFI map - previous efi code identify
        mapped the ranges. )
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090909154339.GA7946@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      daf7b9c9
    • J
      x86: SGI UV: Add volatile semantics to macros that access chipset registers · 8dc579e8
      Jack Steiner 提交于
      Add volatile-semantics to the SGI UV read/write macros that are
      used to access chipset memory mapped registers. No direct
      references to volatile are made. Instead the readq/writeq macros
      are used.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: linux-mm@kvack.org
      Cc: dwalker@fifo99.com
      Cc: cfriesen@nortel.com
      LKML-Reference: <20090910143149.GA14273@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8dc579e8
    • J
      x86: SGI UV: Fix IPI macros · d2374aec
      Jack Steiner 提交于
      The UV BIOS has changed the way interrupt remapping is being done.
      This affects the id used for sending IPIs. The upper id bits no
      longer need to be masked off.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090909154104.GA25083@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d2374aec
    • D
      x86: apic: Convert BUG() to BUG_ON() · c2777f98
      Daniel Walker 提交于
      This was done using Coccinelle's BUG_ON semantic patch.
      Signed-off-by: NDaniel Walker <dwalker@fifo99.com>
      Cc: Julia Lawall <julia@diku.dk>
      LKML-Reference: <1252777220-30796-1-git-send-email-dwalker@fifo99.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c2777f98
    • A
      x86: Remove final bits of CONFIG_X86_OLD_MCE · bc3eb707
      Andi Kleen 提交于
      Caught by Linus.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      [ fixed up context conflict manually. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bc3eb707
    • S
      x86, pat: don't use rb-tree based lookup in reserve_memtype() · dcb73bf4
      Suresh Siddha 提交于
      Recent enhancement of rb-tree based lookup exposed a  bug with the lookup
      mechanism in the reserve_memtype() which ensures that there are no conflicting
      memtype requests for the memory range.
      
      memtype_rb_search() returns an entry which has a start address <= new start
      address. And from here we traverse the linear linked list to check if there
      any conflicts with the existing mappings. As the rbtree is based on the
      start address of the memory range, it is quite possible that we have several
      overlapped mappings whose start address is much less than new requested start
      but the end is >= new requested end. This results in conflicting memtype
      mappings.
      
      Same bug exists with the old code which uses cached_entry from where
      we traverse the linear linked list. But the new rb-tree code exposes this
      bug fairly easily.
      
      For now, don't use the memtype_rb_search() and always start the search from
      the head of linear linked list in reserve_memtype(). Linear linked list
      for most of the systems grow's to few 10's of entries(as we track memory type
      of RAM pages using struct page). So we should be ok for now.
      
      We still retain the rbtree and use it to speed up free_memtype() which
      doesn't have the same bug(as we know what exactly we are searching for
      in free_memtype).
      
      Also use list_for_each_entry_from() in free_memtype() so that we start
      the search from rb-tree lookup result.
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      LKML-Reference: <1253136483.4119.12.camel@sbs-t61.sc.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      dcb73bf4
  7. 16 9月, 2009 6 次提交
  8. 15 9月, 2009 3 次提交
    • P
      x86: sched: Provide arch implementations using aperf/mperf · 47fe38fc
      Peter Zijlstra 提交于
      APERF/MPERF support for cpu_power.
      
      APERF/MPERF is arch defined to be a relative scale of work capacity
      per logical cpu, this is assumed to include SMT and Turbo mode.
      
      APERF/MPERF are specified to both reset to 0 when either counter
      wraps, which is highly inconvenient, since that'll give a blimp
      when that happens. The manual specifies writing 0 to the counters
      after each read, but that's 1) too expensive, and 2) destroys the
      possibility of sharing these counters with other users, so we live
      with the blimp - the other existing user does too.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47fe38fc
    • P
      x86: Add generic aperf/mperf code · 5cbc19a9
      Peter Zijlstra 提交于
      Move some of the aperf/mperf code out from the cpufreq driver
      thingy so that other people can enjoy it too.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: cpufreq@vger.kernel.org
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cbc19a9
    • P
      x86: Move APERF/MPERF into a X86_FEATURE · a8303aaf
      Peter Zijlstra 提交于
      Move the APERFMPERF capacility into a X86_FEATURE flag so that it
      can be used outside of the acpi cpufreq driver.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: cpufreq@vger.kernel.org
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a8303aaf
新手
引导
客服 返回
顶部