1. 20 2月, 2013 1 次提交
  2. 01 2月, 2013 2 次提交
  3. 21 1月, 2013 1 次提交
  4. 10 1月, 2013 1 次提交
  5. 30 11月, 2012 1 次提交
  6. 18 11月, 2012 2 次提交
  7. 14 11月, 2012 2 次提交
  8. 01 11月, 2012 1 次提交
  9. 07 8月, 2012 2 次提交
  10. 08 6月, 2012 3 次提交
  11. 27 4月, 2012 1 次提交
  12. 17 4月, 2012 1 次提交
  13. 16 4月, 2012 1 次提交
  14. 07 2月, 2012 1 次提交
    • B
      x86/sched/perf/AMD: Set sched_clock_stable · c98fdeaa
      Borislav Petkov 提交于
      Stephane Eranian reported that doing a scheduler latency
      measurements with perf on AMD doesn't work out as expected due
      to the fact that the sched_clock() granularity is too coarse,
      i.e. done in jiffies due to the sched_clock_stable not set,
      which, if set, would mean that we get to use the TSC as sample
      source which would give us much higher precision.
      
      However, there's no reason not to set sched_clock_stable on AMD
      because all families from F10h and upwards do have an invariant
      TSC and have the CPUID flag to prove (CPUID_8000_0007_EDX[8]).
      
      Make it so, #1.
      Signed-off-by: NBorislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: Venki Pallipadi <venki@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Link: http://lkml.kernel.org/r/20120206132546.GA30854@quad
      [ Should any non-standard system break the TSC, we should
        mark them so explicitly, in their platform init handler, or
        in a DMI quirk. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c98fdeaa
  15. 21 12月, 2011 1 次提交
  16. 06 12月, 2011 1 次提交
  17. 05 12月, 2011 1 次提交
    • L
      x86: Fix boot failures on older AMD CPU's · 8e8da023
      Linus Torvalds 提交于
      People with old AMD chips are getting hung boots, because commit
      bcb80e53 ("x86, microcode, AMD: Add microcode revision to
      /proc/cpuinfo") moved the microcode detection too early into
      "early_init_amd()".
      
      At that point we are *so* early in the booth that the exception tables
      haven't even been set up yet, so the whole
      
      	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
      
      doesn't actually work: if the rdmsr does a GP fault (due to non-existant
      MSR register on older CPU's), we can't fix it up yet, and the boot fails.
      
      Fix it by simply moving the code to a slightly later point in the boot
      (init_amd() instead of early_init_amd()), since the kernel itself
      doesn't even really care about the microcode patchlevel at this point
      (or really ever: it's made available to user space in /proc/cpuinfo, and
      updated if you do a microcode load).
      Reported-tested-and-bisected-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Tested-by: NBob Tracy <rct@gherkin.frus.com>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8e8da023
  18. 01 11月, 2011 1 次提交
    • P
      x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE · 69c60c88
      Paul Gortmaker 提交于
      These files were implicitly getting EXPORT_SYMBOL via device.h
      which was including module.h, but that will be fixed up shortly.
      
      By fixing these now, we can avoid seeing things like:
      
      arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
      
      [ with input from Randy Dunlap <rdunlap@xenotime.net> and also
        from Stephen Rothwell <sfr@canb.auug.org.au> ]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      69c60c88
  19. 19 10月, 2011 1 次提交
  20. 10 8月, 2011 1 次提交
    • S
      x86, amd: Include elf.h explicitly, prepare the code for the module.h split · 5cdd174f
      Stephen Rothwell 提交于
      When the moduleu.h splitting tree is merged to the latest
      tip:x86/cpu tree, the x86_64 allmodconfig build fails like this:
      
       arch/x86/kernel/cpu/amd.c: In function 'bsp_init_amd':
       arch/x86/kernel/cpu/amd.c:437:3: error: 'va_align' undeclared (first use in this function)
       arch/x86/kernel/cpu/amd.c:438:23: error: 'ALIGN_VA_32' undeclared (first use in this function)
       arch/x86/kernel/cpu/amd.c:438:37: error: 'ALIGN_VA_64' undeclared (first use in this function)
      
      This is caused by the module.h split up intreacting with commit
      dfb09f9b ("x86, amd: Avoid cache aliasing penalties on AMD
      family 15h") from the tip:x86/cpu tree.
      
      I have added the following patch for today (this, or something
      similar, could be applied to the tip tree directly - the
      export.h include below was added by the module.h splitup).
      
      So include elf.h to use va_align and remove this implicit
      dependency on module.h doing it for us.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Link: http://lkml.kernel.org/r/20110810114956.238d66772883636e3040d29f@canb.auug.org.auSigned-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd174f
  21. 06 8月, 2011 2 次提交
  22. 27 5月, 2011 1 次提交
  23. 20 5月, 2011 1 次提交
  24. 17 5月, 2011 2 次提交
  25. 02 5月, 2011 1 次提交
  26. 16 4月, 2011 1 次提交
  27. 16 3月, 2011 1 次提交
  28. 15 2月, 2011 1 次提交
    • B
      x86, amd: Initialize variable properly · 9e81509e
      Borislav Petkov 提交于
      Commit d518573d ("x86, amd: Normalize compute unit IDs on
      multi-node processors") introduced compute unit normalization
      but causes a compiler warning:
      
       arch/x86/kernel/cpu/amd.c: In function 'amd_detect_cmp':
       arch/x86/kernel/cpu/amd.c:268: warning: 'cores_per_cu' may be used uninitialized in this function
       arch/x86/kernel/cpu/amd.c:268: note: 'cores_per_cu' was declared here
      
      The compiler is right - initialize it with a proper value.
      
      Also, fix up a comment while at it.
      Reported-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      LKML-Reference: <20110214171451.GB10076@kryptos.osrc.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e81509e
  29. 28 1月, 2011 2 次提交
    • T
      x86: Unify CPU -> NUMA node mapping between 32 and 64bit · 645a7919
      Tejun Heo 提交于
      Unlike 64bit, 32bit has been using its own cpu_to_node_map[] for
      CPU -> NUMA node mapping.  Replace it with early_percpu variable
      x86_cpu_to_node_map and share the mapping code with 64bit.
      
      * USE_PERCPU_NUMA_NODE_ID is now enabled for 32bit too.
      
      * x86_cpu_to_node_map and numa_set/clear_node() are moved from
        numa_64 to numa.  For now, on 32bit, x86_cpu_to_node_map is initialized
        with 0 instead of NUMA_NO_NODE.  This is to avoid introducing unexpected
        behavior change and will be updated once init path is unified.
      
      * srat_detect_node() is now enabled for x86_32 too.  It calls
        numa_set_node() and initializes the mapping making explicit
        cpu_to_node_map[] updates from map/unmap_cpu_to_node() unnecessary.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: penberg@kernel.org
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-15-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: David Rientjes <rientjes@google.com>
      645a7919
    • T
      x86: Unify cpu/apicid <-> NUMA node mapping between 32 and 64bit · bbc9e2f4
      Tejun Heo 提交于
      The mapping between cpu/apicid and node is done via
      apicid_to_node[] on 64bit and apicid_2_node[] +
      apic->x86_32_numa_cpu_node() on 32bit. This difference makes it
      difficult to further unify 32 and 64bit NUMA handling.
      
      This patch unifies it by replacing both apicid_to_node[] and
      apicid_2_node[] with __apicid_to_node[] array, which is accessed
      by two accessors - set_apicid_to_node() and numa_cpu_node().  On
      64bit, numa_cpu_node() always consults __apicid_to_node[]
      directly while 32bit goes through apic->numa_cpu_node() method
      to allow apic implementations to override it.
      
      srat_detect_node() for amd cpus contains workaround for broken
      NUMA configuration which assumes relationship between APIC ID,
      HT node ID and NUMA topology.  Leave it to access
      __apicid_to_node[] directly as mapping through CPU might result
      in undesirable behavior change.  The comment is reformatted and
      updated to note the ugliness.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: eric.dumazet@gmail.com
      Cc: yinghai@kernel.org
      Cc: brgerst@gmail.com
      Cc: gorcunov@gmail.com
      Cc: shaohui.zheng@intel.com
      Cc: rientjes@google.com
      LKML-Reference: <1295789862-25482-14-git-send-email-tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: David Rientjes <rientjes@google.com>
      bbc9e2f4
  30. 26 1月, 2011 1 次提交
  31. 30 12月, 2010 1 次提交