An error occurred fetching the project authors.
  1. 08 Jul, 2008 7 commits
    • Bernhard Walle's avatar
      x86, crashdump, /proc/vmcore: remove CONFIG_EXPERIMENTAL from kdump · 383bc5ce
      Bernhard Walle authored
      I would suggest to remove the "experimental" status from Kdump.
      Kdump is now in the kernel since a long time and used by Enterprise
      distributions. I don't think that "experimental" is true any more.
      Signed-off-by: default avatarBernhard Walle <bwalle@suse.de>
      Cc: vgoyal@redhat.com
      Cc: kexec@lists.infradead.org
      Cc: Bernhard Walle <bwalle@suse.de>
      Cc: akpm@linux-foundation.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      383bc5ce
    • Mike Travis's avatar
      x86: cleanup early per cpu variables/accesses v4 · 23ca4bba
      Mike Travis authored
        * Introduce a new PER_CPU macro called "EARLY_PER_CPU".  This is
          used by some per_cpu variables that are initialized and accessed
          before there are per_cpu areas allocated.
      
          ["Early" in respect to per_cpu variables is "earlier than the per_cpu
          areas have been setup".]
      
          This patchset adds these new macros:
      
      	DEFINE_EARLY_PER_CPU(_type, _name, _initvalue)
      	EXPORT_EARLY_PER_CPU_SYMBOL(_name)
      	DECLARE_EARLY_PER_CPU(_type, _name)
      
      	early_per_cpu_ptr(_name)
      	early_per_cpu_map(_name, _idx)
      	early_per_cpu(_name, _cpu)
      
          The DEFINE macro defines the per_cpu variable as well as the early
          map and pointer.  It also initializes the per_cpu variable and map
          elements to "_initvalue".  The early_* macros provide access to
          the initial map (usually setup during system init) and the early
          pointer.  This pointer is initialized to point to the early map
          but is then NULL'ed when the actual per_cpu areas are setup.  After
          that the per_cpu variable is the correct access to the variable.
      
          The early_per_cpu() macro is not very efficient but does show how to
          access the variable if you have a function that can be called both
          "early" and "late".  It tests the early ptr to be NULL, and if not
          then it's still valid.  Otherwise, the per_cpu variable is used
          instead:
      
      	#define early_per_cpu(_name, _cpu) 			\
      		(early_per_cpu_ptr(_name) ?			\
      			early_per_cpu_ptr(_name)[_cpu] :	\
      			per_cpu(_name, _cpu))
      
          A better method is to actually check the pointer manually.  In the
          case below, numa_set_node can be called both "early" and "late":
      
      	void __cpuinit numa_set_node(int cpu, int node)
      	{
      	    int *cpu_to_node_map = early_per_cpu_ptr(x86_cpu_to_node_map);
      
      	    if (cpu_to_node_map)
      		    cpu_to_node_map[cpu] = node;
      	    else
      		    per_cpu(x86_cpu_to_node_map, cpu) = node;
      	}
      
        * Add a flag "arch_provides_topology_pointers" that indicates pointers
          to topology cpumask_t maps are available.  Otherwise, use the function
          returning the cpumask_t value.  This is useful if cpumask_t set size
          is very large to avoid copying data on to/off of the stack.
      
        * The coverage of CONFIG_DEBUG_PER_CPU_MAPS has been increased while
          the non-debug case has been optimized a bit.
      
        * Remove an unreferenced compiler warning in drivers/base/topology.c
      
        * Clean up #ifdef in setup.c
      
      For inclusion into sched-devel/latest tree.
      
      Based on:
      	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
          +   sched-devel/latest  .../mingo/linux-2.6-sched-devel.git
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      23ca4bba
    • Mike Travis's avatar
      x86: modify Kconfig to allow up to 4096 cpus · 1184dc2f
      Mike Travis authored
        * Increase the limit of NR_CPUS to 4096 and introduce a boolean
          called "MAXSMP" which when set (e.g. "allyesconfig"), will set
          NR_CPUS = 4096 and NODES_SHIFT = 9 (512).
      
        * Changed max setting for NODES_SHIFT from 15 to 9 to accurately
          reflect the real limit.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      1184dc2f
    • Yinghai Lu's avatar
      x86: simplify x86_mpparse dependency check · bad48f4b
      Yinghai Lu authored
      "Maciej W. Rozycki" <macro@linux-mips.org> said:
      
      > Given X86_64 selects X86_LOCAL_APIC I am not sure the redundancy seen
      >above does not actually obscure the logic behind...  I think:
      >
      >       depends on X86_LOCAL_APIC && !X86_VISWS
      >
      >would be clearer and get the same.
      Suggested-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      bad48f4b
    • Yinghai Lu's avatar
      x86: fix compiling when CONFIG_X86_MPPARSE is not set · a4caa18e
      Yinghai Lu authored
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a4caa18e
    • Yinghai Lu's avatar
      x86: let MPS support be selectable, v2 · 6695c85b
      Yinghai Lu authored
      v2: seperate "fix for compiling when MPPARSE is not set" to another patch
          make X86_MPPARSE to be selectable only when acpi is set and
          X86_MPPARSE will be set if acpi is not set.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6695c85b
    • Yinghai Lu's avatar
      x86: Kconfig cleanup with genericarch · 0699eae1
      Yinghai Lu authored
      we already have summit and etc depends on genericarch,
      so use genericarch only.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0699eae1
  2. 04 Jul, 2008 1 commit
  3. 01 Jul, 2008 1 commit
  4. 27 Jun, 2008 3 commits
    • Ingo Molnar's avatar
      x86, AMD IOMMU: build fix #3 · 07c40e8a
      Ingo Molnar authored
      fix typo causing:
      
      arch/x86/kernel/built-in.o: In function `__unmap_single':
      amd_iommu.c:(.text+0x17771): undefined reference to `iommu_area_free'
      arch/x86/kernel/built-in.o: In function `__map_single':
      amd_iommu.c:(.text+0x1797a): undefined reference to `iommu_area_alloc'
      amd_iommu.c:(.text+0x179a2): undefined reference to `iommu_area_alloc'
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      07c40e8a
    • Ingo Molnar's avatar
      x86, AMD IOMMU: build fix · 24d2ba0a
      Ingo Molnar authored
      fix:
      
       arch/x86/kernel/amd_iommu_init.c:247: warning: 'struct acpi_table_header' declared inside parameter list
       arch/x86/kernel/amd_iommu_init.c:247: warning: its scope is only this definition or declaration, which is probably not what you want
       arch/x86/kernel/amd_iommu_init.c: In function 'find_last_devid_acpi':
       arch/x86/kernel/amd_iommu_init.c:257: error: dereferencing pointer to incomplete type
       arch/x86/kernel/amd_iommu_init.c:265: error: dereferencing pointer to incomplete type
      
      the AMD IOMMU code depends on ACPI facilities.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      24d2ba0a
    • Joerg Roedel's avatar
      x86, AMD IOMMU: add Kconfig entry · 2b188723
      Joerg Roedel authored
      This patch adds the Kconfig entry for the AMD IOMMU driver.
      Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: bhavna.sarathy@amd.com
      Cc: Sebastian.Biemueller@amd.com
      Cc: robert.richter@amd.com
      Cc: joro@8bytes.org
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2b188723
  5. 24 Jun, 2008 2 commits
  6. 10 Jun, 2008 1 commit
  7. 05 Jun, 2008 1 commit
    • Andres Salomon's avatar
      PCI/x86: fix up PCI stuff so that PCI_GOANY supports OLPC · 2bdd1b03
      Andres Salomon authored
      Previously, one would have to specifically choose CONFIG_OLPC and
      CONFIG_PCI_GOOLPC in order to enable PCI_OLPC.  That doesn't really work
      for distro kernels, so this patch allows one to choose CONFIG_OLPC and
      CONFIG_PCI_GOANY in order to build in OLPC support in a generic kernel (as
      requested by Robert Millan).
      
      This also moves GOOLPC before GOANY in the menuconfig list.
      
      Finally, make pci_access_init return early if we detect OLPC hardware.
      There's no need to continue probing stuff, and pci_pcbios_init
      specifically trashes our settings (we didn't run into that before because
      PCI_GOANY wasn't supported).
      Signed-off-by: default avatarAndres Salomon <dilinger@debian.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      2bdd1b03
  8. 25 May, 2008 6 commits
  9. 22 May, 2008 1 commit
  10. 12 May, 2008 1 commit
  11. 10 May, 2008 1 commit
  12. 08 May, 2008 1 commit
  13. 05 May, 2008 1 commit
  14. 04 May, 2008 1 commit
  15. 30 Apr, 2008 2 commits
    • Sam Ravnborg's avatar
      x86: use defconfigs from x86/configs/* · b9b39bfb
      Sam Ravnborg authored
      Daniel Drake <dsd@gentoo.org> reported:
      
      In 2.6.23, if you unpacked a kernel source tarball and then
      ran "make menuconfig" you'd be presented with this message:
          # using defaults found in arch/i386/defconfig
      
      and the default options would be set.
      
      The same thing in 2.6.24 does not give you any "using defaults" message, and
      the default config options within menuconfig are rather blank (e.g. no PCI
      support). You can work around this by explicitly running "make defconfig"
      before menuconfig, but it would be nice to have the behaviour the way it was
      for 2.6.23 (and the way it still is for other archs).
      
      Fixed by adding a x86 specific defconfig list to Kconfig.
      
      Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10470
      Tested-by: dsd@gentoo.org
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      b9b39bfb
    • Ingo Molnar's avatar
      x86 VISWS: build fix · 3e8f7e35
      Ingo Molnar authored
      the 'reboot_force' flag is a notion that non-PC subarchitectures do
      not have.
      
      also, unify the X86_BIOS_REBOOT option between 32-bit and 64-bit
      and get rid of a few unnecessary Kconfig and Makefile complications
      that way.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      3e8f7e35
  16. 29 Apr, 2008 2 commits
  17. 28 Apr, 2008 2 commits
  18. 27 Apr, 2008 2 commits
  19. 26 Apr, 2008 4 commits
    • Alexander van Heukelum's avatar
      x86, bitops: select the generic bitmap search functions · 19870def
      Alexander van Heukelum authored
      Introduce GENERIC_FIND_FIRST_BIT and GENERIC_FIND_NEXT_BIT in
      lib/Kconfig, defaulting to off. An arch that wants to use the
      generic implementation now only has to use a select statement
      to include them.
      
      I added an always-y option (X86_CPU) to arch/x86/Kconfig.cpu
      and used that to select the generic search functions. This
      way ARCH=um SUBARCH=i386 automatically picks up the change
      too, and arch/um/Kconfig.i386 can therefore be simplified a
      bit. ARCH=um SUBARCH=x86_64 does things differently, but
      still compiles fine. It seems that a "def_bool y" always
      wins over a "def_bool n"?
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      19870def
    • Alexander van Heukelum's avatar
      x86: switch 64-bit to generic find_first_bit · 2aba6925
      Alexander van Heukelum authored
      Switch x86_64 to generic find_first_bit. The x86_64-specific
      implementation is not removed.
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2aba6925
    • Alexander van Heukelum's avatar
      x86: generic versions of find_first_(zero_)bit, convert i386 · 77b9bd9c
      Alexander van Heukelum authored
      Generic versions of __find_first_bit and __find_first_zero_bit
      are introduced as simplified versions of __find_next_bit and
      __find_next_zero_bit. Their compilation and use are guarded by
      a new config variable GENERIC_FIND_FIRST_BIT.
      
      The generic versions of find_first_bit and find_first_zero_bit
      are implemented in terms of the newly introduced __find_first_bit
      and __find_first_zero_bit.
      
      This patch does not remove the i386-specific implementation,
      but it does switch i386 to use the generic functions by setting
      GENERIC_FIND_FIRST_BIT=y for X86_32.
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      77b9bd9c
    • Alexander van Heukelum's avatar
      x86: change x86 to use generic find_next_bit · 6fd92b63
      Alexander van Heukelum authored
      The versions with inline assembly are in fact slower on the machines I
      tested them on (in userspace) (Athlon XP 2800+, p4-like Xeon 2.8GHz, AMD
      Opteron 270). The i386-version needed a fix similar to 06024f21 to avoid
      crashing the benchmark.
      
      Benchmark using: gcc -fomit-frame-pointer -Os. For each bitmap size
      1...512, for each possible bitmap with one bit set, for each possible
      offset: find the position of the first bit starting at offset. If you
      follow ;). Times include setup of the bitmap and checking of the
      results.
      
      		Athlon		Xeon		Opteron 32/64bit
      x86-specific:	0m3.692s	0m2.820s	0m3.196s / 0m2.480s
      generic:	0m2.622s	0m1.662s	0m2.100s / 0m1.572s
      
      If the bitmap size is not a multiple of BITS_PER_LONG, and no set
      (cleared) bit is found, find_next_bit (find_next_zero_bit) returns a
      value outside of the range [0, size]. The generic version always returns
      exactly size. The generic version also uses unsigned long everywhere,
      while the x86 versions use a mishmash of int, unsigned (int), long and
      unsigned long.
      
      Using the generic version does give a slightly bigger kernel, though.
      
      defconfig:	   text    data     bss     dec     hex filename
      x86-specific:	4738555  481232  626688 5846475  5935cb vmlinux (32 bit)
      generic:	4738621  481232  626688 5846541  59360d vmlinux (32 bit)
      x86-specific:	5392395  846568  724424 6963387  6a40bb vmlinux (64 bit)
      generic:	5392458  846568  724424 6963450  6a40fa vmlinux (64 bit)
      Signed-off-by: default avatarAlexander van Heukelum <heukelum@fastmail.fm>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6fd92b63