- 08 Jul, 2008 40 commits
-
-
Yinghai Lu authored
call it right after we are done with MADT/mptable handling, instead of doing that in setup_per_cpu_areas() later on... this way for_possible_cpu() can be used early. Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Yinghai Lu authored
when acpi=off, cpu_to_apicid is ready after get_smp_config so need to move init_cpu_to_node after it. otherwise, we will get wrong cpu->node mapping, and it will rely on amd_detect_cmp() to correct it - but that is too late as setup_per_cpu_data is already called before that so we will get per_cpu_data on the wrong node. Signed-off-by:
-
Yinghai Lu authored
move out e820_register_active_regions from non numa zones_sizes_init() and remove numa version zones_sizes_init(). and let 32 bit call remove_all_active_ranges() in setup_arch() directly like 64-bit Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
so it has a more meaningful name. also change it to static. Signed-off-by:
-
Bernhard Walle authored
This patch fixes a small bug in documentation: x86_64 also has now the ability to build a relocatable kernel. Signed-off-by:
Bernhard Walle <bwalle@suse.de> Cc: vgoyal@redhat.com Cc: kexec@lists.infradead.org Signed-off-by:
-
Bernhard Walle authored
This patch removes the need of the crashkernel=...@offset parameter to define a fixed offset for crashkernel reservation. That feature can be used together with a relocatable kernel where the kexec-tools relocate the kernel and get the actual offset from /proc/iomem. The use case is a kernel where the .text+.data+.bss is after 16M physical memory (debug kernel with lockdep on x86_64 can cause that) which caused a major pain in autoconfiguration in our distribution. Also, that patch unifies crashdump architectures a bit since IA64 has that semantics from the very beginning of the kdump port. Signed-off-by:
-
Alok Kataria authored
e820_search_gap also take a end_addr parameter to limit search from start_addr to end_addr. Signed-off-by:
AloK N Kataria <akataria@vmware.com> Acked-by:
-
Mike Travis authored
* When CONFIG_DEBUG_PER_CPU_MAPS is set, the node passed to node_to_cpumask and node_to_cpumask_ptr should be validated. If invalid, then a dump_stack is performed and a zero cpumask is returned. v2: Slightly different version to remove a compiler warning. v3: Redone to reflect moving setup.c -> setup_percpu.c Signed-off-by:Mike Travis <travis@sgi.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
Ingo Molnar wrote: > -tip auto-testing found pagetable corruption (CPA self-test failure): > > [ 32.956015] CPA self-test: > [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 > [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 > [ 32.968000] CPA ffff88001d54e000: unexpected level 2 > [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 > [ 32.976000] CPA ffff880022c5d000: unexpected level 2 > [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 > [ 32.984000] CPA ffff8800200ce000: unexpected level 2 > [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 > > config and full log can be found at: > > http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad > http://redhat.com/~mingo/misc/log-Mon_Jun_30_11_11_51_CEST_2008.bad Phew. OK, I've worked this out. Short version is that's it's a false alarm, and there was no real failure here. Long version: * I changed the code to create the physical mapping pagetables to reuse any existing mapping rather than replace it. Specifically, reusing an pud pointed to by the pgd caused this symptom to appear. * The specific PUD being reused is the one created statically in head_64.S, which creates an initial 1GB mapping. * That mapping doesn't have _PAGE_GLOBAL set on it, due to the inconsistency between __PAGE_* and PAGE_*. * The CPA test attempts to clear _PAGE_GLOBAL, and then checks to see that the resulting range is 1) shattered into 4k pages, and 2) has no _PAGE_GLOBAL. * However, since it didn't have _PAGE_GLOBAL on that range to start with, change_page_attr_clear() had nothing to do, and didn't bother shattering the range, * resulting in the reported messages The simple fix is to set _PAGE_GLOBAL in level2_ident_pgt. An additional fix to make CPA testing more robust by using some other pagetable bit (one of the unused available-to-software ones). This would solve spurious CPA test warnings under Xen which uses _PAGE_GLOBAL for its own purposes (ie, not under guest control). Also, we should revisit the use of _PAGE_GLOBAL in asm-x86/pgtable.h, and use it consistently, and drop MAKE_GLOBAL. The first time I proposed it it caused breakages in the very early CPA code; with luck that's all fixed now. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Mark McLoughlin <markmc@redhat.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Stephen Tweedie <sct@redhat.com> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Yinghai Lu authored
kva ram already mapped right after away, so don't need to get that for low ram. avoid wasting one copy of pgdat. also add node id in early_res name in case we get it from find_e820_area. Signed-off-by:
-
Yinghai Lu authored
Ying Huang would like setup_data to be reserved, but not included in the no save range. Here we try to modify the e820 table to reserve that range early. also add that in early_res in case bootloader messes up with the ramdisk. other solution would be 1. add early_res_to_highmem... 2. early_res_to_e820... but they could reserve another type memory wrongly, if early_res has some resource reserved early, and not needed later, but it is not removed from early_res in time. Like the RAMDISK (already handled). Signed-off-by:
Huang, Ying <ying.huang@intel.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
-
Ingo Molnar authored
now that the early-ioremap code is unified, move the prototypes too from io_32.h to io.h. this fixes: arch/x86/kernel/setup.c:531: error: implicit declaration of function ‘early_ioremap_init' on 64-bit. Signed-off-by: -
Jeremy Fitzhardinge authored
Looks like the setup.c unification missed the early_ioremap init from the early_ioremap unification. Unconditionally call early_ioremap_init(). needed for "x86/paravirt: groundwork for 64-bit Xen support". Signed-off-by:
-
Ingo Molnar authored
typo fixes from Randy Dunlap and Alan Cox. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Cyrill Gorcunov authored
nmi_watchdog is set to NMI_NONE by default (ie disabled) on _any_ mode so lets fix documentation too. Signed-off-by:
-
Yinghai Lu authored
change the enable_local_apic to static force_enable_local_apic for 32bit Signed-off-by:
-
Yinghai Lu authored
use PMD_SHIFT to calculate boundary also adjust size for pre-allocated table size Signed-off-by:
-
Yinghai Lu authored
when 64bit resource is not enabled, we get: arch/x86/kernel/e820.c: In function ‘e820_reserve_resources’: arch/x86/kernel/e820.c:1217: warning: comparison is always false due to limited range of data type because res->start/end is resource_t aka u32. it will overflow. fix it with temp end of u64 Signed-off-by:
-
Yinghai Lu authored
some ram-end boundary only has page alignment, instead of 2M alignment. v2: make init_memory_mapping more solid: start could be any value other than 0 v3: fix NON PAE by handling left over in kernel_physical_mapping Signed-off-by:
-
Jeremy Fitzhardinge authored
Make sure SWAPGS and PARAVIRT_ADJUST_EXCEPTION_FRAME are properly defined when CONFIG_PARAVIRT is off. Fixes Ingo's build failure: arch/x86/kernel/entry_64.S: Assembler messages: arch/x86/kernel/entry_64.S:1201: Error: invalid character '_' in mnemonic arch/x86/kernel/entry_64.S:1205: Error: invalid character '_' in mnemonic arch/x86/kernel/entry_64.S:1209: Error: invalid character '_' in mnemonic arch/x86/kernel/entry_64.S:1213: Error: invalid character '_' in mnemonic Signed-off-by:
-
Yinghai Lu authored
instead of calling it from trap_init() also move init ioapic mapping out of apic_32.c so 32 bit do same as 64 bit Signed-off-by:
-
Yinghai Lu authored
v2: fix print info to cont Signed-off-by:
-
Jeremy Fitzhardinge authored
Ingo Molnar wrote: > that fixed the build but now we've got a boot crash with this config: > > time.c: Detected 2010.304 MHz processor. > spurious 8259A interrupt: IRQ7. > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [<0000000000000000>] > PGD 0 > Thread overran stack, or stack corrupted > Oops: 0010 [1] SMP > CPU 0 > I don't know if this will fix this bug, but it's definitely a bugfix. It was trashing random pages by overwriting them with pagetables... Don't trash a large pmd's data when mapping physical memory. This is a bugfix for "x86_64: adjust mapping of physical pagetables to work with Xen". Signed-off-by:
-
Jeremy Fitzhardinge authored
Ingo Molnar wrote: > * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >>> It quickly broke the build in testing: > >>> include/asm/pgalloc.h: In function ‘paravirt_pgd_free': > >>> include/asm/pgalloc.h:14: error: parameter name omitted > >>> arch/x86/kernel/entry_64.S: In file included from > >>> arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function > >>> ‘paravirt_pgd_free': > >>> include/asm/pgalloc.h:14: error: parameter name omitted >>> >> No, looks like my fault. The non-PARAVIRT version of >> paravirt_pgd_free() is: >> >> static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} >> >> but C doesn't like missing parameter names, even if unused. >> >> This should fix it: >> > > that fixed the build but now we've got a boot crash with this config: > > time.c: Detected 2010.304 MHz processor. > spurious 8259A interrupt: IRQ7. > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [<0000000000000000>] > PGD 0 > Thread overran stack, or stack corrupted > Oops: 0010 [1] SMP > CPU 0 > > with: > > http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad > Use SWAPGS_UNSAFE_STACK in ia32entry.S in the places where the active stack is the usermode stack. Signed-off-by: -
Yinghai Lu authored
do that in init_memory_mapping also remove one init_ohci1394_dma_on_all_controllers Signed-off-by:
-
Yinghai Lu authored
asm-x86/paravirt.h already have protection with CONFIG_PARAVIRT inside Signed-off-by:
-
Bernhard Walle authored
This patch brings back limiting of the E820 map when a user-defined E820 map is specified. While the behaviour of i386 (32 bit) was to limit the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to limit. That patch limits the E820 map again for both x86 architectures. Code was tested for compilation and booting on a 32 bit and 64 bit system. Signed-off-by:
-
Jeremy Fitzhardinge authored
The patch "x86: introduce init_memory_mapping for 32bit" does not allocate enough space for PTEs if the CPU does not implement PSE. Signed-off-by:
-
Jeremy Fitzhardinge authored
Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
-
Jeremy Fitzhardinge authored
64-bit Xen pushes a couple of extra words onto an exception frame. Add a hook to deal with them. Signed-off-by:
-
Jeremy Fitzhardinge authored
It's never safe to call a swapgs pvop when the user stack is current - it must be inline replaced. Rather than making a call, the SWAPGS_UNSAFE_STACK pvop always just puts "swapgs" as a placeholder, which must either be replaced inline or trap'n'emulated (somehow). Signed-off-by:
-
Jeremy Fitzhardinge authored
Replace privileged instructions with the corresponding pvops in ia32entry.S. Signed-off-by:
-
Jeremy Fitzhardinge authored
In a 64-bit system, we need separate sysret/sysexit operations to return to a 32-bit userspace. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citirx.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
There's no need to combine restoring the user rsp within the sysret pvop, so split it out. This makes the pvop's semantics closer to the machine instruction. Signed-off-by:
-
Jeremy Fitzhardinge authored
Don't conflate sysret and sysexit; they're different instructions with different semantics, and may be in use at the same time (at least within the same kernel, depending on whether its an Intel or AMD system). sysexit - just return to userspace, does no register restoration of any kind; must explicitly atomically enable interrupts. sysret - reloads flags from r11, so no need to explicitly enable interrupts on 64-bit, responsible for restoring usermode %gs Signed-off-by: -
Jeremy Fitzhardinge authored
This is needed when the kernel is running on RING3, such as under Xen. x86_64 has a weird feature that makes it #GP on iret when SS is a null descriptor. This need to be tested on bare metal to make sure it doesn't cause any problems. AMD specs say SS is always ignored (except on iret?). Signed-off-by:
-
Jeremy Fitzhardinge authored
We must do this because load_TLS() may need to clear %fs and %gs. (e.g. under Xen). Signed-off-by:
-
