summaryrefslogtreecommitdiffstats
path: root/arch/i386/kernel/cpu/mtrr
Commit message (Collapse)AuthorAgeFilesLines
* i386: move kernel/cpu/mtrrThomas Gleixner2007-10-119-2621/+0Star
| | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.Juergen Beisert2007-07-222-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to index register access ordering problems, when using macros a line like this fails (and does nothing): setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); With inlined functions this line will work as expected. Note about a side effect: Seems on Geode GX1 based systems the "suspend on halt power saving feature" was never enabled due to this wrong macro expansion. With inlined functions it will be enabled, but this will stop the TSC when the CPU runs into a HLT instruction. Kernel output something like this: Clocksource tsc unstable (delta = -472746897 ns) This is the 3rd version of this patch. - Adding missed arch/i386/kernel/cpu/mtrr/state.c Thanks to Andres Salomon - Adding some big fat comments into the new header file Suggested by Andi Kleen AK: fixed x86-64 compilation Signed-off-by: Juergen Beisert <juergen@kreuzholzen.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: fix section mismatch warnings in mtrrSam Ravnborg2007-07-222-2/+2
| | | | | | | | | | | | | | | | | | | Following section mismatch warnings were reported by Andrey Borzenkov: WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:amd_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x967a) and 'mtrr_attrib_to_str' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:cyrix_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x967f) and 'mtrr_attrib_to_str' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:centaur_init_mtrr from .text between 'mtrr_bp_init' (at offset 0x9684) and 'mtrr_attrib_to_str' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa735) and 'generic_get_mtrr' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa749) and 'generic_get_mtrr' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'get_mtrr_state' (at offset 0xa770) and 'generic_get_mtrr' It was tracked down to a few functions missing __init tag. Compile tested only. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* MTRR: Fix race causing set_mtrr to go into infinite loopLoic Prylli2007-07-061-0/+4
| | | | | | | | | | | | | | Processors synchronization in set_mtrr requires the .gate field to be set after .count field is properly initialized. Without an explicit barrier, the compiler was reordering those memory stores. That was sometimes causing a processor (in ipi_handler) to see the .gate change and decrement .count before the latter is set by set_mtrr() (which then hangs in a infinite loop with irqs disabled). Signed-off-by: Loic Prylli <loic@myri.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: mtrr crash fixAndrew Morton2007-07-011-1/+2
| | | | | | | | | | | | Commit 3ebad5905609476a4ff1151a66b21d9794009961 ("[PATCH] x86: Save and restore the fixed-range MTRRs of the BSP when suspending") added mtrr operations without verifying that the CPU has MTRRs. Crashes transmeta CPUs. Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <linux@horizon.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: remove bogus mtrr range checkLinus Torvalds2007-07-011-5/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9215da33209b861b01c51382254b178a3fe92a30 "fixed" the MTRR range check to not allow any MTRR's under the 1MB mark (since that's where the fixed MTRR's are active). However, that was totally bogus, since it's normal (and almost required) to have a large variable MTRR that starts at 0, and covers some large percentage of the whole RAM, and then using the fixed MTRR's to override that large MTRR to handle the special ISA hole in the 640k-1M region. The old check was bogus too (checking that no variable MTRR is used that is entirely under the 1MB range), but at least it wasn't actively detrimental, because no sane situation would ever trigger such MTRR usage in the first place. That said, the whole notion of not allowing variable MTRR's in the low 1MB is just stupid, so rather than revert the commit, this just removes the whole sad and unnecessary check entirely. Cc: Jan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Tested-by: Luca Palermo <darkmage@sabayonlinux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mtrr/cyrix: fix sectionsRandy Dunlap2007-06-281-2/+2
| | | | | | | | | | | | | | | | | | | main.c::mtrr_add() or mtrr_del() [exported] calls main.c::mtrr_add_page() or mtrr_del_page() or mtrr_restore() [resume] calls main.c::set_mtrr() calls main.c::ipi_handler() calls main.c::mtrr_if->set_all() == which can be cyrix_set_all WARNING: arch/i386/kernel/built-in.o(.text+0x8657): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region') WARNING: arch/i386/kernel/built-in.o(.text+0x866b): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region') WARNING: arch/i386/kernel/built-in.o(.text+0x867e): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region') WARNING: arch/i386/kernel/built-in.o(.text+0x8684): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region') WARNING: arch/i386/kernel/built-in.o(.text+0x868a): Section mismatch: reference to .init.data: (between 'cyrix_set_all' and 'centaur_get_free_region') Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* x86_64: fix link warning between for .text and .init.textYinghai Lu2007-06-202-3/+3
| | | | | | | | | | | | | | WARNING: arch/x86_64/kernel/built-in.o(.text+0xace9): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/x86_64/kernel/built-in.o(.text+0xad09): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: arch/x86_64/kernel/built-in.o(.text+0xad38): Section mismatch: reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr') WARNING: drivers/built-in.o(.text+0x3a680): Section mismatch: reference to .init.text:acpi_map_pxm_to_node (between 'acpi_get_node' and 'acpi_lock_ac_dir') AK: also marked mtrr_bp_init __init to avoid some more warnings Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Andi Kleen <ak@suse.de> Acked-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mtrr atomicity fixAndrew Morton2007-06-041-1/+4
| | | | | | | | | | | | | | Rafael gets this on an SMP box with kernel preemption enabled, during hibernation and restore (100% of the time): Enabling non-boot CPUs ... BUG: using smp_processor_id() in preemptible [00000001] code: bash/4514 caller is mtrr_save_state+0x9/0x40 Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386: fix PGE maskBrian Gerst2007-05-212-2/+2
| | | | | | | | | cr4 is a 32-bit register, so casting the mask to an unsigned char is wrong, as it clears more than the PGE bit. Signed-off-by: Brian Gerst <bgerst@didntduck.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* i386/x86-64: fix section mismatchBernhard Walle2007-05-172-2/+2
| | | | | | | | | | | | | | | WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text:mtrr_bp_init from .text between 'id entify_cpu' (at offset 0x6571) and 'IRQ0x20_interrupt' It's because identify_cpu() which is __cpuinit calls mtrr_bp_init() which is __init(). __cpuinit() expands to nothing if CONFIG_HOTPLUG_CPU=y and so the call is illegal. Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] i386: fix mtrr sectionsRandy Dunlap2007-05-021-3/+4
| | | | | | | | | | | | | | | Fix section mismatch warnings in mtrr code. Fix line length on one source line. WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103) WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x180) WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x199) WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to .init.text: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x1c1) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.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: Enable support for fixed-range IORRs to keep RdMem & WrMem in syncBernhard Kaindl2007-05-021-25/+60
| | | | | | | | | | | | | | | | | | | | | | | If our copy of the MTRRs of the BSP has RdMem or WrMem set, and we are running on an AMD64/K8 system, the boot CPU must have had MtrrFixDramEn and MtrrFixDramModEn set (otherwise our RDMSR would have copied these bits cleared), so we set them on this CPU as well. This allows us to keep the AMD64/K8 RdMem and WrMem bits in sync across the CPUs of SMP systems in order to fullfill the duty of system software to "initialize and maintain MTRR consistency across all processors." as written in the AMD and Intel manuals. If an WRMSR instruction fails because MtrrFixDramModEn is not set, I expect that also the Intel-style MTRR bits are not updated. AK: minor cleanup, moved MSR defines around Signed-off-by: Bernhard Kaindl <bk@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andi Kleen <ak@suse.de> Cc: Dave Jones <davej@codemonkey.org.uk>
* [PATCH] x86: Save the MTRRs of the BSP before booting an APBernhard Kaindl2007-05-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applied fix by Andew Morton: http://lkml.org/lkml/2007/4/8/88 - Fix `make headers_check'. AMD and Intel x86 CPU manuals state that it is the responsibility of system software to initialize and maintain MTRR consistency across all processors in Multi-Processing Environments. Quote from page 188 of the AMD64 System Programming manual (Volume 2): 7.6.5 MTRRs in Multi-Processing Environments "In multi-processing environments, the MTRRs located in all processors must characterize memory in the same way. Generally, this means that identical values are written to the MTRRs used by the processors." (short omission here) "Failure to do so may result in coherency violations or loss of atomicity. Processor implementations do not check the MTRR settings in other processors to ensure consistency. It is the responsibility of system software to initialize and maintain MTRR consistency across all processors." Current Linux MTRR code already implements the above in the case that the BIOS does not properly initialize MTRRs on the secondary processors, but the case where the fixed-range MTRRs of the boot processor are changed after Linux started to boot, before the initialsation of a secondary processor, is not handled yet. In this case, secondary processors are currently initialized by Linux with MTRRs which the boot processor had very early, when mtrr_bp_init() did run, but not with the MTRRs which the boot processor uses at the time when that secondary processors is actually booted, causing differing MTRR contents on the secondary processors. Such situation happens on Acer Ferrari 1000 and 5000 notebooks where the BIOS enables and sets AMD-specific IORR bits in the fixed-range MTRRs of the boot processor when it transitions the system into ACPI mode. The SMI handler of the BIOS does this in SMM, entered while Linux ACPI code runs acpi_enable(). Other occasions where the SMI handler of the BIOS may change bits in the MTRRs could occur as well. To initialize newly booted secodary processors with the fixed-range MTRRs which the boot processor uses at that time, this patch saves the fixed-range MTRRs of the boot processor before new secondary processors are started. When the secondary processors run their Linux initialisation code, their fixed-range MTRRs will be updated with the saved fixed-range MTRRs. If CONFIG_MTRR is not set, we define mtrr_save_state as an empty statement because there is nothing to do. Possible TODOs: *) CPU-hotplugging outside of SMP suspend/resume is not yet tested with this patch. *) If, even in this case, an AP never runs i386/do_boot_cpu or x86_64/cpu_up, then the calls to mtrr_save_state() could be replaced by calls to mtrr_save_fixed_ranges(NULL) and mtrr_save_state() would not be needed. That would need either verification of the CPU-hotplug code or at least a test on a >2 CPU machine. *) The MTRRs of other running processors are not yet checked at this time but it might be interesting to syncronize the MTTRs of all processors before booting. That would be an incremental patch, but of rather low priority since there is no machine known so far which would require this. AK: moved prototypes on x86-64 around to fix warnings Signed-off-by: Bernhard Kaindl <bk@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andi Kleen <ak@suse.de> Cc: Dave Jones <davej@codemonkey.org.uk>
* [PATCH] x86: Adds mtrr_save_fixed_ranges() for use in two later patches.Bernhard Kaindl2007-05-021-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In this current implementation which is used in other patches, mtrr_save_fixed_ranges() accepts a dummy void pointer because in the current implementation of one of these patches, this function may be called from smp_call_function_single() which requires that this function takes a void pointer argument. This function calls get_fixed_ranges(), passing mtrr_state.fixed_ranges which is the element of the static struct which stores our current backup of the fixed-range MTRR values which all CPUs shall be using. Because mtrr_save_fixed_ranges calls get_fixed_ranges after kernel initialisation time, __init needs to be removed from the declaration of get_fixed_ranges(). If CONFIG_MTRR is not set, we define mtrr_save_fixed_ranges as an empty statement because there is nothing to do. AK: Moved prototypes for x86-64 around to fix warnings Signed-off-by: Bernhard Kaindl <bk@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andi Kleen <ak@suse.de> Cc: Dave Jones <davej@codemonkey.org.uk>
* [PATCH] i386: mtrr range check correctionJan Beulich2007-05-021-1/+1
| | | | | | | | | | | | Whether a region is below 1Mb is determined by its start rather than its end. This hunk got erroneously dropped from a previous patch. Signed-off-by: Jan Beulich <jbeulich@novell.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: fix 32-bit ioctls on x64_32Giuliano Procida2007-02-131-0/+30
| | | | | | | [MTRR] fix 32-bit ioctls on x64_32 Signed-off-by: Giuliano Procida <giuliano.procida@googlemail.com> Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] i386: fix size_or_mask and size_and_maskAndreas Herrmann2007-02-132-4/+4
| | | | | | | | | | | | | | | | mtrr: fix size_or_mask and size_and_mask This fixes two bugs in /proc/mtrr interface: o If physical address size crosses the 44 bit boundary size_or_mask is evaluated wrong. o size_and_mask limits width of physical base address for an MTRR to be less than 44 bits. TBD: later patch had one more change, but I think that was bogus. TBD: need to double check Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] mark struct file_operations const 2Arjan van de Ven2007-02-121-1/+1
| | | | | | | | | | | | Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch accidental writes at compile time to these shared resources. [akpm@osdl.org: sparc64 fix] Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] x86-64: replace kmalloc+memset with kzalloc in MTRR codeBurman Yan2006-12-072-6/+3Star
| | | | | | Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] i386: fix MTRR codeJan Beulich2006-12-077-60/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until not so long ago, there were system log messages pointing to inconsistent MTRR setup of the video frame buffer caused by the way vesafb and X worked. While vesafb was fixed meanwhile, I believe fixing it there only hides a shortcoming in the MTRR code itself, in that that code is not symmetric with respect to the ordering of attempts to set up two (or more) regions where one contains the other. In the current shape, it permits only setting up sub-regions of pre-exisiting ones. The patch below makes this symmetric. While working on that I noticed a few more inconsistencies in that code, namely - use of 'unsigned int' for sizes in many, but not all places (the patch is converting this to use 'unsigned long' everywhere, which specifically might be necessary for x86-64 once a processor supporting more than 44 physical address bits would become available) - the code to correct inconsistent settings during secondary processor startup tried (if necessary) to correct, among other things, the value in IA32_MTRR_DEF_TYPE, however the newly computed value would never get used (i.e. stored in the respective MSR) - the generic range validation code checked that the end of the to-be-added range would be above 1MB; the value checked should have been the start of the range - when contained regions are detected, previously this was allowed only when the old region was uncacheable; this can be symmetric (i.e. the new region can also be uncacheable) and even further as per Intel's documentation write-trough and write-back for either region is also compatible with the respective opposite in the other Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] i386: conditionalize inclusion of some MTRR flavorsJan Beulich2006-12-072-3/+7
| | | | | | | Avoid inclusion of code that's dead for x86-64. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de>
* [PATCH] i386: fix buggy MTRR address checksAndreas Mohr2006-12-072-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Fix checks that failed to realize that values are 4-kB-unit-sized (note the format strings in this same diff context which *do* realize the unit size, via appended "000"!). Also fix an incorrect below-1MB area check (as gathered from Jan Beulich's unapplied patch at http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/1378.html ) Update mtrr_add_page() docu to make 4-kB-sized calculation more obvious. Given several further items mentioned in Jan's patch mail, all in all MTRR code seems surprisingly buggy, for a surprisingly long period of time (many years). Further work/investigation would be useful. TBD Note that my patch is pretty much UNTESTED, since I can only verify that it TBD successfully boots my machine, but I cannot test against actual buggy TBD hardware which would require these (formerly broken) checks. Long -mm TBD simmering would make sense, especially since these now-working checks might TBD turn out to have adverse effects on unaffected hardware. Signed-off-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Andi Kleen <ak@suse.de> Acked-by: Jan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org>
* [PATCH] mtrr: Add lock annotations for prepare_set and post_setJosh Triplett2006-09-261-2/+2
| | | | | | | | | | | | | The functions prepare_set and post_set in kernel/cpu/mtrr/generic.c wrap the spinlock set_atomicity_lock: prepare_set returns with the lock held, and post_set releases the lock without acquiring it. Add lock annotations to these two functions so that sparse can check callers for lock pairing, and so that sparse will not complain about these functions since they intentionally use locks in this manner. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] sem2mutex: misc static one-file mutexesIngo Molnar2006-03-261-6/+7
| | | | | | | | | | | | | | | | | | | | | | Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jens Axboe <axboe@suse.de> Cc: Neil Brown <neilb@cse.unsw.edu.au> Acked-by: Alasdair G Kergon <agk@redhat.com> Cc: Greg KH <greg@kroah.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Adam Belay <ambx1@neo.rr.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/x86Linus Torvalds2006-02-011-9/+6Star
|\
| * [X86] Remove pointless versioning of mtrr driver.Dave Jones2006-01-061-3/+0Star
| | | | | | | | | | | | | | It's not like this has changed significantly, and probably never will. Reduce some bootup dmesg noise. Signed-off-by: Dave Jones <davej@redhat.com>
| * [X86] Rename MTRR mutex to something more sensible.Dave Jones2005-12-201-6/+6
| | | | | | | | | | | | | | I spotted 'main_lock' whilst grovelling through a vmlinux with objdump. Even if it is static, it's a horrible name. Signed-off-by: Dave Jones <davej@redhat.com>
* | [PATCH] capable/capability.h (arch/)Randy Dunlap2006-01-121-0/+1
| | | | | | | | | | | | | | | | arch: Use <linux/capability.h> where capable() is used. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* | remove the outdated arch/i386/kernel/cpu/{,mtrr/}changelogAdrian Bunk2006-01-101-229/+0Star
|/ | | | | | | This patch removes two outdated changelog files. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [PATCH] x86_64: Force correct address space size for MTRR on some 64bit ↵Shaohua Li2005-11-151-0/+8
| | | | | | | | | | | | | | | | Intel Xeons They report 40bit, but only have 36bits of physical address space. This caused problems with setting up the correct masks for MTRR. CPUID workaround for steppings 0F33h(supporting x86) and 0F34h(supporting x86 and EM64T). Detail info can be found at: http://download.intel.com/design/Xeon/specupdt/30240216.pdf http://download.intel.com/design/Pentium4/specupdt/30235221.pdf Signed-off-by: Shaohua Li<shaohua.li@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Clean up mtrr compat ioctl codeBrian Gerst2005-10-311-45/+74
| | | | | | | | | | Handle 32-bit mtrr ioctls in the mtrr driver instead of the ia32 compatability layer. Signed-off-by: Brian Gerst <bgerst@didntduck.org> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] swsusp: fix remaining u32 vs. pm_message_t confusionPavel Machek2005-09-051-1/+1
| | | | | | | | | | Fix remaining bits of u32 vs. pm_message confusion. Should not break anything. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] MTRR suspend/resume cleanupShaohua Li2005-07-083-35/+64
| | | | | | | | | | | | | There has been some discuss about solving the SMP MTRR suspend/resume breakage, but I didn't find a patch for it. This is an intent for it. The basic idea is moving mtrr initializing into cpu_identify for all APs (so it works for cpu hotplug). For BP, restore_processor_state is responsible for restoring MTRR. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] get rid of redundant NULL checks before kfree() in arch/i386/Jesper Juhl2005-06-261-2/+1Star
| | | | | | Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] mtrr size-and-base debuggingAndrew Morton2005-06-231-8/+15
| | | | | | | Consolidate the mtrr sanity checking, add a dump_stack(). Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cyrix: eliminate bad section referencesmaximilian attems2005-05-061-2/+2
| | | | | | | | | | | | | | | | | | | | | Fix cyrix section references: convert __initdata to __devinitdata. Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000379 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 00000399 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b3 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003b9 R_386_32 .init.data Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .text refers to 000003bf R_386_32 .init.data Signed-of-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] make lots of things staticAdrian Bunk2005-05-011-2/+2
| | | | | | | | Another large rollup of various patches from Adrian which make things static where they were needlessly exported. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Enable write combining for server works LE rev > 6Lee Revell2005-05-011-5/+9
| | | | | | | | | Enable write combining for server works LE rev > 6 per http://www.ussg.iu.edu/hypermail/linux/kernel/0104.3/1007.html Signed-Off-By: Lee Revell <rlrevell@joe-job.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64-always-use-cpuid-80000008-to-figure-out-mtrr fixSiddha, Suresh B2005-04-171-2/+4
| | | | | | | | | 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>
* [PATCH] x86_64: Always use CPUID 80000008 to figure out MTRR address space sizeAndi Kleen2005-04-171-34/+15Star
| | | | | | | | | | | | | 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>
* Linux-2.6.12-rc2Linus Torvalds2005-04-1710-0/+2602
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!
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-22 01:24:25 +0200