1. 26 9月, 2006 4 次提交
  2. 12 9月, 2006 1 次提交
  3. 04 7月, 2006 2 次提交
  4. 30 6月, 2006 2 次提交
  5. 27 6月, 2006 3 次提交
    • J
      [PATCH] x86_64: Calgary IOMMU - Calgary specific bits · e465058d
      Jon Mason 提交于
      This patch hooks Calgary into the build, the x86-64 IOMMU
      initialization paths, and introduces the Calgary specific bits.  The
      implementation draws inspiration from both PPC (which has support for
      the same chip but requires firmware support which we don't have on
      x86-64) and gart. Calgary is different from gart in that it support a
      translation table per PHB, as opposed to the single gart aperture.
      
      Changes from previous version:
       * Addition of boot-time disablement for bus-level translation/isolation
         (e.g, enable userspace DMA for things like X)
       * Usage of newer IOMMU abstraction functions
      Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com>
      Signed-off-by: NJon Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e465058d
    • A
      [PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded. · a813ce43
      Andi Kleen 提交于
       - Rename the GART_IOMMU option to IOMMU to make clear it's not
         just for AMD
       - Rewrite the help text to better emphatise this fact
       - Make it an embedded option because too many people get it wrong.
      
      To my astonishment I discovered the aacraid driver tests this
      symbol directly. This looks quite broken to me - it's an internal
      implementation detail of the PCI DMA API. Can the maintainer
      please clarify what this test was intended to do?
      
      Cc: linux-scsi@vger.kernel.org
      Cc: alan@redhat.com
      Cc: markh@osdl.org
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a813ce43
    • A
      [PATCH] x86_64: Clean and enhance up K8 northbridge access code · a32073bf
      Andi Kleen 提交于
       - Factor out the duplicated access/cache code into a single file
         * Shared between i386/x86-64.
       - Share flush code between AGP and IOMMU
         * Fix a bug: AGP didn't wait for end of flush before
       - Drop 8 northbridges limit and allocate dynamically
       - Add lock to serialize AGP and IOMMU GART flushes
       - Add PCI ID for next AMD northbridge
       - Random related cleanups
      
      The old K8 NUMA discovery code is unchanged. New systems
      should all use SRAT for this.
      
      Cc: "Navin Boppuri" <navin.boppuri@newisys.com>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a32073bf
  6. 23 6月, 2006 1 次提交
  7. 11 4月, 2006 1 次提交
    • Y
      [PATCH] Configurable NODES_SHIFT · c80d79d7
      Yasunori Goto 提交于
      Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for
      each arch.  Its definition is sometimes configurable.  Indeed, ia64 defines 5
      NODES_SHIFT values in the current git tree.  But it looks a bit messy.
      
      SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has
      been changeable by config.  Suitable node's number may be changed in the
      future even if it is other architecture.  So, I wrote configurable node's
      number.
      
      This patch set defines just default value for each arch which needs multi
      nodes except ia64.  But, it is easy to change to configurable if necessary.
      
      On ia64 the number of nodes can be already configured in generic ia64 and SN2
      config.  But, NODES_SHIFT is defined for DIG64 and HP'S machine too.  So, I
      changed it so that all platforms can be configured via CONFIG_NODES_SHIFT.  It
      would be simpler.
      
      See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c80d79d7
  8. 10 4月, 2006 1 次提交
  9. 02 4月, 2006 1 次提交
  10. 28 3月, 2006 2 次提交
  11. 27 3月, 2006 1 次提交
  12. 26 3月, 2006 5 次提交
    • J
      [PATCH] x86_64: Make GART_IOMMU kconfig help text more specific (trivial) · 5d05f4de
      Jon Mason 提交于
      Have the GART_IOMMU help text specify that this is the hardware IOMMU in
      amd64 processors.  This will be significant if/when other IOMMUs are
      added to the x86-64 architecture. :-)
      
      Also, note that the previous help text stated that IOMMU was needed for
      >3GB memory instead of >4GB.  This is fixed in the newer version.
      Signed-off-by: NJon Mason <jdmason@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d05f4de
    • A
      [PATCH] x86_64: Remove CONFIG_UNORDERED_IO · ba22f135
      Andi Kleen 提交于
      It was a failed experiment - all benchmarks done with it on both AMD
      and Intel showed it was a loss. That was probably because the store
      buffers of the CPUs for write combining traffic weren't large enough.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ba22f135
    • A
      [PATCH] x86_64: Limit max number of CPUs to 255 · 01d4bed4
      Andi Kleen 提交于
      Because 256 causes overflows in some code that stores them in 8 bit
      fields and the x86 APIC architecture cannot handle more than 255
      anyways.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01d4bed4
    • A
      [PATCH] x86_64: Basic reorder infrastructure · 4bdc3b7f
      Arjan van de Ven 提交于
      This patch puts the infrastructure in place to allow for a reordering of
      functions based inside the vmlinux. The general idea is that it is possible
      to put all "common" functions into the first 2Mb of the code, so that they
      are covered by one TLB entry. This as opposed to the current situation where
      a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
      
      This is done by enabling the -ffunction-sections flag in gcc, which puts
      each function in its own ELF section, so that the linker can then order them
      in a way defined by the linker script.
      
      As per previous discussions, Linus said he wanted a "static" list for this,
      eg a list provided by the kernel tarbal, so that most people have the same
      ordering at least. A script is provided to create this list based on
      readprofile(1) output. The included list is provisional, and entirely biased
      on my own testbox and me running a few kernel compiles and some other
      things.
      
      I think that to get to a better list we need to invite people to submit
      their own profiles, and somehow add those all up and base the final list on
      that. I'm willing to do that effort if this is ends up being the prefered
      approach. Such an effort probably needs to be repeated like once a year or
      so to adopt to the changing nature of the kernel.
      
      Made it a CONFIG with default n because it increases link times
      dramatically.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4bdc3b7f
    • A
      [PATCH] x86_64: Move kernel to 2MB · 04103609
      Andi Kleen 提交于
      As suggested by Andi (and Alan), move the default kernel location
      from 1Mb to 2Mb, to align to the start of a TLB entry.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      04103609
  13. 27 2月, 2006 2 次提交
  14. 17 1月, 2006 2 次提交
  15. 12 1月, 2006 3 次提交
  16. 11 1月, 2006 2 次提交
    • M
      [PATCH] kexec: change CONFIG_PHYSICAL_START dependency · 05970d47
      Maneesh Soni 提交于
      I have heard some complaints about people not finding CONFIG_CRASH_DUMP
      option and also some objections about its dependency on CONFIG_EMBEDDED.
      The following patch ends that dependency.  I thought of hiding it under
      CONFIG_KEXEC, but CONFIG_PHYSICAL_START could also be used for some reasons
      other than kexec/kdump and hence left it visible.  I will also update the
      documentation accordingly.
      
      o Following patch removes the config dependency of CONFIG_PHYSICAL_START
        on CONFIG_EMBEDDED. The reason being CONFIG_CRASH_DUMP option for
        kdump needs CONFIG_PHYSICAL_START which makes CONFIG_CRASH_DUMP depend
        on CONFIG_EMBEDDED. It is not always obvious for kdump users to choose
        CONFIG_EMBEDDED.
      
      o It also shifts the palce where this option appears, to make it closer
        to kexec and kdump options.
      Signed-off-by: NManeesh Soni <maneesh@in.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Haren Myneni <haren@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      05970d47
    • V
      [PATCH] kdump: x86_64 save cpu registers upon crash · ec9ce0db
      Vivek Goyal 提交于
      - Saving the cpu registers of all cpus before booting in to the crash
        kernel.
      
      - crash_setup_regs will save the registers of the cpu on which panic has
        occured.  One of the concerns ppc64 folks raised is that after capturing the
        register states, one should not pop the current call frame and push new one.
         Hence it has been inlined.  More call frames later get pushed on to stack
        (machine_crash_shutdown() and machine_kexec()), but one will not want to
        backtrace those.
      
      - Not very sure about the CFI annotations.  With this patch I am getting
        decent backtrace with gdb.  Assuming, compiler has generated enough
        debugging information for crash_kexec().  Coding crash_setup_regs() in pure
        assembly makes it tricky because then it can not be inlined and we don't
        want to return back after capturing register states we don't want to pop
        this call frame.
      
      - Saving the non-panicing cpus registers will be done in the NMI handler
        while shooting down them in machine_crash_shutdown.
      
      - Introducing CRASH_DUMP option in Kconfig for x86_64.
      Signed-off-by: NMurali M Chakravarthy <muralim@in.ibm.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ec9ce0db
  17. 09 1月, 2006 1 次提交
  18. 15 11月, 2005 3 次提交
  19. 07 11月, 2005 1 次提交
  20. 22 9月, 2005 1 次提交
  21. 15 9月, 2005 1 次提交
    • D
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      David S. Miller 提交于
      Several implementations were essentialy a common piece of C code using
      the cmpxchg() macro.  Put the implementation in one spot that everyone
      can share, and convert sparc64 over to using this.
      
      Alpha is the lone arch-specific implementation, which codes up a
      special fast path for the common case in order to avoid GP reloading
      which a pure C version would require.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4db2ce01