1. 09 Dec, 2009 1 commit
  2. 11 Nov, 2009 1 commit
    • Andreas Herrmann's avatar
      x86, ucode-amd: Ensure ucode update on suspend/resume after CPU off/online cycle · 9f15226e
      Andreas Herrmann authored
      When switching a CPU offline/online and then doing
      suspend/resume, ucode is not updated on this CPU.
      This is due to the microcode_fini_cpu() call which frees uci->mc
      when setting the CPU offline:
        static void microcode_fini_cpu_amd(int cpu)
                struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
                uci->mc = NULL;
      When the CPU is set online uci->mc is still NULL because no
      ucode update is required.
      Finally this prevents ucode update when resuming after suspend:
        static enum ucode_state microcode_resume_cpu(int cpu)
              struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
              if (!uci->mc)
                      return UCODE_NFOUND;
      Fix is to check whether uci->mc is valid before
      microcode_resume_cpu() is called.
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: dimm <dmitry.adamushko@gmail.com>
      LKML-Reference: <20091111190329.GF18592@alberich.amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  3. 10 Nov, 2009 1 commit
  4. 14 Oct, 2009 1 commit
  5. 22 Sep, 2009 1 commit
  6. 19 Sep, 2009 1 commit
  7. 16 Jun, 2009 1 commit
  8. 12 May, 2009 1 commit
    • Dmitry Adamushko's avatar
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed,... · 871b72dd
      Dmitry Adamushko authored
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic
      * Solve issues described in 6f66cbc6
        in a way that doesn't resort to set_cpus_allowed();
      * in fact, only collect_cpu_info and apply_microcode callbacks
        must run on a target cpu, others will do just fine on any other.
        smp_call_function_single() (as suggested by Ingo) is used to run
        these callbacks on a target cpu.
      * cleanup of synchronization logic of the 'microcode_core' part
        The generic 'microcode_core' part guarantees that only a single cpu
        (be it a full-fledged cpu, one of the cores or HT)
        is being updated at any particular moment of time.
        In general, there is no need for any additional sync. mechanism in
        arch-specific parts (the patch removes existing spinlocks).
        See also the "Synchronization" section in microcode_core.c.
      * return -EINVAL instead of -1 (which is translated into -EPERM) in
        microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions
        for an error code?
      * use 'enum ucode_state' as return value of request_microcode_{fw, user}
        to gain more flexibility by distinguishing between real error cases
        and situations when an appropriate ucode was not found (which is not an
        error per-se).
      * some minor cleanups
      Thanks a lot to Hugh Dickins for review/suggestions/testing!
         Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2
      [ Impact: refactor and clean up microcode driver locking code ]
      Signed-off-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
      Acked-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <1242078507.5560.9.camel@earth>
      [ did some more cleanups ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
       arch/x86/include/asm/microcode.h  |   25 ++
       arch/x86/kernel/microcode_amd.c   |   58 ++----
       arch/x86/kernel/microcode_core.c  |  326 +++++++++++++++++++++-----------------
       arch/x86/kernel/microcode_intel.c |   92 +++-------
       4 files changed, 261 insertions(+), 240 deletions(-)
      (~20 new comment lines)
  9. 16 Apr, 2009 1 commit
    • Dmitry Adamushko's avatar
      x86: fix microcode driver newly spewing warnings · 0917798d
      Dmitry Adamushko authored
      Jeff Garzik reported this WARN_ON() noise:
      > Kernel: 2.6.30-rc1-00306-g8371f87c
      > Hardware: ICH10 x86-64
      > This is a regression from 2.6.29.  Microcode spews the following WARNING
      > multiple times during boot:
      > ------------[ cut here ]------------
      > WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xeb/0xf0()
      > Hardware name:         sysfs group ffffffffa0209700 not found for
      >  kobject 'cpu0'
      Keep sysfs files around for cpus even when we failed to locate
      microcode for them at the moment of module loading. The appropriate
      microcode firmware can become available later on.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  10. 14 Apr, 2009 1 commit
    • Hugh Dickins's avatar
      x86 microcode: revert some work_on_cpu · 6f66cbc6
      Hugh Dickins authored
      Revert part of af5c820a
       ("x86: cpumask:
      use work_on_cpu in arch/x86/kernel/microcode_core.c")
      That change is causing only one Intel CPU's microcode to be updated e.g.
      microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22
      where before it announced that also for CPU0 and CPU1 and CPU2.
      We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code,
      because Intel's request_microcode_user() involves a copy_from_user() from
      /sbin/microcode_ctl, which therefore needs to be on that CPU at the time.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 18 Mar, 2009 2 commits
    • Ingo Molnar's avatar
      x86: microcode: cleanup · 4bae1967
      Ingo Molnar authored
      Impact: cleanup
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Rusty Russell's avatar
      x86: cpumask: use work_on_cpu in arch/x86/kernel/microcode_core.c · af5c820a
      Rusty Russell authored
      Impact: don't play with current's cpumask
      Straightforward indirection through work_on_cpu().  One change is
      that the error code from microcode_update_cpu() is now actually
      plumbed back to microcode_init_cpu(), so now we printk if it fails
      on cpu hotplug.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  12. 20 Dec, 2008 1 commit
    • Dmitry Adamushko's avatar
      x86: fix resume (S2R) broken by Intel microcode module, on A110L · 280a9ca5
      Dmitry Adamushko authored
      Impact: fix deadlock
      This is in response to the following bug report:
      Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12100
      Subject         : resume (S2R) broken by Intel microcode module, on A110L
      Submitter       : Andreas Mohr <andi@lisas.de>
      Date            : 2008-11-25 08:48 (19 days old)
      Handled-By      : Dmitry Adamushko <dmitry.adamushko@gmail.com>
      [ The deadlock scenario has been discovered by Andreas Mohr ]
      I think I might have a logical explanation why the system:
      might hang upon resuming, OTOH it should have likely hanged each and every time.
      (1) possible deadlock in microcode_resume_cpu() if either 'if' section is
      (2) now, I don't see it in spec. and can't experimentally verify it (newer
      ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
      think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
      be back to its original one (we need to reload ucode anyway so it doesn't seem
      logical if a cpu doesn't drop the version)... if so, the comparison with
      memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
      the aforementioned 'if' sections might have been triggered - leading to a
      Obviously, in my tests I simulated loading/resuming with the ucode of the same
      version (just to see that the file is loaded/re-loaded upon resuming) so this
      issue has never popped up.
      I'd appreciate if someone with an appropriate system might give a try to the
      2nd patch (titled "fix a comparison && deadlock...").
      In any case, the deadlock situation is a must-have fix.
      Reported-by: default avatarAndreas Mohr <andi@lisas.de>
      Signed-off-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
      Tested-by: default avatarAndreas Mohr <andi@lisas.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  13. 26 Nov, 2008 1 commit
    • Hannes Eder's avatar
      x86: microcode: fix sparse warnings · 4db646b1
      Hannes Eder authored
      Impact: make global variables and a function static
      Fix following sparse warnings:
        arch/x86/kernel/microcode_core.c:102:22: warning: symbol
        'microcode_ops' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:206:24: warning: symbol
        'microcode_pdev' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:322:6: warning: symbol
        'microcode_update_cpu' was not declared. Should it be static?
        arch/x86/kernel/microcode_intel.c:468:22: warning: symbol
        'microcode_intel_ops' was not declared. Should it be static?
      Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  14. 28 Oct, 2008 1 commit
  15. 02 Oct, 2008 1 commit
  16. 24 Sep, 2008 1 commit
  17. 23 Sep, 2008 1 commit
  18. 14 Sep, 2008 1 commit
  19. 12 Sep, 2008 1 commit
    • Dmitry Adamushko's avatar
      x86, microcode rework, v2 · a0a29b62
      Dmitry Adamushko authored
      this is a rework of the microcode splitup in tip/x86/microcode
      (1) I think this new interface is cleaner (look at the changes
          in 'struct microcode_ops' in microcode.h);
      (2) it's -64 lines of code;
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  20. 20 Aug, 2008 1 commit
    • Dmitry Adamushko's avatar
      x86-microcode: generic interface refactoring · d45de409
      Dmitry Adamushko authored
      This is the 1st patch in the series. Here the aim was to avoid any
      significant changes, logically-wise.
      So it's mainly about generic interface refactoring: e.g. make
      microcode_{intel,amd}.c more about arch-specific details and less
      about policies like make-sure-we-run-on-a-target-cpu
      (no more set_cpus_allowed_ptr() here) and generic synchronization (no
      more microcode_mutex here).
      All in all, more line have been deleted than added.
      4 files changed, 145 insertions(+), 198 deletions(-)
      Signed-off-by: default avatarDmitry Adamushko <dmitry.adamushko@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  21. 15 Aug, 2008 2 commits
  22. 29 Jul, 2008 2 commits
    • Ingo Molnar's avatar
      x86, microcode: fix symbol exports · 224e946b
      Ingo Molnar authored
      fix tons of build errors:
       arch/x86/kernel/built-in.o: In function `microcode_fini_cpu':
       microcode_intel.c:(.text+0x11598): undefined reference to `microcode_mutex'
       microcode_intel.c:(.text+0x115a4): undefined reference to `ucode_cpu_info'
       microcode_intel.c:(.text+0x115ae): undefined reference to `ucode_cpu_info'
       microcode_intel.c:(.text+0x115bc): undefined reference to `microcode_mutex'
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Ingo Molnar's avatar
      x86, microcode support: fix build error · 45b1e23e
      Ingo Molnar authored
        arch/x86/kernel/microcode.c:412: error: static declaration of ‘microcode_init’ follows non-static declaration
        include/asm/microcode.h:1: error: previous declaration of ‘microcode_init’ was here
        arch/x86/kernel/microcode.c:454: error: static declaration of ‘microcode_exit’ follows non-static declaration
        include/asm/microcode.h:2: error: previous declaration of ‘microcode_exit’ was here
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  23. 28 Jul, 2008 6 commits
  24. 26 Jul, 2008 1 commit
  25. 22 Jul, 2008 1 commit
    • Andi Kleen's avatar
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      Andi Kleen authored
      This allow to dynamically generate attributes and share show/store
      functions between attributes. Right now most attributes are generated
      by special macros and lots of duplicated code. With the attribute
      passed it's instead possible to attach some data to the attribute
      and then use that in shared low level functions to do different things.
      I need this for the dynamically generated bank attributes in the x86
      machine check code, but it'll allow some further cleanups.
      I converted all users in tree to the new show/store prototype. It's a single
      huge patch to avoid unbisectable sections.
      Runtime tested: x86-32, x86-64
      Compiled only: ia64, powerpc
      Not compile tested/only grep converted: sh, arm, avr32
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  26. 18 Jul, 2008 1 commit
    • Mike Travis's avatar
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      Mike Travis authored
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
          with new cpumask_of_cpu_ptr macros.  These are patterned after the
          node_to_cpumask_ptr macros.
          In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
          the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
          is provided when there is a large NR_CPUS count, reducing
          greatly the amount of code generated and stack space used for
          cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
          calling set_cpus_allowed_ptr() to reduce the amount of stack space
          needed to pass the cpumask_t value.
          If there isn't a cpumask_of_cpu_map[], then a temporary variable is
          declared and filled in with value from cpumask_of_cpu(cpu) as well as
          a pointer variable pointing to this temporary variable.  Afterwards,
          the pointer is used to reference the cpumask value.  The compiler
          will optimize out the extra dereference through the pointer as well
          as the stack space used for the pointer, resulting in identical code.
          A good example of the orthogonal usages is in net/sunrpc/svc.c:
      	case SVC_POOL_PERCPU:
      		unsigned int cpu = m->pool_to[pidx];
      		cpumask_of_cpu_ptr(cpumask, cpu);
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, cpumask);
      		return 1;
      	case SVC_POOL_PERNODE:
      		unsigned int node = m->pool_to[pidx];
      		node_to_cpumask_ptr(nodecpumask, node);
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, nodecpumask);
      		return 1;
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  27. 10 Jul, 2008 1 commit
  28. 03 Jul, 2008 1 commit
  29. 20 Jun, 2008 1 commit
  30. 19 Apr, 2008 1 commit
    • Mike Travis's avatar
      x86: use new set_cpus_allowed_ptr function · fc0e4748
      Mike Travis authored
        * Use new set_cpus_allowed_ptr() function added by previous patch,
          which instead of passing the "newly allowed cpus" cpumask_t arg
          by value,  pass it by pointer:
          -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
          +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)
        * Cleanup uses of CPU_MASK_ALL.
        * Collapse other NR_CPUS changes to arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
          Use pointers to cpumask_t arguments whenever possible.
      Depends on:
      	[sched-devel]: sched: add new set_cpus_allowed_ptr function
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  31. 17 Apr, 2008 1 commit
  32. 01 Feb, 2008 1 commit
    • Sam Ravnborg's avatar
      x86: fix section mismatch warnings when referencing notifiers · c72258c7
      Sam Ravnborg authored
      Fix the following warnings:
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0xf8): Section mismatch in reference from the function msr_exit() to the variable .cpuinit.data:msr_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x158): Section mismatch in reference from the function cpuid_exit() to the variable .cpuinit.data:cpuid_class_cpu_notifier
      WARNING: arch/x86/kernel/built-in.o(.exit.text+0x171): Section mismatch in reference from the function microcode_exit() to the variable .cpuinit.data:mc_cpu_notifier
      In all three cases there were a function annotated __exit
      that referenced a variable annotated __cpuinitdata.
      The fix was to replace the annotation of the notifier
      with __refdata to tell modpost that the reference to
      a _cpuinit function in the notifier are OK.
      The unregister call that references the notifier
      variable will simple delete the function pointer
      so there is no problem ignoring the reference.
      Note: This looks like another case where __cpuinit
      has been used as replacement for proper use
      of CONFIG_HOTPLUG_CPU to decide what code are used for
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>