1. 21 8月, 2008 3 次提交
  2. 20 8月, 2008 4 次提交
  3. 18 8月, 2008 8 次提交
    • A
      x86: fix build warnings in real mode code · 1b72691c
      Andi Kleen 提交于
      This recent patch
      
      commit c3965bd1
      Author: Paul Jackson <pj@sgi.com>
      Date:   Wed May 14 08:15:34 2008 -0700
      
          x86 boot: proper use of ARRAY_SIZE instead of repeated E820MAX constant
      
      caused these new warnings during a normal build:
      
      In file included from linux-2.6/arch/x86/boot/memory.c:17:
      linux-2.6/include/linux/log2.h: In function '__ilog2_u32':
      linux-2.6/include/linux/log2.h:34: warning: implicit declaration of function 'fls'
      linux-2.6/include/linux/log2.h: In function '__ilog2_u64':
      linux-2.6/include/linux/log2.h:42: warning: implicit declaration of function 'fls64'
      linux-2.6/include/linux/log2.h: In function '__roundup_pow_of_two ':
      linux-2.6/include/linux/log2.h:63: warning: implicit declaration of function 'fls_long'
      
      I tried to fix them in log2.h, but it's difficult because the real mode
      environment is completely different from a normal kernel environment. Instead
      define an own ARRAY_SIZE macro in boot.h, similar to the other private
      macros there.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1b72691c
    • M
      x86, calgary: fix section mismatch warning - get_tce_space_from_tar · f7106662
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x27032): Section mismatch in reference from the function get_tce_space_from_tar() to the function .init.text:calgary_bus_has_devices()
      The function get_tce_space_from_tar() references
      the function __init calgary_bus_has_devices().
      This is often because get_tce_space_from_tar lacks a __init
      annotation or the annotation of calgary_bus_has_devices is wrong.
      
      get_tce_space_from_tar is called only from __init function (calgary_init)
      and calls __init function (calgary_bus_has_devices).
      So annotate it properly.
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Chandru Siddalingappa <chandru@in.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f7106662
    • M
      x86: silence section mismatch warning - get_local_pda · d19fbfdf
      Marcin Slusarz 提交于
      Take out part of get_local_pda referencing __init function (free_bootmem)
      to new (static) function marked as __ref. It's safe to do because free_bootmem
      is called before __init sections are dropped.
      
      WARNING: vmlinux.o(.cpuinit.text+0x3cd7): Section mismatch in reference from the function get_local_pda() to the function .init.text:free_bootmem()
      The function __cpuinit get_local_pda() references
      a function __init free_bootmem().
      If free_bootmem is only used by get_local_pda then
      annotate free_bootmem with a matching annotation.
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Mike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d19fbfdf
    • D
      x86: fix i486 suspend to disk CR4 oops · e532c06f
      David Fries 提交于
      arch/x86/power/cpu_32.c __save_processor_state calls read_cr4()
      only a i486 CPU doesn't have the CR4 register.  Trying to read it
      produces an invalid opcode oops during suspend to disk.
      
      Use the safe rc4 reading op instead. If the value to be written is
      zero the write is skipped.
      
      arch/x86/power/hibernate_asm_32.S
      done: swapped the use of %eax and %ecx to use jecxz for
      the zero test and jump over store to %cr4.
      restore_image: s/%ecx/%eax/ to be consistent with done:
      
      In addition to __save_processor_state, acpi_save_state_mem,
      efi_call_phys_prelog, and efi_call_phys_epilog had checks added
      (acpi restore was in assembly and already had a check for
      non-zero).  There were other reads and writes of CR4, but MCE and
      virtualization shouldn't be executed on a i486 anyway.
      Signed-off-by: NDavid Fries <david@fries.net>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e532c06f
    • M
      x86: mpparse.c: fix section mismatch warning · 39e00fe2
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x118f7): Section mismatch in reference from the function construct_ioapic_table() to the function .init.text:MP_bus_info()
      The function construct_ioapic_table() references
      the function __init MP_bus_info().
      This is often because construct_ioapic_table lacks a __init
      annotation or the annotation of MP_bus_info is wrong.
      
      construct_ioapic_table is called only from construct_default_ISA_mptable which is __init
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39e00fe2
    • M
      x86: mmconf: fix section mismatch warning · c72a5efe
      Marcin Slusarz 提交于
      WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x1591): Section mismatch in reference from the function init_amd() to the function .init.text:check_enable_amd_mmconf_dmi()
      The function __cpuinit init_amd() references
      a function __init check_enable_amd_mmconf_dmi().
      If check_enable_amd_mmconf_dmi is only used by init_amd then
      annotate check_enable_amd_mmconf_dmi with a matching annotation.
      
      check_enable_amd_mmconf_dmi is only called from init_amd which is __cpuinit
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c72a5efe
    • M
      x86: fix MP_processor_info section mismatch warning · 67d0c9eb
      Marcin Slusarz 提交于
      WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x1fe7): Section mismatch in reference from the function MP_processor_info() to the variable .init.data:x86_quirks
      The function __cpuinit MP_processor_info() references
      a variable __initdata x86_quirks.
      If x86_quirks is only used by MP_processor_info then
      annotate x86_quirks with a matching annotation.
      
      MP_processor_info uses x86_quirks which is __init and is used only from
      smp_read_mpc and construct_default_ISA_mptable which are __init
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      67d0c9eb
    • M
      x86, tsc: fix section mismatch warning · d554d9a4
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x7950): Section mismatch in reference from the function native_calibrate_tsc() to the function .init.text:tsc_read_refs()
      The function native_calibrate_tsc() references
      the function __init tsc_read_refs().
      This is often because native_calibrate_tsc lacks a __init
      annotation or the annotation of tsc_read_refs is wrong.
      
      tsc_read_refs is called from native_calibrate_tsc which is not __init
      and native_calibrate_tsc cannot be marked __init
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d554d9a4
  4. 16 8月, 2008 3 次提交
    • M
      x86: fix section mismatch warning - spp_getpage() · 8d6ea967
      Marcin Slusarz 提交于
      WARNING: vmlinux.o(.text+0x17a3e): Section mismatch in reference from the function set_pte_vaddr_pud() to the function .init.text:spp_getpage()
      The function set_pte_vaddr_pud() references
      the function __init spp_getpage().
      This is often because set_pte_vaddr_pud lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      spp_getpage is called from __init (__init_extra_mapping) and
      non __init (set_pte_vaddr_pud) functions, so it can't be __init.
      Unfortunately it calls alloc_bootmem_pages which is __init,
      but does it only when bootmem allocator is available (after_bootmem == 0).
      
      So annotate it accordingly.
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: H. Peter Anvin <hpa@zytor.com>
      8d6ea967
    • A
      x86: change init_gdt to update the gdt via write_gdt, rather than a direct write. · fc0091b3
      Alex Nixon 提交于
      By writing directly, a memory access violation can occur whilst
      hotplugging a CPU if the entry was previously marked read-only.
      Signed-off-by: NAlex Nixon <alex.nixon@citrix.com>
      Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc0091b3
    • A
      x86: Fix ioremap off by one BUG · e213e877
      Andi Kleen 提交于
      Jean Delvare's machine triggered this BUG
      
      acpi_os_map_memory phys ffff0000 size 65535
      ------------[ cut here ]------------
      kernel BUG at arch/x86/mm/pat.c:233!
      
      with ACPI in the backtrace.
      
      Adding some debugging output showed that ACPI calls
      
      acpi_os_map_memory phys ffff0000 size 65535
      
      And ioremap/PAT does this check in 32bit, so addr+size wraps and the BUG
      in reserve_memtype() triggers incorrectly.
      
              BUG_ON(start >= end); /* end is exclusive */
      
      But reserve_memtype already uses u64:
      
      int reserve_memtype(u64 start, u64 end,
      
      so the 32bit truncation must happen in the caller. Presumably in ioremap
      when it passes this information to reserve_memtype().
      
      This patch does this computation in 64bit.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=11346Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      e213e877
  5. 15 8月, 2008 18 次提交
  6. 14 8月, 2008 4 次提交
    • T
      x86: hpet: workaround SB700 BIOS · a6825f1c
      Thomas Gleixner 提交于
      AMD SB700 based systems with spread spectrum enabled use a SMM based
      HPET emulation to provide proper frequency setting. The SMM code is
      initialized with the first HPET register access and takes some time to
      complete. During this time the config register reads 0xffffffff. We
      check for max. 1000 loops whether the config register reads a non
      0xffffffff value to make sure that HPET is up and running before we go
      further. A counting loop is safe, as the HPET access takes thousands
      of CPU cycles. On non SB700 based machines this check is only done
      once and has no side effects.
      
      Based on a quirk patch from: crane cai <crane.cai@amd.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      a6825f1c
    • Y
      x86: check bigsmp in smp_sanity_check instead of cpu_up · a58f03b0
      Yinghai Lu 提交于
      clear bits for cpu nr > 8.
      
      This allows us to boot the full range of possible CPUs that the
      supported APIC model will allow. Previously we'd hang or boot up
      with less than 8 CPUs.
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Tested-by: NJeff Chua <jeff.chua.linux@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a58f03b0
    • Y
      x86: don't call e820_regiter_active_regions if out of range on node · 858f7747
      Yinghai Lu 提交于
      so we don't get warning on 32bit system with 64g RAM or more
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      858f7747
    • M
      x86: resurrect proper handling of maxcpus= kernel option (v2) · 23b49c19
      Max Krasnyansky 提交于
      For some reason we had two parsers registered for maxcpus=. One in init/main.c
      and another in arch/x86/smpboot.c. So I nuked the one in arch/x86.
      
      Also 64-bit kernels used to handle maxcpus= as documented in
      Documentation/cpu-hotplug.txt. CPUs with 'id > maxcpus' are initialized
      but not booted. 32-bit version for some reason ignored them even though
      all the infrastructure for booting them later is there.
      
      In the current mainline both 64 and 32 bit versions are broken.
      This patch restores the correct behaviour. I've tested x86_64 version on
      4- and 8- way Core2 and 2-way Opteron based machines. Various config
      combinations SMP, !SMP, CPU_HOTPLUG, !CPU_HOTPLUG.
      Booted with maxcpus=1 and maxcpus=4, etc. Everything is working as expected.
      
      So far we've received two reports from different people confirming that 32-bit
      version also works fine, both on dual core laptops and 16way server machines.
      
      [v2: This version fixes visws breakage pointed out by Ingo.]
      Signed-off-by: NMax Krasnyansky <maxk@qualcomm.com>
      Cc: lizf@cn.fujitsu.com
      Cc: jeff.chua.linux@gmail.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      23b49c19