1. 17 10月, 2007 3 次提交
  2. 13 10月, 2007 4 次提交
  3. 11 10月, 2007 2 次提交
  4. 22 9月, 2007 1 次提交
  5. 28 7月, 2007 1 次提交
    • T
      [IA64] Fix build failure in fs/quota.c · 7a6c8135
      Tony Luck 提交于
      b716395e added code to handle
      a compatability issue with 32bit quota tools, but the new compat
      routines are only needed when CONFIG_COMPAT=y (and with this set
      to 'n' there are compilation problems since some new typedefs are
      not visible).
      
      Reported by Doug Chapman.  Fix tuned by a cast of thousands (Andi,
      Andreas, Arthur, HPA, Willy)
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      7a6c8135
  6. 22 7月, 2007 2 次提交
  7. 18 7月, 2007 1 次提交
  8. 13 7月, 2007 1 次提交
  9. 24 5月, 2007 1 次提交
  10. 03 5月, 2007 4 次提交
  11. 17 2月, 2007 2 次提交
  12. 13 2月, 2007 2 次提交
  13. 12 2月, 2007 1 次提交
    • C
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter 提交于
      As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA
      channel management.  Other functionality may still expect GFP_DMA to
      provide memory below 16M.  So we need to make sure that CONFIG_ZONE_DMA is
      set independent of CONFIG_GENERIC_ISA_DMA.  Undo the modifications to
      mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set
      theses explicitly in each arches Kconfig.
      
      Reviews must occur for each arch in order to determine if ZONE_DMA can be
      switched off.  It can only be switched off if we know that all devices
      supported by a platform are capable of performing DMA transfers to all of
      memory (Some arches already support this: uml, avr32, sh sh64, parisc and
      IA64/Altix).
      
      In order to switch ZONE_DMA off conditionally, one would have to establish
      a scheme by which one can assure that no drivers are enabled that are only
      capable of doing I/O to a part of memory, or one needs to provide an
      alternate means of performing an allocation from a specific range of memory
      (like provided by alloc_pages_range()) and insure that all drivers use that
      call.  In that case the arches alloc_dma_coherent() may need to be modified
      to call alloc_pages_range() instead of relying on GFP_DMA.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ac6da66
  14. 02 1月, 2007 1 次提交
  15. 21 12月, 2006 1 次提交
    • I
      [PATCH] x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY_DEFAULT · a9622f62
      Ingo Molnar 提交于
      one of my boxes didnt boot the 2.6.20-rc1-rt0 kernel rpm, it hung during
      early bootup. After an hour or two of happy debugging i narrowed it down
      to the CALGARY_IOMMU_ENABLED_BY_DEFAULT option, which was freshly added
      to 2.6.20 via the x86_64 tree and /enabled by default/.
      
      commit bff6547b claims:
      
          [PATCH] Calgary: allow compiling Calgary in but not using it by default
      
          This patch makes it possible to compile Calgary in but not use it by
          default. In this mode, use 'iommu=calgary' to activate it.
      
      but the change does not actually practice it:
      
       config CALGARY_IOMMU_ENABLED_BY_DEFAULT
              bool "Should Calgary be enabled by default?"
              default y
              depends on CALGARY_IOMMU
              help
                Should Calgary be enabled by default? if you choose 'y', Calgary
                will be used (if it exists). If you choose 'n', Calgary will not be
                used even if it exists. If you choose 'n' and would like to use
                Calgary anyway, pass 'iommu=calgary' on the kernel command line.
                If unsure, say Y.
      
      it's both 'default y', and says "If unsure, say Y". Clearly not a typo.
      
      disabling this option makes my box boot again. The patch below fixes the
      Kconfig entry. Grumble.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9622f62
  16. 12 12月, 2006 1 次提交
  17. 09 12月, 2006 2 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
    • J
      [PATCH] Generic BUG for x86-64 · c31a0bf3
      Jeremy Fitzhardinge 提交于
      This makes x86-64 use the generic BUG machinery.
      
      The main advantage in using the generic BUG machinery for x86-64 is that
      the inlined overhead of BUG is just the ud2a instruction; the file+line
      information are no longer inlined into the instruction stream.  This
      reduces cache pollution.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c31a0bf3
  18. 07 12月, 2006 3 次提交
  19. 04 10月, 2006 1 次提交
  20. 02 10月, 2006 1 次提交
    • A
      [PATCH] Kprobes: Make kprobe modules more portable · 3a872d89
      Ananth N Mavinakayanahalli 提交于
      In an effort to make kprobe modules more portable, here is a patch that:
      
      o Introduces the "symbol_name" field to struct kprobe.
        The symbol->address resolution now happens in the kernel in an
        architecture agnostic manner. 64-bit powerpc users no longer have
        to specify the ".symbols"
      o Introduces the "offset" field to struct kprobe to allow a user to
        specify an offset into a symbol.
      o The legacy mechanism of specifying the kprobe.addr is still supported.
        However, if both the kprobe.addr and kprobe.symbol_name are specified,
        probe registration fails with an -EINVAL.
      o The symbol resolution code uses kallsyms_lookup_name(). So
        CONFIG_KPROBES now depends on CONFIG_KALLSYMS
      o Apparantly kprobe modules were the only legitimate out-of-tree user of
        the kallsyms_lookup_name() EXPORT. Now that the symbol resolution
        happens in-kernel, remove the EXPORT as suggested by Christoph Hellwig
      o Modify tcp_probe.c that uses the kprobe interface so as to make it
        work on multiple platforms (in its earlier form, the code wouldn't
        work, say, on powerpc)
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3a872d89
  21. 01 10月, 2006 1 次提交
  22. 27 9月, 2006 3 次提交
  23. 26 9月, 2006 1 次提交