1. 05 2月, 2010 1 次提交
  2. 29 1月, 2010 1 次提交
  3. 27 1月, 2010 1 次提交
  4. 25 1月, 2010 5 次提交
  5. 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
  6. 23 1月, 2010 3 次提交
  7. 21 1月, 2010 1 次提交
  8. 19 1月, 2010 2 次提交
  9. 17 1月, 2010 1 次提交
  10. 16 1月, 2010 2 次提交
  11. 13 1月, 2010 6 次提交
    • I
      x86: xen: 64-bit kernel RPL should be 0 · e68266b7
      Ian Campbell 提交于
      Under Xen 64 bit guests actually run their kernel in ring 3,
      however the hypervisor takes care of squashing descriptor the
      RPLs transparently (in order to allow them to continue to
      differentiate between user and kernel space CS using the RPL).
      Therefore the Xen paravirt backend should use RPL==0 instead of
      1 (or 3). Using RPL==1 causes generic arch code to take
      incorrect code paths because it uses "testl $3, <CS>, je foo"
      type tests for a userspace CS and this considers 1==userspace.
      
      This issue was previously masked because get_kernel_rpl() was
      omitted when setting CS in kernel_thread(). This was fixed when
      kernel_thread() was unified with 32 bit in
      f443ff42.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      LKML-Reference: <1263377768-19600-2-git-send-email-ian.campbell@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e68266b7
    • C
      x86: kernel_thread() -- initialize SS to a known state · 864a0922
      Cyrill Gorcunov 提交于
      Before the kernel_thread was converted into "C" we had
      pt_regs::ss set to __KERNEL_DS (by SAVE_ALL asm macro).
      
      Though I must admit I didn't find any *explicit* load of
      %ss from this structure the better to be on a safe side
      and set it to a known value.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      LKML-Reference: <1263377768-19600-1-git-send-email-ian.campbell@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      864a0922
    • F
      x86/agp: Fix agp_amd64_init and agp_amd64_cleanup · 42590a75
      FUJITA Tomonori 提交于
      This fixes the regression introduced by the commit
      f405d2c0.
      
      The above commit fixes the following issue:
      
        http://marc.info/?l=linux-kernel&m=126192729110083&w=2
      
      However, it doesn't work properly when you remove and insert the
      agp_amd64 module again.
      
      agp_amd64_init() and agp_amd64_cleanup should be called only
      when gart_iommu is not called earlier (that is, the GART IOMMU
      is not enabled). We need to use 'gart_iommu_aperture' to see if
      GART IOMMU is enabled or not.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: mitov@issp.bas.bg
      Cc: davej@redhat.com
      LKML-Reference: <20100104161603L.fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      42590a75
    • M
      x86: SGI UV: Fix mapping of MMIO registers · fcfbb2b5
      Mike Travis 提交于
      This fixes the problem of the initialization code not correctly
      mapping the entire MMIO space on a UV system.  A side effect is
      the map_high() interface needed to be changed to accommodate
      different address and size shifts.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NMike Habeck <habeck@sgi.com>
      Cc: <stable@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <4B479202.7080705@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcfbb2b5
    • A
      x86: mce.h: Fix warning in header checks · df39a2e4
      Alan Cox 提交于
      Someone isn't reading their build output: Move the definition
      out of the exported header.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Cc: linux-kernel@vger.kernelorg
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      df39a2e4
    • F
      perf: Stop stack frame walking off kernel addresses boundaries · c2c5d45d
      Frederic Weisbecker 提交于
      While processing kernel perf callchains, an bad entry can be
      considered as a valid stack pointer but not as a kernel address.
      
      In this case, we hang in an endless loop. This can happen in an
      x86-32 kernel after processing the last entry in a kernel
      stacktrace.
      
      Just stop the stack frame walking after we encounter an invalid
      kernel address.
      
      This fixes a hard lockup in x86-32.
      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: <1262227945-27014-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c2c5d45d
  12. 12 1月, 2010 4 次提交
  13. 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
  14. 06 1月, 2010 2 次提交
  15. 05 1月, 2010 3 次提交
  16. 31 12月, 2009 3 次提交
  17. 29 12月, 2009 1 次提交
    • M
      x86: SGI UV: Fix writes to led registers on remote uv hubs · 39d30770
      Mike Travis 提交于
      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: NMike Travis <travis@sgi.com>
      Reviewed-by: NJack 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: NIngo Molnar <mingo@elte.hu>
      39d30770
  18. 28 12月, 2009 1 次提交