1. 10 Feb, 2010 1 commit
    • Suresh Siddha's avatar
      x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs · 681ee44d
      Suresh Siddha authored
      We need to fall back from logical-flat APIC mode to physical-flat mode
      when we have more than 8 CPUs.  However, in the presence of CPU
      hotplug(with bios listing not enabled but possible cpus as disabled cpus in
      MADT), we have to consider the number of possible CPUs rather than
      the number of current CPUs; otherwise we may cross the 8-CPU boundary
      when CPUs are added later.
      
      32bit apic code can use more cleanups (like the removal of vendor checks in
      32bit default_setup_apic_routing()) and more unifications with 64bit code.
      Yinghai has some patches in works already. This patch addresses the boot issue
      that is reported in the virtualization guest context.
      
      [ hpa: incorporated function annotation feedback from Yinghai Lu ]
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1265767304.2833.19.camel@sbs-t61.sc.intel.com>
      Acked-by: default avatarShaohui Zheng <shaohui.zheng@intel.com>
      Reviewed-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      681ee44d
  2. 30 Jan, 2010 2 commits
    • Jason Wessel's avatar
      perf, hw_breakpoint, kgdb: Do not take mutex for kernel debugger · 5352ae63
      Jason Wessel authored
      This patch fixes the regression in functionality where the
      kernel debugger and the perf API do not nicely share hw
      breakpoint reservations.
      
      The kernel debugger cannot use any mutex_lock() calls because it
      can start the kernel running from an invalid context.
      
      A mutex free version of the reservation API needed to get
      created for the kernel debugger to safely update hw breakpoint
      reservations.
      
      The possibility for a breakpoint reservation to be concurrently
      processed at the time that kgdb interrupts the system is
      improbable. Should this corner case occur the end user is
      warned, and the kernel debugger will prohibit updating the
      hardware breakpoint reservations.
      
      Any time the kernel debugger reserves a hardware breakpoint it
      will be a system wide reservation.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: kgdb-bugreport@lists.sourceforge.net
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: torvalds@linux-foundation.org
      LKML-Reference: <1264719883-7285-3-git-send-email-jason.wessel@windriver.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5352ae63
    • Jason Wessel's avatar
      x86, hw_breakpoints, kgdb: Fix kgdb to use hw_breakpoint API · cc096749
      Jason Wessel authored
      In the 2.6.33 kernel, the hw_breakpoint API is now used for the
      performance event counters.  The hw_breakpoint_handler() now
      consumes the hw breakpoints that were previously set by kgdb
      arch specific code.  In order for kgdb to work in conjunction
      with this core API change, kgdb must use some of the low level
      functions of the hw_breakpoint API to install, uninstall, and
      deal with hw breakpoint reservations.
      
      The kgdb core required a change to call kgdb_disable_hw_debug
      anytime a slave cpu enters kgdb_wait() in order to keep all the
      hw breakpoints in sync as well as to prevent hitting a hw
      breakpoint while kgdb is active.
      
      During the architecture specific initialization of kgdb, it will
      pre-allocate 4 disabled (struct perf event **) structures.  Kgdb
      will use these to manage the capabilities for the 4 hw
      breakpoint registers, per cpu.  Right now the hw_breakpoint API
      does not have a way to ask how many breakpoints are available,
      on each CPU so it is possible that the install of a breakpoint
      might fail when kgdb restores the system to the run state.  The
      intent of this patch is to first get the basic functionality of
      hw breakpoints working and leave it to the person debugging the
      kernel to understand what hw breakpoints are in use and what
      restrictions have been imposed as a result.  Breakpoint
      constraints will be dealt with in a future patch.
      
      While atomic, the x86 specific kgdb code will call
      arch_uninstall_hw_breakpoint() and arch_install_hw_breakpoint()
      to manage the cpu specific hw breakpoints.
      
      The net result of these changes allow kgdb to use the same pool
      of hw_breakpoints that are used by the perf event API, but
      neither knows about future reservations for the available hw
      breakpoint slots.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Acked-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: kgdb-bugreport@lists.sourceforge.net
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: torvalds@linux-foundation.org
      LKML-Reference: <1264719883-7285-2-git-send-email-jason.wessel@windriver.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cc096749
  3. 29 Jan, 2010 2 commits
  4. 28 Jan, 2010 1 commit
  5. 27 Jan, 2010 2 commits
  6. 24 Jan, 2010 1 commit
    • H. Peter Anvin's avatar
      x86: Remove "x86 CPU features in debugfs" (CONFIG_X86_CPU_DEBUG) · b1600918
      H. Peter Anvin authored
      CONFIG_X86_CPU_DEBUG, which provides some parsed versions of the x86
      CPU configuration via debugfs, has caused boot failures on real
      hardware.  The value of this feature has been marginal at best, as all
      this information is already available to userspace via generic
      interfaces.
      
      Causes crashes that have not been fixed + minimal utility -> remove.
      
      See the referenced LKML thread for more information.
      Reported-by: default avatarOzan Çağlayan <ozan@pardus.org.tr>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <alpine.LFD.2.00.1001221755320.13231@localhost.localdomain>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: <stable@kernel.org>
      b1600918
  7. 23 Jan, 2010 2 commits
  8. 22 Jan, 2010 4 commits
  9. 21 Jan, 2010 1 commit
  10. 18 Jan, 2010 2 commits
  11. 15 Jan, 2010 2 commits
  12. 13 Jan, 2010 5 commits
  13. 12 Jan, 2010 1 commit
  14. 06 Jan, 2010 2 commits
    • Len Brown's avatar
      x86, ACPI: delete acpi_boot_table_init() return value · 8558e394
      Len Brown authored
      cleanup only.
      
      setup_arch(), doesn't care care if ACPI initialization succeeded
      or failed, so delete acpi_boot_table_init()'s return value.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      8558e394
    • Suresh Siddha's avatar
      x86, irq: Check move_in_progress before freeing the vector mapping · 7f41c2e1
      Suresh Siddha authored
      With the recent irq migration fixes (post 2.6.32), Gary Hade has noticed
      "No IRQ handler for vector" messages during the 2.6.33-rc1 kernel boot on IBM
      AMD platforms and root caused the issue to this commit:
      
      > commit 23359a88
      > Author: Suresh Siddha <suresh.b.siddha@intel.com>
      > Date:   Mon Oct 26 14:24:33 2009 -0800
      >
      >    x86: Remove move_cleanup_count from irq_cfg
      
      As part of this patch, we have removed the move_cleanup_count check
      in smp_irq_move_cleanup_interrupt(). With this change, we can run into a
      situation where an irq cleanup interrupt on a cpu can cleanup the vector
      mappings associated with multiple irqs, of which one of the irq's migration
      might be still in progress. As such when that irq hits the old cpu, we get
      the "No IRQ handler" messages.
      
      Fix this by checking for the irq_cfg's move_in_progress and if the move
      is still in progress delay the vector cleanup to another irq cleanup
      interrupt request (which will happen when the irq starts arriving at the
      new cpu destination).
      Reported-and-tested-by: default avatarGary Hade <garyhade@us.ibm.com>
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1262804191.2732.7.camel@sbs-t61.sc.intel.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      7f41c2e1
  15. 04 Jan, 2010 1 commit
  16. 31 Dec, 2009 1 commit
    • Frederic Weisbecker's avatar
      perf: Pass appropriate frame pointer to dump_trace() · 48b5ba9c
      Frederic Weisbecker authored
      Pass the frame pointer from the regs of the interrupted path
      to dump_trace() while processing the stack trace.
      
      Currently, dump_trace() takes the current bp and starts the
      callchain from dump_trace() itself. This is wasteful because
      we need to walk through the entire NMI/DEBUG stack before
      retrieving the interrupted point.
      
      We can fix that by just using the frame pointer from the
      captured regs. It points exactly where we want to start.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1262235183-5320-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      48b5ba9c
  17. 30 Dec, 2009 2 commits
  18. 29 Dec, 2009 1 commit
    • Mike Travis's avatar
      x86: SGI UV: Fix writes to led registers on remote uv hubs · 39d30770
      Mike Travis authored
      The wrong address was being used to write the SCIR led regs on
      remote hubs.  Also, there was an inconsistency between how BIOS
      and the kernel indexed these regs.  Standardize on using the
      lower 6 bits of the APIC ID as the index.
      
      This patch fixes the problem of writing to an errant address to
      a cpu # >= 64.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable@kernel.org
      LKML-Reference: <4B3922F9.3060905@sgi.com>
      [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      39d30770
  19. 28 Dec, 2009 1 commit
    • Pekka Enberg's avatar
      x86: Use KERN_DEFAULT log-level in __show_regs() · d015a092
      Pekka Enberg authored
      Andrew Morton reported a strange looking kmemcheck warning:
      
        WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88004fba6c20)
        0000000000000000310000000000000000000000000000002413000000c9ffff
         u u u u u u u u u u u u u u u u i i i i i i i i u u u u u u u u
      
         [<ffffffff810af3aa>] kmemleak_scan+0x25a/0x540
         [<ffffffff810afbcb>] kmemleak_scan_thread+0x5b/0xe0
         [<ffffffff8104d0fe>] kthread+0x9e/0xb0
         [<ffffffff81003074>] kernel_thread_helper+0x4/0x10
         [<ffffffffffffffff>] 0xffffffffffffffff
      
      The above printout is missing register dump completely. The
      problem here is that the output comes from syslog which doesn't
      show KERN_INFO log-level messages. We didn't see this before
      because both of us were testing on 32-bit kernels which use the
      _default_ log-level.
      
      Fix that up by explicitly using KERN_DEFAULT log-level for
      __show_regs() printks.
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <1261988819.4641.2.camel@penberg-laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d015a092
  20. 23 Dec, 2009 1 commit
    • Linus Torvalds's avatar
      Revert "x86, ucode-amd: Ensure ucode update on suspend/resume after CPU off/online cycle" · 2f99f5c8
      Linus Torvalds authored
      This reverts commit 9f15226e.  It's just
      wrong, and broke resume for Rafael even on a non-AMD CPU.
      
      As Rafael says:
       "... it causes microcode_init_cpu() to be called during resume even for
        CPUs for which there's no microcode to apply.  That, in turn, results
        in executing request_firmware() (on Intel CPUs at least) which doesn't
        work at this stage of resume (we have device interrupts disabled, I/O
        devices are still suspended and so on).
      
        If I'm not mistaken, the "if (uci->valid)" logic means "if that CPU is
        known to us" , so before commit 9f15226e microcode_resume_cpu() was
        called for all CPUs already in the system during suspend, which was
        the right thing to do.  The commit changed it so that the CPUs without
        microcode to apply are now treated as "unknown", which is not quite
        right.
      
        The problem this commit attempted to solve has to be handled
        differently."
      
      Bisected-and -requested-by: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f99f5c8
  21. 22 Dec, 2009 5 commits
    • Andrew Morton's avatar
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by... · 4a28395d
      Andrew Morton authored
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by using smp_call_function_any()
      
      Presently acpi-cpufreq will perform the MSR read on the first CPU in the
      mask.  That's inefficient if that CPU differs from the current CPU.
      Because we have to perform a cross-CPU call, but we could have run the
      rdmsr on the current CPU.
      
      So switch to using the new smp_call_function_any(), which will perform the
      call on the current CPU if that CPU is present in the mask (it is).
      
      Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Zhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      4a28395d
    • Alex Chiang's avatar
      ACPI: processor: unify arch_acpi_processor_cleanup_pdc · 47817254
      Alex Chiang authored
      The x86 and ia64 implementations of the function in $subject are
      exactly the same.
      
      Also, since the arch-specific implementations of setting _PDC have
      been completely hollowed out, remove the empty shells.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      47817254
    • Alex Chiang's avatar
      ACPI: processor: finish unifying arch_acpi_processor_init_pdc() · 6c5807d7
      Alex Chiang authored
      The only thing arch-specific about calling _PDC is what bits get
      set in the input obj_list buffer.
      
      There's no need for several levels of indirection to twiddle those
      bits. Additionally, since we're just messing around with a buffer,
      we can simplify the interface; no need to pass around the entire
      struct acpi_processor * just to get at the buffer.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      6c5807d7
    • Alex Chiang's avatar
      ACPI: processor: factor out common _PDC settings · 08ea48a3
      Alex Chiang authored
      Both x86 and ia64 initialize _PDC with mostly common bit settings.
      
      Factor out the common settings and leave the arch-specific ones alone.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      08ea48a3
    • Alex Chiang's avatar
      ACPI: processor: unify arch_acpi_processor_init_pdc · 407cd87c
      Alex Chiang authored
      The x86 and ia64 implementations of arch_acpi_processor_init_pdc()
      are almost exactly the same. The only difference is in what bits
      they set in obj_list buffer.
      
      Combine the boilerplate memory management code, and leave the
      arch-specific bit twiddling in separate implementations.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      407cd87c