Commit Graph

558 Commits

Author SHA1 Message Date
Siddha, Suresh B
cf94b62f70 [PATCH] x86_64-always-use-cpuid-80000008-to-figure-out-mtrr fix
We need to use the size_and_mask in set_mtrr_var_ranges(which is called
while programming MTRR's for AP's

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:11 -07:00
Andi Kleen
1f2c958ad5 [PATCH] x86_64: Always use CPUID 80000008 to figure out MTRR address space size
It doesn't make sense to only do this only for AMD K8.

This would support future CPUs with extended address spaces properly.

For i386 and x86-64

Cc: <davej@redhat.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:25:10 -07:00
Jason Davis
90660ec3c3 [PATCH] x86_64 genapic update
x86_64 genapic mechanism should be aware of machines that use physical APIC
mode regardless of how many clusters/processors are detected.

ACPI 3.0 FADT makes this determination very simple by providing a feature
flag "force_apic_physical_destination_mode" to state whether the machine
unconditionally uses physical APIC mode.

Unisys' next generation x86_64 ES7000 will need to utilize this FADT
feature flag in order to boot the x86_64 kernel in the correct APIC mode. 
This patch has been tested on both x86_64 commodity and ES7000 boxes.

Signed-off-by: Jason Davis <jason.davis@unisys.com>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:53 -07:00
Andi Kleen
db46868128 [PATCH] x86-64/i386: Revert cpuinfo siblings behaviour back to 2.6.10
Only display physical id/siblings when there are siblings or dual core.

In 2.6.11 I accidentially broke it and it was always displaying these
fields But for compatibility to all these /proc parsers around it is better
to do it in the old way again.  

Noticed by Suresh Siddha

Cc: <Suresh.b.siddha@intel.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:51 -07:00
Roland McGrath
c97db4a0a7 [PATCH] i386 vDSO: add PT_NOTE segment
This patch adds an ELF note to the vDSO giving the LINUX_VERSION_CODE
value.  Having this in the vDSO lets the dynamic linker avoid the `uname'
syscall it now always does at startup to ascertain the kernel ABI
available.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:48 -07:00
Roland McGrath
ecd02dddd1 [PATCH] i386: Use loaddebug macro consistently
This moves the macro loaddebug from asm-i386/suspend.h to
asm-i386/processor.h, which is the place that makes sense for it to be
defined, removes the extra copy of the same macro in
arch/i386/kernel/process.c, and makes arch/i386/kernel/signal.c use the
macro in place of its expansion.

This is a purely cosmetic cleanup for the normal i386 kernel.  However, it
is handy for Xen to be able to just redefine the loaddebug macro once
instead of also changing the signal.c code.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:46 -07:00
Stas Sergeev
5df240826c [PATCH] fix crash in entry.S restore_all
Fix the access-above-bottom-of-stack crash.

1. Allows to preserve the valueable optimization

2. Works for NMIs

3.  Doesn't care whether or not there are more of the like instances
   where the stack is left empty.

4. Seems to work for me without the crashes:) 

(akpm: this is still under discussion, although I _think_ it's OK.  You might
want to hold off)

Signed-off-by: Stas Sergeev <stsp@aknet.ru> 
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:01 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00