1. 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
  2. 21 7月, 2007 1 次提交
  3. 18 7月, 2007 1 次提交
  4. 12 7月, 2007 1 次提交
  5. 12 5月, 2007 1 次提交
  6. 09 5月, 2007 1 次提交
  7. 03 5月, 2007 1 次提交
  8. 20 3月, 2007 1 次提交
    • L
      ACPI: IA64: fix allnoconfig build · 8140a90e
      Len Brown 提交于
      The evils of Kconfig's select bite us once again...
      ia64/Kconfig selects ACPI, which depends on PM.
      But select ignores dependencies, allnoconfig
      chooses CONFIG_PM=n, and thus the menu of sub-options
      under ACPI vanish, which breaks the build.
      
      Manually select PM along with ACPI for now.
      Some day, we should delete them both, or fix select.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8140a90e
  9. 16 2月, 2007 1 次提交
  10. 12 2月, 2007 2 次提交
  11. 06 2月, 2007 2 次提交
  12. 30 1月, 2007 1 次提交
  13. 09 12月, 2006 1 次提交
    • 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
  14. 08 12月, 2006 1 次提交
    • Z
      [IA64] IA64 Kexec/kdump · a7956113
      Zou Nan hai 提交于
      Changes and updates.
      
      1. Remove fake rendz path and related code according to discuss with Khalid Aziz.
      2. fc.i offset fix in relocate_kernel.S.
      3. iospic shutdown code eoi and mask race fix from Fujitsu.
      4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner.
      5. Send slave to SAL slave loop patch from Jay Lan.
      6. Kdump on non-recoverable MCA event patch from Jay Lan
      7. Use CTL_UNNUMBERED in kdump_on_init sysctl.
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a7956113
  15. 13 11月, 2006 1 次提交
    • J
      [PATCH] mspec driver build fix · 1a4b0fc5
      Jes Sorensen 提交于
      Fix MSPEC driver to build for non SN2 enabled configs as the driver should
      work in cached and uncached modes (no fetchop) on these systems.  In
      addition make MSPEC select IA64_UNCACHED_ALLOCATOR, which is required for
      it and move it to arch/ia64/Kconfig to avoid warnings on non ia64
      architectures running allmodconfig.  Once the Kconfig code is fixed, we can
      move it back.
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Cc: Fernando Luis Vzquez Cao <fernando@oss.ntt.co.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1a4b0fc5
  16. 09 11月, 2006 1 次提交
  17. 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
  18. 27 9月, 2006 1 次提交
  19. 26 9月, 2006 1 次提交
  20. 12 9月, 2006 1 次提交
  21. 30 8月, 2006 1 次提交
  22. 01 7月, 2006 1 次提交
    • C
      [PATCH] zoned vm counters: basic ZVC (zoned vm counter) implementation · 2244b95a
      Christoph Lameter 提交于
      Per zone counter infrastructure
      
      The counters that we currently have for the VM are split per processor.  The
      processor however has not much to do with the zone these pages belong to.  We
      cannot tell f.e.  how many ZONE_DMA pages are dirty.
      
      So we are blind to potentially inbalances in the usage of memory in various
      zones.  F.e.  in a NUMA system we cannot tell how many pages are dirty on a
      particular node.  If we knew then we could put measures into the VM to balance
      the use of memory between different zones and different nodes in a NUMA
      system.  For example it would be possible to limit the dirty pages per node so
      that fast local memory is kept available even if a process is dirtying huge
      amounts of pages.
      
      Another example is zone reclaim.  We do not know how many unmapped pages exist
      per zone.  So we just have to try to reclaim.  If it is not working then we
      pause and try again later.  It would be better if we knew when it makes sense
      to reclaim unmapped pages from a zone.  This patchset allows the determination
      of the number of unmapped pages per zone.  We can remove the zone reclaim
      interval with the counters introduced here.
      
      Futhermore the ability to have various usage statistics available will allow
      the development of new NUMA balancing algorithms that may be able to improve
      the decision making in the scheduler of when to move a process to another node
      and hopefully will also enable automatic page migration through a user space
      program that can analyse the memory load distribution and then rebalance
      memory use in order to increase performance.
      
      The counter framework here implements differential counters for each processor
      in struct zone.  The differential counters are consolidated when a threshold
      is exceeded (like done in the current implementation for nr_pageache), when
      slab reaping occurs or when a consolidation function is called.
      
      Consolidation uses atomic operations and accumulates counters per zone in the
      zone structure and also globally in the vm_stat array.  VM functions can
      access the counts by simply indexing a global or zone specific array.
      
      The arrangement of counters in an array also simplifies processing when output
      has to be generated for /proc/*.
      
      Counters can be updated by calling inc/dec_zone_page_state or
      _inc/dec_zone_page_state analogous to *_page_state.  The second group of
      functions can be called if it is known that interrupts are disabled.
      
      Special optimized increment and decrement functions are provided.  These can
      avoid certain checks and use increment or decrement instructions that an
      architecture may provide.
      
      We also add a new CONFIG_DMA_IS_NORMAL that signifies that an architecture can
      do DMA to all memory and therefore ZONE_NORMAL will not be populated.  This is
      only currently set for IA64 SGI SN2 and currently only affects
      node_page_state().  In the best case node_page_state can be reduced to
      retrieving a single counter for the one zone on the node.
      
      [akpm@osdl.org: cleanups]
      [akpm@osdl.org: export vm_stat[] for filesystems]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2244b95a
  23. 30 6月, 2006 2 次提交
  24. 28 6月, 2006 1 次提交
  25. 23 6月, 2006 1 次提交
  26. 22 6月, 2006 2 次提交
    • K
      [IA64] Make PCI Express support selectable · b7bb575c
      Kenji Kaneshige 提交于
      When I tried to use PCI Express Hotplug driver on my ia64 box, I
      noticed that "PCI Express support" is not even selectable on ia64.
      This patch makes PCI Express support selectable.
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      b7bb575c
    • D
      [IA64] esi-support · 2ab561a1
      David Mosberger-Tang 提交于
      Add support for making ESI calls [1].  ESI stands for "Extensible SAL
      specification" and is basically a way for invoking firmware
      subroutines which are identified by a GUID.  I don't know whether ESI
      is used by vendors other than HP (if you do, please let me know) but
      as firmware "backdoors" go, this seems one of the cleaner methods, so
      it seems reasonable to support it, even though I'm not aware of any
      publicly documented ESI calls.  I'd have liked to make the ESI module
      completely stand-alone, but unfortunately that is not easily (or not
      at all) possible because in order to make ESI calls in physical mode,
      a small stub similar to the EFI stub is needed in the kernel proper.
      I did try to create a stub that would work in user-level, but it
      quickly got ugly beyond recognition (e.g., the stub had to make
      assumptions about how the module-loader generated call-stubs work) and
      I didn't even get it to work (that's probably fixable, but I didn't
      bother because I concluded it was too ugly anyhow).  While it's not
      terribly elegant to have kernel code which isn't actively used in the
      kernel proper, I think it might be worth making an exception here for
      two reasons: the code is trivially small (all that's really needed is
      esi_stub.S) and by including it in the normal kernel distro, it might
      encourage other OEMs to also use ESI, which I think would be far
      better than each inventing their own firmware "backdoor".
      
      The code was originally written by Alex.  I just massaged and packaged
      it a bit (and perhaps messed up some things along the way...).
      
      Changes since first version of patch that was posted to mailing list:
      * Export ia64_esi_call and ia64_esi_call_phys() as GPL symbols.
      * Disallow building esi.c as a module for now.  Building as a module
        would currently lead to an unresolved reference to "sal_lock" on SMP kernels
        because that symbol doesn't get exported.
      * Export esi_call_phys() only if ESI is enabled.
      * Remove internal stuff from esi.h and add a "proc_type" argument to
        ia64_esi_call() such that serialization-requirements can be expressed (ESI
        follows SAL here, where procedure calls may have to be serialized, are
        MP-safe, or MP-safe andr reentrant).
      
      [1] h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,919,00.html
      Signed-off-by: NDavid Mosberger <David.Mosberger@acm.org>
      Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      2ab561a1
  27. 22 4月, 2006 1 次提交
  28. 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
  29. 02 4月, 2006 1 次提交
  30. 27 3月, 2006 2 次提交
    • A
      [PATCH] bitops: ia64: use generic bitops · 2875aef8
      Akinobu Mita 提交于
      - remove generic_fls64()
      - remove find_{next,first}{,_zero}_bit()
      - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
      - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
      - remove sched_find_first_bit()
      Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2875aef8
    • M
      [PATCH] ia64: use i386 dmi_scan.c · 3ed3bce8
      Matt Domsch 提交于
      Enable DMI table parsing on ia64.
      
      Andi Kleen has a patch in his x86_64 tree which enables the use of i386
      dmi_scan.c on x86_64.  dmi_scan.c functions are being used by the
      drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or
      memory spaces where the IPMI controllers may be found.
      
      This patch adds equivalent changes for ia64 as to what is in the x86_64
      tree.  In addition, I reworked the DMI detection, such that on EFI-capable
      systems, it uses the efi.smbios pointer to find the table, rather than
      brute-force searching from 0xF0000.  On non-EFI systems, it continues the
      brute-force search.
      
      My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with
      latest BIOS, does not list the IPMI controller in the ACPI namespace, nor
      does it have an ACPI SPMI table.  Also note, currently shipping Dell x8xx
      EM64T servers don't have these either, so DMI is the only method for
      obtaining the address of the IPMI controller.
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Acked-by: N"Luck, Tony" <tony.luck@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3ed3bce8
  31. 25 3月, 2006 1 次提交
  32. 27 2月, 2006 1 次提交
  33. 03 2月, 2006 1 次提交
  34. 27 1月, 2006 1 次提交
  35. 06 1月, 2006 1 次提交
    • A
      [IA64] support for cpu0 removal · ff741906
      Ashok Raj 提交于
      here is the BSP removal support for IA64. Its pretty much the same thing that
      was released a while back, but has your feedback incorporated.
      
      - Removed CONFIG_BSP_REMOVE_WORKAROUND and associated cmdline param
      - Fixed compile issue with sn2/zx1 due to a undefined fix_b0_for_bsp
      - some formatting nits (whitespace etc)
      
      This has been tested on tiger and long back by alex on hp systems as well.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      ff741906