1. 13 2月, 2010 2 次提交
  2. 11 2月, 2010 7 次提交
  3. 02 2月, 2010 1 次提交
  4. 30 1月, 2010 4 次提交
    • J
      perf, hw_breakpoint, kgdb: Do not take mutex for kernel debugger · 5352ae63
      Jason Wessel 提交于
      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: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NFrederic 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: NIngo Molnar <mingo@elte.hu>
      5352ae63
    • J
      x86, hw_breakpoints, kgdb: Fix kgdb to use hw_breakpoint API · cc096749
      Jason Wessel 提交于
      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: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NFrederic 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: NIngo Molnar <mingo@elte.hu>
      cc096749
    • D
      x86: Add quirk for Intel DG45FC board to avoid low memory corruption · 7c099ce1
      David Härdeman 提交于
      Commit 6aa542a6 added a quirk for the
      Intel DG45ID board due to low memory corruption. The Intel DG45FC
      shares the same BIOS (and the same bug) as noted in:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=13736Signed-off-by: NDavid Härdeman <david@hardeman.nu>
      LKML-Reference: <20100128200254.GA9134@hardeman.nu>
      Cc: <stable@kernel.org>
      Cc: Alexey Fisher <bug-track@fisher-privat.net>
      Cc: ykzhao <yakui.zhao@intel.com>
      Cc: Tony Bones <aabonesml@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      7c099ce1
    • H
      x86: get rid of the insane TIF_ABI_PENDING bit · 05d43ed8
      H. Peter Anvin 提交于
      Now that the previous commit made it possible to do the personality
      setting at the point of no return, we do just that for ELF binaries.
      And suddenly all the reasons for that insane TIF_ABI_PENDING bit go
      away, and we can just make SET_PERSONALITY() just do the obvious thing
      for a 32-bit compat process.
      
      Everything becomes much more straightforward this way.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05d43ed8
  5. 28 1月, 2010 1 次提交
  6. 27 1月, 2010 2 次提交
  7. 24 1月, 2010 1 次提交
    • H
      x86: Remove "x86 CPU features in debugfs" (CONFIG_X86_CPU_DEBUG) · b1600918
      H. Peter Anvin 提交于
      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: NOzan Çağlayan <ozan@pardus.org.tr>
      Signed-off-by: NH. 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
  8. 23 1月, 2010 5 次提交
  9. 22 1月, 2010 1 次提交
  10. 21 1月, 2010 1 次提交
  11. 19 1月, 2010 2 次提交
  12. 16 1月, 2010 2 次提交
  13. 13 1月, 2010 5 次提交
  14. 12 1月, 2010 1 次提交
  15. 07 1月, 2010 2 次提交
    • L
      x86, ACPI: delete acpi_boot_table_init() return value · 8558e394
      Len Brown 提交于
      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: NLen Brown <len.brown@intel.com>
      8558e394
    • S
      x86, irq: Check move_in_progress before freeing the vector mapping · 7f41c2e1
      Suresh Siddha 提交于
      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: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NSuresh 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: NH. Peter Anvin <hpa@zytor.com>
      7f41c2e1
  16. 05 1月, 2010 1 次提交
  17. 31 12月, 2009 2 次提交
    • F
      perf: Pass appropriate frame pointer to dump_trace() · 48b5ba9c
      Frederic Weisbecker 提交于
      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: NFrederic 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: NIngo 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
    • Z
      ACPI: introduce kernel parameter acpi_sleep=sci_force_enable · d7f0eea9
      Zhang Rui 提交于
      Introduce kernel parameter acpi_sleep=sci_force_enable
      
      some laptop requires SCI_EN being set directly on resume,
      or else they hung somewhere in the resume code path.
      
      We already have a blacklist for these laptops but we still need
      this option, especially when debugging some suspend/resume problems,
      in case there are systems that need this workaround and are not yet
      in the blacklist.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d7f0eea9