summaryrefslogtreecommitdiffstats
path: root/arch/i386/kernel/cpu/transmeta.c
Commit message (Collapse)AuthorAgeFilesLines
* i386: move kernel/cpuThomas Gleixner2007-10-111-116/+0
| | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* i386: cpu/transmeta.c: fix definition of USER686H. Peter Anvin2007-05-091-2/+4
| | | | | | | | | The definition of USER686 is supposed to be a mask of feature bits, not an OR of feature numbers! It happened to work anyway on the only processor affected, simply by pure coincidence. Fix. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] i386: Don't delete cpu_devs data to identify different x86 types in ↵Thomas Renninger2007-05-021-10/+0
| | | | | | | | | | | | | | | | | | | | | | late_initcall In arch/i386/cpu/common.c there is: cpu_devs[X86_VENDOR_INTEL] cpu_devs[X86_VENDOR_CYRIX] cpu_devs[X86_VENDOR_AMD] ... They are all filled with data early. The data (struct) got set to NULL for all, but Intel in different late_initcall (exit_cpu_vendor) calls. I don't see what sense this makes at all, maybe something that got forgotten with the HOTPLUG_CPU extenstions? Please check/review whether initdata, cpuinitdata is still ok and this still works with HOTPLUG_CPU and without, it should... Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Cc: davej@redhat.com
* [PATCH] i386: Fix warning in cpu initializationAndi Kleen2007-02-131-1/+1
| | | | | | | | Fix bogus warning linux/arch/i386/kernel/cpu/transmeta.c:12: warning: ‘cpu_freq’ may be used uninitialized in this function Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] i386: All Transmeta CPUs have constant TSCsH. Peter Anvin2007-02-131-0/+3
| | | | | | | | | All Transmeta CPUs ever produced have constant-rate TSCs. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
* [PATCH] i386: mark cpu identify functions as __cpuinitMagnus Damm2006-09-261-1/+1
| | | | | | | | | 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>
* [PATCH] i386: mark cpu init functions as __cpuinit, data as __cpuinitdataMagnus Damm2006-09-261-1/+1
| | | | | | | | | 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>
* [PATCH] i386: mark cpu_dev structures as __cpuinitdataMagnus Damm2006-09-261-1/+1
| | | | | | | | | | 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>
* [PATCH] i386: remove redundant generic_identify() calls when identifying cpusMagnus Damm2006-09-261-1/+0
| | | | | | | | | | | | | 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>
* [PATCH] x86_64: Add boot option to disable randomized mappings and cleanupAndi Kleen2006-02-171-0/+1
| | | | | | | | | | | | | 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>
* [PATCH] i386 cpu hotplug: don't access freed memoryChuck Ebbert2006-02-051-1/+9
| | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] transmeta: CONFIG_PROC_FS=n build fixAndrew Morton2005-08-011-0/+2
| | | | | | | 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>
* [PATCH] disable addres space randomization default on transmeta CPUsEric Lammerts2005-08-011-0/+4
| | | | | | | | | | | | 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>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+107
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!
OpenPOWER on IntegriCloud