- 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:
-
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:
-
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:
-
