1. 16 4月, 2013 2 次提交
  2. 03 4月, 2013 2 次提交
  3. 20 2月, 2013 1 次提交
  4. 01 2月, 2013 2 次提交
  5. 21 1月, 2013 1 次提交
  6. 10 1月, 2013 1 次提交
  7. 30 11月, 2012 1 次提交
  8. 18 11月, 2012 2 次提交
  9. 14 11月, 2012 2 次提交
  10. 01 11月, 2012 1 次提交
  11. 07 8月, 2012 2 次提交
  12. 08 6月, 2012 3 次提交
  13. 27 4月, 2012 1 次提交
  14. 17 4月, 2012 1 次提交
  15. 16 4月, 2012 1 次提交
  16. 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
  17. 21 12月, 2011 1 次提交
  18. 06 12月, 2011 1 次提交
  19. 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
  20. 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
  21. 19 10月, 2011 1 次提交
  22. 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
  23. 06 8月, 2011 2 次提交
  24. 27 5月, 2011 1 次提交
  25. 20 5月, 2011 1 次提交
  26. 17 5月, 2011 2 次提交
  27. 02 5月, 2011 1 次提交
  28. 16 4月, 2011 1 次提交
  29. 16 3月, 2011 1 次提交
  30. 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