- 08 Jul, 2008 40 commits
-
-
Yinghai Lu authored
Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
and let 64 bit use that instead of setup_64.c [ mingo@elte.hu ] x86: build fix fix: arch/x86/kernel/setup.c: In function ‘setup_arch': arch/x86/kernel/setup.c:561: error: implicit declaration of function ‘efi_reserve_early' and: arch/x86/kernel/setup.c:766: error: implicit declaration of function 'init_cpu_to_node' and: arch/x86/kernel/setup.c:676: warning: operation on 'max_pfn_mapped' may be undefined Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
those variables are not needed by 64 bit. Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
So remove outdated comments Signed-off-by:
-
Yinghai Lu authored
some functions need to be moved to setup_numa.c after we merge setup32/64.c, some funcs need to be moved back to setup.c Signed-off-by:
-
Yinghai Lu authored
interesting... [ 0.000000] mapped low ram: 0 - 20000000 [ 0.000000] low ram: 00000000 - 1fff0000 [ 0.000000] bootmap 00002000 - 00006000 max_pfn_mapped > max_low_pfn? it seems init_memory_mapping reveals an old bug. please check attached test patch. Signed-off-by: -
Bernhard Walle authored
I would suggest to remove the "experimental" status from Kdump. Kdump is now in the kernel since a long time and used by Enterprise distributions. I don't think that "experimental" is true any more. Signed-off-by:
Bernhard Walle <bwalle@suse.de> Cc: vgoyal@redhat.com Cc: kexec@lists.infradead.org Cc: Bernhard Walle <bwalle@suse.de> Cc: akpm@linux-foundation.org Signed-off-by:
-
Paul Jackson authored
Applies on top of the previous patch: x86 boot: add code to add BIOS provided EFI memory entries to kernel Instead of always adding EFI memory map entries (if present) to the memory map after initially finding either E820 BIOS memory map entries and/or kernel command line memmap entries, -instead- only add such additional EFI memory map entries if the kernel boot option: add_efi_memmap is specified. Requiring this 'add_efi_memmap' option is backward compatible with kernels that didn't load such additional EFI memory map entries in the first place, and it doesn't override a configuration that tries to replace all E820 or EFI BIOS memory map entries with ones given entirely on the kernel command line. Signed-off-by:Paul Jackson <pj@sgi.com> Cc: "Yinghai Lu" <yhlu.kernel@gmail.com> Cc: "Jack Steiner" <steiner@sgi.com> Cc: "Mike Travis" <travis@sgi.com> Cc: "Huang Cc: Ying" <ying.huang@intel.com> Cc: "Andi Kleen" <andi@firstfloor.org> Cc: "Andrew Morton" <akpm@linux-foundation.org> Cc: Paul Jackson <pj@sgi.com> Signed-off-by:
-
Paul Jackson authored
Fix some problems with (and applies on top of) a previous patch: x86 boot: show pfn addresses in hex not decimal in some kernel info printks Primarily change "0x%8lx" format, which displays with a right aligned space filled hex number (spaces between the "0x" prefix and the number), into "%0#10lx" format, which zero fills instead of space fills, and which uses the printf flag '#' to request the "0x" prefix instead of hard coding it. Also replace some other "0x%lx" formats with "%#lx", making use of the '#' printf flag again. Signed-off-by:
-
Alok Kataria authored
This is a preparatory patch for the next patch in series. Moves some code from e820_setup_gap to a new function e820_search_gap. This patch is a part of a bug fix where we walk the ACPI table to calculate a gap for PCI optional devices. v1->v2: Patch on top of tip/master. Fixes a bug introduced in the last patch about the typeof "last". Also the new function e820_search_gap now returns if we found a gap in e820_map. Signed-off-by:
Alok N Kataria <akataria@vmware.com> Cc: lenb@kernel.org Signed-off-by:
-
Yinghai Lu authored
and use max_pfn directly. Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
in case someone using crazy parameter while calling them. Signed-off-by:
-
Yinghai Lu authored
that range is from find_e820_area, so don't try to use end_pfn to see if out of boundary...use table_top instead to avoid possible strange result while cross the boundary... also change early_printk to printk, because init_memory_mapping is after early param parsing, and console=uart8250 already working at that time. Signed-off-by:
-
Yinghai Lu authored
so don't shift that in the loop Signed-off-by:
-
Yinghai Lu authored
before that we relay on sanitize_e820_map to remove the overlap. but e820_update_range(,,E820_RESERVED, E820_RAM) will not work this patch fix that who is going to use this? Signed-off-by:
-
Yinghai Lu authored
move kva related early backto initmem_init for numa32 Signed-off-by:
-
Yinghai Lu authored
moving relocate_initrd early Signed-off-by:
-
Yinghai Lu authored
... so can we use mem below max_low_pfn earlier. this allows us to move several functions more early instead of waiting to after paging_init. That includes moving relocate_initrd() earlier in the bootup, and kva related early setup done in initmem_init. (in followup patches) Signed-off-by:
-
Jeremy Fitzhardinge authored
Some amount of asm-x86/mmu_context.h can be unified, including activate_mm paravirt hook. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Stephen Tweedie <sct@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
pgd_index is common for 32 and 64-bit, so move it to a common place. Signed-off-by:
-
Eduardo Habkost authored
Use __pgd() on mk_kernel_pgd() Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Stephen Tweedie <sct@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
For calculating the offset from struct gate_struct fields. [ gate_offset and gate_segment were broken for 32-bit. ] Signed-off-by:
-
Jeremy Fitzhardinge authored
The 32-bit early_ioremap will work equally well for 64-bit, so just use it. Signed-off-by:
-
Jeremy Fitzhardinge authored
Use the _populate() functions to attach new pages to a pagetable, to make sure the right paravirt_ops calls get called. Signed-off-by:
-
Jeremy Fitzhardinge authored
Use write_gdt_entry to generate the special vgetcpu descriptor in the vsyscall page. Signed-off-by:
-
Jeremy Fitzhardinge authored
This removes a pile of buggy open-coded implementations of savesegment and loadsegment. (They are buggy because they don't have memory barriers to prevent them from being reordered with respect to memory accesses.) Signed-off-by:
-
Jeremy Fitzhardinge authored
wrmsr is a special instruction which can have arbitrary system-wide effects. We don't want the compiler to reorder it with respect to memory operations, so make it a memory barrier. Signed-off-by:
-
Jeremy Fitzhardinge authored
Add "memory" clobbers to savesegment and loadsegment, since they can affect memory accesses and we never want the compiler to reorder them with respect to memory references. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
