Skip to content

L
linux-davinci-2.6.23
Switch branch/tag
  1. 14 Nov, 2006 8 commits
    • Andi Kleen's avatar
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen authored 
      The vgetcpu per CPU initialization previously relied on CPU hotplug
events for all CPUs to initialize the per CPU state. That only
worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
others some CPUs didn't get their state initialized properly
and vgetcpu wouldn't work.

Change the initialization sequence to instead run in a normal
initcall (which runs after the normal CPU bootup) and initialize
all running CPUs there. Later hotplug CPUs are still handled
with an hotplug notifier.

This actually simplifies the code somewhat.
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      8c131af1
    • Andi Kleen's avatar
      [PATCH] x86: Add acpi_user_timer_override option for Asus boards · fa18f477
      Andi Kleen authored 
      Timer overrides are normally disabled on Nvidia board because
they are commonly wrong, except on new ones with HPET support.
Unfortunately there are quite some Asus boards around that
don't have HPET, but need a timer override.

We don't know yet how to handle this transparently,
but at least add a command line option to force the timer override
and let them boot.

Cc: len.brown@intel.com
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      fa18f477
    • Magnus Damm's avatar
      [PATCH] x86-64: setup saved_max_pfn correctly (kdump) · 15803a43
      Magnus Damm authored 
      x86_64: setup saved_max_pfn correctly

2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
to zero instead of the max_pfn value before the user map is setup.

This happens because saved_max_pfn is initialized at parse_early_param() time,
and at this time no active regions have been registered. save_max_pfn is setup
from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
returns 0 because no regions exist.

This patch fixes this by registering before and removing after the call
to e820_end_of_ram().
Signed-off-by: default avatarMagnus Damm <magnus@valinux.co.jp>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      15803a43
    • Andi Kleen's avatar
      [PATCH] x86-64: Handle reserve_bootmem_generic beyond end_pfn · 5e58a02a
      Andi Kleen authored 
      This can happen on kexec kernels with some configurations, in particularly
on Unisys ES7000 systems.

Analysis by Amul Shah

Cc: Amul Shah <amul.shah@unisys.com>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      5e58a02a
    • Steven Rostedt's avatar
      [PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says · 51d67a48
      Steven Rostedt authored 
      Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
nasty bug in Xen.  But it also pointed out a small bug in the x86_64
kernel boot setup.

The GDT limit being setup by the initial bzImage code when entering into
protected mode is way too big.  The comment by the code states that the
size of the GDT is 2048, but the actual size being set up is much bigger
(32768). This happens simply because of one extra '0'.

Instead of setting up a 0x800 size, 0x8000 is set up.  On bare metal this
is fine because the CPU wont load any segments unless  they are
explicitly used.  But unfortunately, this breaks Xen on vmx FV, since it
(for now) blindly loads all the segments into the VMCS if they are less
than the gdt limit. Since the real mode segments are around 0x3000, we are
getting junk into the VMCS and that later causes an exception.

Stephen Tweedie has written up a patch to fix the Xen side and will be
submitting that to those folks. But that doesn't excuse the GDT limit
being a magnitude too big.

AK: changed to compute true gdt size in assembler, fixed comment
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      51d67a48
    • Andi Kleen's avatar
      [PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation. · 14679eb3
      Andi Kleen authored 
      ptrace(PTRACE_[SG]ET_THREAD_AREA) calls from ia32 code
should be passed onto the x86_64 implementation.

The default case in sys32_ptrace used to call to sys_ptrace(), but is
now EINVAL.  This patch fixes a regression caused by that changed.
Signed-off-by: default avatarMike McCormack <mike@codeweavers.com>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      14679eb3
    • Aaron Durbin's avatar
      [PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable. · 14f448e3
      Aaron Durbin authored 
      Fix partial page check in e820_register_active_regions to ensure
partial pages are
not being marked as active in the memory pool.
Signed-off-by: default avatarAaron Durbin <adurbin@google.com>
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      14f448e3
    • Andi Kleen's avatar
      Revert "[PATCH] MMCONFIG and new Intel motherboards" · 64e72e41
      Andi Kleen authored 
      This reverts 4c6e052a commit.

Following Linus' i386 change: revert resource reservation
for mmcfg config now. Will be revisited in .20 hopefully.
      64e72e41
  3. 13 Nov, 2006 32 commits