1. 14 Aug, 2008 5 commits
    • Thomas Gleixner's avatar
      x86: hpet: workaround SB700 BIOS · a6825f1c
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      a6825f1c
    • Yinghai Lu's avatar
      x86: check bigsmp in smp_sanity_check instead of cpu_up · a58f03b0
      Yinghai Lu authored
      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: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Tested-by: default avatarJeff Chua <jeff.chua.linux@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a58f03b0
    • Yinghai Lu's avatar
      x86: don't call e820_regiter_active_regions if out of range on node · 858f7747
      Yinghai Lu authored
      so we don't get warning on 32bit system with 64g RAM or more
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      858f7747
    • Max Krasnyansky's avatar
      x86: resurrect proper handling of maxcpus= kernel option (v2) · 23b49c19
      Max Krasnyansky authored
      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: default avatarMax Krasnyansky <maxk@qualcomm.com>
      Cc: lizf@cn.fujitsu.com
      Cc: jeff.chua.linux@gmail.com
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      23b49c19
    • Ingo Molnar's avatar
      Merge branch 'x86/fpu' into x86/urgent · 31677619
      Ingo Molnar authored
      31677619
  2. 13 Aug, 2008 9 commits
  3. 12 Aug, 2008 26 commits