- 30 Jan, 2008 40 commits
-
-
Ingo Molnar authored
these bugs are harder to find than they seem, a stackdump helps. make it dependent on CONFIG_DEBUG_SHIRQ so that people can turn it off if it annoys them. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Ingo Molnar authored
An older binutils bug caused us to not fix up alternatives. This problem involved mutex.c but we dont do lockdep section tricks there anymore, so this workaround is moot. Keep the printk nevertheless, just in case ... We can remove that later on. Signed-off-by:
-
Ingo Molnar authored
add warning to check_tsc_warp() - if get_cycles() does not progress. Signed-off-by:
-
Ingo Molnar authored
100 million max # of loops is a bit too much - reduce it to 10 million. Signed-off-by:
-
Jan Engelhardt authored
x86: remove unneeded casts Signed-off-by:
Jan Engelhardt <jengelh@computergmbh.de> Signed-off-by:
-
Harvey Harrison authored
Use v8086_mode inline in fault_32.c, no functional change also ifdef the section for 32-bit only and add to fault_64.c Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Ingo Molnar authored
dont crash survivable situations. Signed-off-by:
-
travis@sgi.com authored
Provide a means to trap usages of per_cpu map variables before they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate. Signed-off-by:
Mike Travis <travis@sgi.com> Signed-off-by:
-
travis@sgi.com authored
Change static bios_cpu_apicid array to a per_cpu data variable. This includes using a static array used during initialization similar to the way x86_cpu_to_apicid[] is handled. There is one early use of bios_cpu_apicid in apic_is_clustered_box(). The other reference in cpu_present_to_apicid() is called after smp_set_apicids() has setup the percpu version of bios_cpu_apicid. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Mike Travis authored
Signed-off-by:
-
travis@sgi.com authored
Change the following static arrays sized by NR_CPUS to per_cpu data variables: char cpu_to_node_map[NR_CPUS]; fixup: - Split cpu_to_node function into "early" and "late" versions so that x86_cpu_to_node_map_early_ptr is not EXPORT'ed and the cpu_to_node inline function is more streamlined. - This also involves setting up the percpu maps as early as possible. - Fix X86_32 NUMA build errors that previous version of this patch caused. V2->V3: - add early_cpu_to_node function to keep cpu_to_node efficient - move and rename smp_set_apicids() to setup_percpu_maps() - call setup_percpu_maps() as early as possible V1->V2: - Removed extraneous casts - Fix !NUMA builds with '#ifdef CONFIG_NUMA" Signed-off-by: -
Andi Kleen authored
Add a generic option to clear any cpuid bit. I added it because it was very easy to add with the new generic cpuid disable bitmap and perhaps it will be useful in the future. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
To disable CLFLUSH usage, especially in change_page_attr(). Signed-off-by:
-
Andi Kleen authored
Fix from: Ian Campbell <ijc@hellion.org.uk> Signed-off-by:
-
Andi Kleen authored
Modern 32bit userland doesn't even boot when the TSC is disabled because ld.so tends to contain RDTSCs. So make notsc only effective for the kernel, similar to 64bit. Signed-off-by:
-
Andi Kleen authored
This convers nofxsr, mem=nopentium and nosep to use the new generic cpuid disable bitmap instead of using own variables. Signed-off-by:
-
Andi Kleen authored
There are already various options to disable specific cpuid bits on the command line. They all use their own variable. Add a generic mask to make this easier in the future. Signed-off-by:
-
Eduardo Habkost authored
This finally makes paravirt-ops able to compile and boot under x86_64. Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
-
Eduardo Habkost authored
paravirt_pagetable_setup_{start,done}() are not used (yet) under x86_64, and native_pagetable_setup_{start,done}() don't exist on x86_64. So they don't need to be set. Signed-off-by: -
Eduardo Habkost authored
Add .set_pgd field to pv_mmu_ops. Implement pud_val(), __pud(), set_pgd(), pud_clear(), pgd_clear(). pud_clear() and pgd_clear() are implemented simply using set_pud() and set_pmd(). They don't have a field at pv_mmu_ops. Signed-off-by:
-
Glauber de Oliveira Costa authored
__pmd, pmd_val and set_pud are used before they are defined (as static) We move them a little up in the file, so it doesn't happen. Signed-off-by:
Glauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by:
-
Glauber de Oliveira Costa authored
This patch adds the __parainstructions section to vmlinux.lds.S. It's needed for the patching system. Signed-off-by:
-
Glauber de Oliveira Costa authored
This patch adds the constant PARAVIRT needs in asm_offsets_64.c Signed-off-by:
-
Glauber de Oliveira Costa authored
This patch fills in the read and write cr8 fields with their native version. Signed-off-by:
-
Glauber de Oliveira Costa authored
Since the cr8 manipulation functions ended up staying in the tree, they can't be defined just when PARAVIRT is off: In this patch, those functions are defined for the PARAVIRT case too. [ mingo@elte.hu: fixes ] Signed-off-by:
-
Glauber de Oliveira Costa authored
This patch adds room for read and write_cr8 functions back in pv_cpu_ops struct Signed-off-by:
-
Glauber de Oliveira Costa authored
With PARAVIRT, we actually have arch_{dup,exit}_mmap functions, so we can't include the generic header Signed-off-by: -
Glauber de Oliveira Costa authored
x86_64 lacks a native_init_IRQ() function, so we turn the arch's init_IRQ() function into a native construct Signed-off-by:
-
Glauber de Oliveira Costa authored
We use a __stringify construction at paravirt_patch_64.c. It's better practice to include the stringify header directly Signed-off-by:
-
Yinghai Lu authored
currently when gart iommu is enabled by BIOS or previous we got " Checking aperture... CPU 0: aperture @4000000 size 64MB CPU 1: aperture @4000000 size 64MB " we should use use Node instead. we will get " Checking aperture... Node 0: aperture @4000000 size 64MB Node 1: aperture @4000000 size 64MB " Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Hiroshi Shimamoto authored
Move the select_idle_routine() call to after the detect_ht() call at identify_cpu() on 64-bit. This change is for printing the polling idle and HT enabled warning message properly. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
-
Hiroshi Shimamoto authored
The warning message at idle_setup() is never shown because smp_num_sibling hasn't been updated at this point yet. Move this polling idle and HT enabled warning to select_idle_routine(). I also implement this warning on 64-bit kernel. Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Michael Opdenacker authored
do not add the pcspkr platform device if pcspkr support is disabled. Signed-off-by:
Michael Opdenacker <michael@free-electrons.com> Signed-off-by:
-
Yinghai Lu authored
Andi's patch " x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection Need this in the next patch in time_init and that happens early. This includes a minor fix on i386 where early_intel_workarounds() [which is now called early_init_intel] really executes early as the comments say. " calling early_init_amd in early_identify_cpu and identify_cpu two times. this patch remove the one in identify_cpu Signed-off-by: -
Jesse Barnes authored
On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup. This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it and it's untested on other non-Intel machines, so best keep it off). Further enhancements and fixes from: Yinghai Lu <Yinghai.Lu@Sun.COM> Andi Kleen <ak@suse.de> Signed-off-by:
Jesse Barnes <jesse.barnes@intel.com> Tested-by:
Justin Piszcz <jpiszcz@lucidpixels.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andi Kleen authored
They now look like: hal-resmgr[13791]: segfault at 3c rip 2b9c8caec182 rsp 7fff1e825d30 error 4 in libacl.so.1.1.0[2b9c8caea000+6000] This makes it easier to pinpoint bugs to specific libraries. And printing the offset into a mapping also always allows to find the correct fault point in a library even with randomized mappings. Previously there was no way to actually find the correct code address inside the randomized mapping. Relies on earlier patch to shorten the printk formats. They are often now longer than 80 characters, but I think that's worth it. [includes fix from Eric Dumazet to check d_path error value] Signed-off-by:
-
Andi Kleen authored
When the kernel panics early for some unrelated reason there would be eventually an early exception inside panic because clear_local_APIC tried to disable the not yet mapped APIC. Check for that explicitely. Signed-off-by:
-
Andi Kleen authored
On VMs implemented using JITs that cache translated code changing the lock prefixes is a quite costly operation that forces the JIT to throw away and retranslate a lot of code. Previously a SMP kernel would rewrite the locks once for each CPU which is quite unnecessary. This patch changes the code to never switch at boot in the normal case (SMP kernel booting with >1 CPU) or only once for SMP kernel on UP. This makes a significant difference in boot up performance on AMD SimNow! Also I expect it to be a little faster on native systems too because a smp switch does a lot of text_poke()s which each synchronize the pipeline. v1->v2: Rename max_cpus v1->v2: Fix off by one in UP check (Thomas Gleixner) Signed-off-by:
-
Andi Kleen authored
On x86-64 there are several memory allocations before bootmem. To avoid them stomping on each other they used to be all hard coded in bad_area(). Replace this with an array that is filled as needed. This cleans up the code considerably and allows to expand its use. Cc: peterz@infradead.org Signed-off-by:
-
