- 17 Apr, 2008 40 commits
-
-
Paolo Ciarrocchi authored
Signed-off-by:
Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Jacek Luczak authored
this patch fixes section mismatch warnings (on x86_64 host) in setup_trampoline(), which was referencing __initdata variables trampoline_data and trampoline_end. Warning messages: WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x2b6a): Section mismatch in reference from the function setup_trampoline() to the variable .init.data:trampoline_data The function __cpuinit setup_trampoline() references a variable __initdata trampoline_data. If trampoline_data is only used by setup_trampoline then annotate trampoline_data with a matching annotation. WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x2b71): Section mismatch in reference from the function setup_trampoline() to the variable .init.data:trampoline_end The function __cpuinit setup_trampoline() references a variable __initdata trampoline_end. If trampoline_end is only used by setup_trampoline then annotate trampoline_end with a matching annotation. Signed-off-by: -
Jacek Luczak authored
This patch fixes mismatch warnings in smp_checks() (in arch/x86/kernel/smpboot.c): WARNING: arch/x86/kernel/built-in.o(.text+0x11922): Section mismatch in reference from the function smp_checks() to the variable .cpuinit.data:smp_b_stepping The function smp_checks() references the variable __cpuinitdata smp_b_stepping. This is often because smp_checks lacks a __cpuinitdata annotation or the annotation of smp_b_stepping is wrong. Signed-off-by:
Jacek Luczak <luczak.jacek@gmail.com> Signed-off-by:
-
Alok Kataria authored
> > Make sure that we clear the "shutdown status flag" in the CMOS > > register after each CPU is brought up. This fixes a problem where the > > "shutdown status flag" may remain set when a CPU is brought up after > > booting. > > btw., what problem does this result in, exactly? The shutdown status flag set to "0xA", corresponds to "JMP double word request without INT init". This JMP at reboot time is at an unintended location. And results in Triple faults in our case. Though this error at reboot can be safely ignored in a VM environment, am not sure what the effect would be on a physical system. May be it will result in a triple fault and an eventual hardware reset thus masking this BUG in the kernel. This fix just makes sure that we reset that status flag after initialization is done. Fix paranoia about using BIOS quickboot mechanism. Make sure that we clear the "shutdown status flag" in the CMOS register after each CPU is brought up. This fixes a problem where the "shutdown status flag" may remain set when a CPU is brought up after booting. Signed-off-by:
Alok N Kataria <akataria@vmware.com> Signed-off-by:
Dan Arai <arai@vmware.com> Signed-off-by:
-
Yinghai Lu authored
print out buggy mptable, instead of skipping it quietly Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Akinobu Mita authored
Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Akinobu Mita authored
Use cpumask_of_cpu() rather than the pair of cpus_clear() and cpu_set(). Signed-off-by:
-
Akinobu Mita authored
There is no reason to use obscurer name. Signed-off-by:
-
Akinobu Mita authored
No need to clear the memory allocated by alloc_bootmem(). It is already filled with zero. Signed-off-by:
-
Akinobu Mita authored
Remove duplicate code by using ioapic_read_entry() and ioapic_write_entry() in io_apic_{32,64}.c Signed-off-by: -
Akinobu Mita authored
If one can find an ack pending pin, there is no need to check the rest of them. Signed-off-by:
-
Alexander van Heukelum authored
In arch/x86/boot/compressed/misc.c, the variable vidmem is the only variable that ends up in de data segment. It's also superfluous, because the first thing the code does is: if (RM_SCREEN_INFO.orig_video_mode == 7) { vidmem = (char *) 0xb0000; vidport = 0x3b4; } else { vidmem = (char *) 0xb8000; vidport = 0x3d4; } This patch removes the initialisation. Signed-off-by: -
Alexey Starikovskiy authored
Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
Alexey Starikovskiy authored
Signed-off-by:
-
