- 17 Apr, 2008 40 commits
-
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Joe Perches authored
Signed-off-by:
-
Ingo Molnar authored
revert: "x86: fix breakage of vSMP irq operations" the irqflags.h unification will solve this in a cleaner way. Signed-off-by: -
Yinghai Lu authored
Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
> yhlu@mpk:~/xx/xx/kernel/x86/linux-2.6> git-bisect bad > d1c707188ad646c8094cac9afb1738e7d0196ff2 is first bad commit > commit d1c707188ad646c8094cac9afb1738e7d0196ff2 > Author: Glauber de Oliveira Costa <gcosta@redhat.com> > Date: Wed Mar 19 14:25:53 2008 -0300 > > x86: include mach_apic.h in smpboot_64.c and smpboot.c > > After the inclusion, a lot of files needs fixing for conflicts, > some of them in the headers themselves, to accomodate for both > i386 and x86_64 versions. > > [ mingo@elte.hu: build fix ] > > Signed-off-by: Glauber Costa <gcosta@redhat.com> > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > :040000 040000 19f574e64bb8003bbe984f3a8c1315db969dfdcd > 6ffe96588c77bc936705599fa110107856201115 M arch > :040000 040000 61269347ad4f384ed85cc87c4f2d004ed94492ac > 8f5c713da25579a3cdf63db3d4c2f795261d0521 M include > yhlu@mpk:~/xx/xx/kernel/x86/linux-2.6> > attached patch fixes that.
-
Cyrill Gorcunov authored
This patch does clean up relocate_kernel_(32|64).S a bit by getting rid of local PAGE_ALIGNED macro. We should use well-known PAGE_SIZE instead Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
-
Jack Steiner authored
Allow the maximum number of nodes in an x86_64 system to be configurable. This patch does NOT change the default value but allows the value to be a config option. Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
-
Jack Steiner authored
Increase the maximum physical address size of x86_64 system to 44-bits. This is in preparation for future chips that support larger physical memory sizes. Signed-off-by:
-
Jan Beulich authored
This (simplified) piece of code didn't behave as expected due to incorrect constraints in some of the bitops functions, when X86_FEATURE_xxx is referring to other than the first long: int test(struct cpuinfo_x86 *c) { if (cpu_has(c, X86_FEATURE_xxx)) clear_cpu_cap(c, X86_FEATURE_xxx); return cpu_has(c, X86_FEATURE_xxx); } I'd really like understand, though, what the policy of (not) having a "memory" clobber in these operations is - currently, this appears to be totally inconsistent. Also, many comments of the non-atomic functions say those may also be re-ordered - this contradicts the use of "asm volatile" in there, which again I'd like to understand. As much as all of these, using 'int' for the 'nr' parameter and 'void *' for the 'addr' one is in conflict with Documentation/atomic_ops.txt, especially because bt{,c,r,s} indeed take the bit index as signed (which hence would really need special precaution) and access the full 32 bits (if 'unsigned long' was used properly here, 64 bits for x86-64) pointed at, so invalid uses like referencing a 'char' array cannot currently be caught. Finally, the code with and without this patch relies heavily on the -fno-strict-aliasing compiler switch and I'm not certain this really is a good idea. In the light of all of this I'm sending this as RFC, as fixing the above might warrant a much bigger patch... Signed-off-by:Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Ingo Molnar authored
un-revert: commit 4960c9df Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Jan 22 10:23:01 2008 +0100 Revert "x86: fix NMI watchdog & 'stopped time' problem" This reverts commit d4d25dec. needs a proper fix though ... Signed-off-by:
-
Andrew Morton authored
arch/x86/math-emu/reg_ld_str.c:380: warning: 'l[0]' may be used uninitialized in this function arch/x86/math-emu/reg_ld_str.c:380: warning: 'l[1]' may be used uninitialized in this function I can't actually spot the bug here. There's one obvious place, but fixing that didn't shut the warning up. Cc: Andi Kleen <ak@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andrew Morton authored
arch/x86/math-emu/fpu_entry.c:555: warning: 'entry_sel_off.empty' is used uninitialized in this function Presumably it's harmless, but I'll sleep better at night knowing that we initialised it. Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Venki Pallipadi authored
Make the PAT related printks in ioremap pr_debug. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Venki Pallipadi authored
Bug fixes for reserve_memtype() call in __ioremap and pci_mmap_page_range(). If reserve_memtype returns non-zero, then it is an error and subsequent free is not required. Requested and returned prot value check should be done when reserve_memtype returns success. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
Yinghai Lu authored
make known_pat_cpu to think amd k8 and fam10h is ok too. also make tom2 below to be WRBACK Signed-off-by:
-
Ingo Molnar authored
build fix for !CONFIG_MTRR. Signed-off-by: -
Venki Pallipadi authored
Fix double help section in PAT Kconfig. Thanks to Randy Dunlap for catching this bug. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Adds debug prints at critical code. Adds enough info in dmesg to allow us to do effective first round of analysis of any issues that may result due to PAT patch series. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Introduce ioremap_wc for wc remap. (generic wrapper is in a later patch) Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Add a set_memory_wc interface(), similar to set_memory_uc interface. Callers has to call set_memory_uc, set_memory_wb and set_memory_wc, set_memory_wb as pairs. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Add reserve_memtype and free_memtype wrapper for pci_mmap_page_range. Free is called on unmap, but identity map continues to be mapped as per pci_mmap_page_range request, until next request for the same region calls ioremap_change_attr(), which will go through without conflict. This way of mapping is identical to one used in ioremap/iounmap. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Use reserve_memtype and free_memtype interfaces in set_memory_uc/set_memory_wb interfaces to avoid aliasing. Usage model of set_memory_uc and set_memory_wb is for RAM memory and users will first call set_memory_uc and call set_memory_wb after use to reset the attribute. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Use reserve_memtype and free_memtype interfaces in ioremap/iounmap to avoid aliasing. If there is an existing alias for the region, inherit the memory type from the alias. If there are conflicting aliases for the entire region, then fail ioremap. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Make ioremap_change_attr() non-static and use prot_val in place of ioremap_mode. This interface is used in subsequent PAT patches. Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
venkatesh.pallipadi@intel.com authored
Sets up pat_init() infrastructure. PAT MSR has following setting. PAT |PCD ||PWT ||| 000 WB _PAGE_CACHE_WB 001 WC _PAGE_CACHE_WC 010 UC- _PAGE_CACHE_UC_MINUS 011 UC _PAGE_CACHE_UC We are effectively changing WT from boot time setting to WC. UC_MINUS is used to provide backward compatibility to existing /dev/mem users(X). reserve_memtype and free_memtype are new interfaces for maintaining alias-free mapping. It is currently implemented in a simple way with a linked list and not optimized. reserve and free tracks the effective memory type, as a result of PAT and MTRR setting rather than what is actually requested in PAT. pat_init piggy backs on mtrr_init as the rules for setting both pat and mtrr are same. Signed-off-by:
-
venkatesh.pallipadi@intel.com authored
Documentation about PAT related interfaces, intended usage and memory attribute relationship. Signed-off-by:
-
Pavel Machek authored
Initializing to zero is generally bad idea, I hope it is right for __init data, too. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Yinghai Lu authored
don't need to allocate that one by one Signed-off-by:
-
