Commit graph

9 commits

Author SHA1 Message Date
Magnus Damm
5f0f1c1666 [PATCH] i386: mark cpu identify functions as __cpuinit
Mark i386-specific cpu identification functions as __cpuinit. They are all
only called from arch/i386/common.c:identify_cpu() that already is marked as
__cpuinit.

Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:36 +02:00
Magnus Damm
b4af3f7cf1 [PATCH] i386: mark cpu init functions as __cpuinit, data as __cpuinitdata
Mark i386-specific cpu init functions as __cpuinit. They are all
only called from arch/i386/common.c:identify_cpu() that already is marked as
__cpuinit. This patch also removes the empty function init_umc().

Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:36 +02:00
Magnus Damm
9541493054 [PATCH] i386: mark cpu_dev structures as __cpuinitdata
The different cpu_dev structures are all used from __cpuinit callers what
I can tell. So mark them as __cpuinitdata instead of __initdata. I am a
little bit unsure about arch/i386/common.c:default_cpu, especially when it
comes to the purpose of this_cpu.

Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:36 +02:00
Magnus Damm
68bbc172cd [PATCH] i386: remove redundant generic_identify() calls when identifying cpus
cpu_dev->c_identify is only called from arch/i386/common.c:identify_cpu(), and
this after generic_identify() already has been called. There is no need to call
this function twice and hook it in c_identify - but I may be wrong, please
double check before applying.

This patch also removes generic_identify() from cpu.h to avoid unnecessary
future nesting.

Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-09-26 10:52:36 +02:00
Andi Kleen
a62eaf151d [PATCH] x86_64: Add boot option to disable randomized mappings and cleanup
AMD SimNow!'s JIT doesn't like them at all in the guest. For distribution
installation it's easiest if it's a boot time option.

Also I moved the variable to a more appropiate place and make
it independent from sysctl

And marked __read_mostly which it is.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-17 08:00:40 -08:00
Chuck Ebbert
fe38d8553c [PATCH] i386 cpu hotplug: don't access freed memory
i386 CPU init code accesses freed init memory when booting a newly-started
processor after CPU hotplug.  The cpu_devs array is searched to find the
vendor and it contains pointers to freed data.

Fix that by:

        1. Zeroing entries for freed vendor data after bootup.
        2. Changing Transmeta, NSC and UMC to all __init[data].
        3. Printing a warning (once only) and setting this_cpu
           to a safe default when the vendor is not found.

This does not change behavior for AMD systems.  They were broken already
but no error was reported.

Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-02-05 11:06:53 -08:00
Andrew Morton
39bbb07d7c [PATCH] transmeta: CONFIG_PROC_FS=n build fix
Fix bug found by Grant Coady <lkml@dodo.com.au>'s autobuild setup.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-01 21:38:00 -07:00
Eric Lammerts
cdf32eaa4e [PATCH] disable addres space randomization default on transmeta CPUs
We know that the randomisation slows down some workloads on Transmeta CPUs
by quite large amounts.  We think it's because the CPU needs to recode the
same x86 instructions when they pop up at a different virtual address after
a fork+exec.

So disable randomization by default on those CPUs.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-01 19:13:59 -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