aboutsummaryrefslogtreecommitdiff
path: root/arch/x86
AgeCommit message (Collapse)Author
2008-11-03Merge branch 'io-mappings-for-linus-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'io-mappings-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: io mapping: clean up #ifdefs io mapping: improve documentation i915: use io-mapping interfaces instead of a variety of mapping kludges resources: add io-mapping functions to dynamically map large device apertures x86: add iomap_atomic*()/iounmap_atomic() on 32-bit using fixmaps
2008-11-03io mapping: clean up #ifdefsKeith Packard
Impact: cleanup clean up ifdefs: change #ifdef CONFIG_X86_32/64 to CONFIG_HAVE_ATOMIC_IOMAP. flip around the #ifdef sections to clean up the structure. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-01Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: fix AMDC1E and XTOPOLOGY conflict in cpufeature x86: build fix
2008-11-01x86: Clean up late e820 resource allocationLinus Torvalds
This makes the late e820 resources use 'insert_resource_expand_to_fit()' instead of doing a 'reserve_region_with_split()', and also avoids marking them as IORESOURCE_BUSY. This results in us being perfectly happy to use pre-existing PCI resources even if they were marked as being in a reserved region, while still avoiding any _new_ allocations in the reserved regions. It also makes for a simpler and more accurate resource tree. Example resource allocation from Jonathan Corbet, who has firmware that has an e820 reserved entry that covered a big range (e0000000-fed003ff), and that had various PCI resources in it set up by firmware. With old kernels, the reserved range would force us to re-allocate all pre-existing PCI resources, and his reserved range would end up looking like this: e0000000-fed003ff : reserved fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 where only the pre-allocated special regions (IOAPIC and HPET) were kept around. With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's resource tree looked like this: e0000000-fe7fffff : reserved fe800000-fe8fffff : PCI Bus 0000:01 fe800000-fe8fffff : reserved fe900000-fe9d9aff : reserved fe9d9b00-fe9d9bff : 0000:00:1f.3 fe9d9b00-fe9d9bff : reserved fe9d9c00-fe9d9fff : 0000:00:1a.7 fe9d9c00-fe9d9fff : reserved fe9da000-fe9dafff : 0000:00:03.3 fe9da000-fe9dafff : reserved fe9db000-fe9dbfff : 0000:00:19.0 fe9db000-fe9dbfff : reserved fe9dc000-fe9dffff : 0000:00:1b.0 fe9dc000-fe9dffff : reserved fe9e0000-fe9fffff : 0000:00:19.0 fe9e0000-fe9fffff : reserved fea00000-fea7ffff : 0000:00:02.0 fea00000-fea7ffff : reserved fea80000-feafffff : 0000:00:02.1 fea80000-feafffff : reserved feb00000-febfffff : 0000:00:02.0 feb00000-febfffff : reserved fec00000-fed003ff : reserved fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 and because the reserved entry had been split and moved into the individual resources, and because it used the IORESOURCE_BUSY flag, the drivers that actually wanted to _use_ those resources couldn't actually attach to them: e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff] HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff] with this patch, the resource tree instead becomes e0000000-fed003ff : reserved fe800000-fe8fffff : PCI Bus 0000:01 fe9d9b00-fe9d9bff : 0000:00:1f.3 fe9d9c00-fe9d9fff : 0000:00:1a.7 fe9d9c00-fe9d9fff : ehci_hcd fe9da000-fe9dafff : 0000:00:03.3 fe9db000-fe9dbfff : 0000:00:19.0 fe9db000-fe9dbfff : e1000e fe9dc000-fe9dffff : 0000:00:1b.0 fe9dc000-fe9dffff : ICH HD audio fe9e0000-fe9fffff : 0000:00:19.0 fe9e0000-fe9fffff : e1000e fea00000-fea7ffff : 0000:00:02.0 fea80000-feafffff : 0000:00:02.1 feb00000-febfffff : 0000:00:02.0 fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 ie the one reserved region now ends up surrounding all the PCI resources that were allocated inside of it by firmware, and because it is not marked BUSY, drivers have no problem attaching to the pre-allocated resources. Reported-and-tested-by: Jonathan Corbet <corbet@lwn.net> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Robert Hancock <hancockr@shaw.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-31x86: fix AMDC1E and XTOPOLOGY conflict in cpufeatureVenki Pallipadi
Impact: fix xsave slowdown regression Fix two features from conflicting in feature bits. Fixes this performance regression: Subject: cpu2000(both float and int) 13% regression with 2.6.28-rc1 http://lkml.org/lkml/2008/10/28/36 Reported-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Bisected-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-31x86: add iomap_atomic*()/iounmap_atomic() on 32-bit using fixmapsKeith Packard
Impact: introduce new APIs, separate kmap code from CONFIG_HIGHMEM This takes the code used for CONFIG_HIGHMEM memory mappings except that it's designed for dynamic IO resource mapping. These fixmaps are available even with CONFIG_HIGHMEM turned off. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-31x86: build fixIngo Molnar
Impact: build fix on certain UP configs fix: arch/x86/kernel/cpu/common.c: In function 'cpu_init': arch/x86/kernel/cpu/common.c:1141: error: 'boot_cpu_id' undeclared (first use in this function) arch/x86/kernel/cpu/common.c:1141: error: (Each undeclared identifier is reported only once arch/x86/kernel/cpu/common.c:1141: error: for each function it appears in.) Pull in asm/smp.h on UP, so that we get the definition of boot_cpu_id. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linusLinus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: lguest: fix irq vectors. lguest: fix early_ioremap. lguest: fix example launcher compile after moved asm-x86 dir.
2008-10-30Merge branch 'x86-fixes-for-linus-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: cpu_index build fix x86/voyager: fix missing cpu_index initialisation x86/voyager: fix compile breakage caused by dc1e35c6e95e8923cf1d3510438b63c600fee1e2 x86: fix /dev/mem mmap breakage when PAT is disabled x86/voyager: fix compile breakage casued by x86: move prefill_possible_map calling early x86: use CONFIG_X86_SMP instead of CONFIG_SMP x86/voyager: fix boot breakage caused by x86: boot secondary cpus through initial_code x86, uv: fix compile error in uv_hub.h i386/PAE: fix pud_page() x86: remove debug code from arch_add_memory() x86: start annotating early ioremap pointers with __iomem x86: two trivial sparse annotations x86: fix init_memory_mapping for [dc000000 - e0000000) - v2
2008-10-31lguest: fix irq vectors.Rusty Russell
do_IRQ: cannot handle IRQ -1 vector 0x20 cpu 0 ------------[ cut here ]------------ kernel BUG at arch/x86/kernel/irq_32.c:219! We're not ISA: we have a 1:1 mapping from vectors to irqs. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2008-10-31lguest: fix early_ioremap.Rusty Russell
dmi_scan_machine breaks under lguest: lguest: unhandled trap 14 at 0xc04edeae (0xffa00000) This is because we use current_cr3 for the read_cr3() paravirt function, and it isn't set until the first cr3 change. We got away with it until this happened. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2008-10-31x86: cpu_index build fixIngo Molnar
fix: arch/x86/kernel/cpu/common.c: In function 'early_identify_cpu': arch/x86/kernel/cpu/common.c:553: error: 'struct cpuinfo_x86' has no member named 'cpu_index' as cpu_index is only available on SMP. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-31x86/voyager: fix missing cpu_index initialisationJames Bottomley
Impact: fix /proc/cpuinfo output on x86/Voyager Ever since | commit 92cb7612aee39642d109b8d935ad265e602c0563 | Author: Mike Travis <travis@sgi.com> | Date: Fri Oct 19 20:35:04 2007 +0200 | | x86: convert cpuinfo_x86 array to a per_cpu array We've had an extra field in cpuinfo_x86 which is cpu_index. Unfortunately, voyager has never initialised this, although the only noticeable impact seems to be that /proc/cpuinfo shows all zeros for the processor ids. Anyway, fix this by initialising the boot CPU properly and setting the index when the secondaries update. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-31x86/voyager: fix compile breakage caused by ↵James Bottomley
dc1e35c6e95e8923cf1d3510438b63c600fee1e2 Impact: build fix on x86/Voyager Given commits like this: | Author: Suresh Siddha <suresh.b.siddha@intel.com> | Date: Tue Jul 29 10:29:19 2008 -0700 | | x86, xsave: enable xsave/xrstor on cpus with xsave support Which deliberately expose boot cpu dependence to pieces of the system, I think it's time to explicitly have a variable for it to prevent this continual misassumption that the boot CPU is zero. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30x86: fix /dev/mem mmap breakage when PAT is disabledRavikiran G Thirumalai
Impact: allow /dev/mem mmaps on non-PAT CPUs/platforms Fix mmap to /dev/mem when CONFIG_X86_PAT is off and CONFIG_STRICT_DEVMEM is off mmap to /dev/mem on kernel memory has been failing since the introduction of PAT (CONFIG_STRICT_DEVMEM=n case). Seems like the check to avoid cache aliasing with PAT is kicking in even when PAT is disabled. The bug seems to have crept in 2.6.26. This patch makes sure that the mmap to regular kernel memory succeeds if CONFIG_STRICT_DEVMEM=n and PAT is disabled, and the checks to avoid cache aliasing still happens if PAT is enabled. Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org> Tested-by: Tim Sirianni <tim@scalemp.com> Cc: <stable@kernel.org> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30x86/voyager: fix compile breakage casued by x86: move prefill_possible_map ↵James Bottomley
calling early Impact: fix build failure on x86/Voyager Before: | commit 329513a35d1a2b6b28d54f5c2c0dde4face8200b | Author: Yinghai Lu <yhlu.kernel@gmail.com> | Date: Wed Jul 2 18:54:40 2008 -0700 | | x86: move prefill_possible_map calling early prefill_possible_mask() was hidden under CONFIG_HOTPLUG_CPU rendering it invisitble to voyager. Since this commit it's exposed, but not provided by the voyager subarch, so add a dummy stub to fix the link breakage. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30x86: use CONFIG_X86_SMP instead of CONFIG_SMPJames Bottomley
Impact: fix x86/Voyager boot CONFIG_SMP is used for features which work on *all* x86 boxes. CONFIG_X86_SMP is used for standard PC like x86 boxes (for things like multi core and apics) Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30x86/voyager: fix boot breakage caused by x86: boot secondary cpus through ↵James Bottomley
initial_code Impact: boot up secondary CPUs as well on x86/Voyager systems This commit: | commit 3e9704739daf46a8ba6593d749c67b5f7cd633d2 | Author: Glauber Costa <gcosta@redhat.com> | Date: Wed May 28 13:01:54 2008 -0300 | | x86: boot secondary cpus through initial_code removed the use of initialize_secondary. However, it didn't update voyager, so the secondary cpus no longer boot. Fix this by adding the initial_code switch to voyager as well. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, gart: fix gart detection for Fam11h CPUs x86: 64 bit print out absent pages num too x86, kdump: fix invalid access on i386 sparsemem x86: fix APIC_DEBUG with inquire_remote_apic x86: AMD microcode patch loader author update x86: microcode patch loader author update mailmap: add Peter Oruba x86, bts: improve help text for BTS config doc/x86: fix doc subdirs
2008-10-30Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: x86/PCI: build failure at x86/kernel/pci-dma.c with !CONFIG_PCI
2008-10-30x86, uv: fix compile error in uv_hub.hMike Travis
Impact: include file dependency cleanup Fix compile errors of files that include asm/uv/uv_hub.h but do not include linux/timer.h. [ such files are not mainline right now. ] Signed-of-by: Mike Travis <travis@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-30.gitignore updatesAlexey Dobriyan
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-30i386/PAE: fix pud_page()Jan Beulich
Impact: cleanup To the unsuspecting user it is quite annoying that this broken and inconsistent with x86-64 definition still exists. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-29x86: remove debug code from arch_add_memory()Gary Hade
Impact: remove incorrect WARN_ON(1) Gets rid of dmesg spam created during physical memory hot-add which will very likely confuse users. The change removes what appears to be debugging code which I assume was unintentionally included in: x86: arch/x86/mm/init_64.c printk fixes commit 10f22dde556d1ed41d55355d1fb8ad495f9810c8 Signed-off-by: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-29x86: start annotating early ioremap pointers with __iomemHarvey Harrison
Impact: some new sparse warnings in e820.c etc, but no functional change. As with regular ioremap, iounmap etc, annotate with __iomem. Fixes the following sparse warnings, will produce some new ones elsewhere in arch/x86 that will get worked out over time. arch/x86/mm/ioremap.c:402:9: warning: cast removes address space of expression arch/x86/mm/ioremap.c:406:10: warning: cast adds address space to expression (<asn:2>) arch/x86/mm/ioremap.c:782:19: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-29x86: two trivial sparse annotationsHarvey Harrison
Impact: fewer sparse warnings, no functional changes arch/x86/kernel/vsmp_64.c:87:14: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/vsmp_64.c:87:14: expected void const volatile [noderef] <asn:2>*addr arch/x86/kernel/vsmp_64.c:87:14: got void *[assigned] address arch/x86/kernel/vsmp_64.c:88:22: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/vsmp_64.c:88:22: expected void const volatile [noderef] <asn:2>*addr arch/x86/kernel/vsmp_64.c:88:22: got void * arch/x86/kernel/vsmp_64.c:100:23: warning: incorrect type in argument 2 (different address spaces) arch/x86/kernel/vsmp_64.c:100:23: expected void volatile [noderef] <asn:2>*addr arch/x86/kernel/vsmp_64.c:100:23: got void * arch/x86/kernel/vsmp_64.c:101:23: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/vsmp_64.c:101:23: expected void const volatile [noderef] <asn:2>*addr arch/x86/kernel/vsmp_64.c:101:23: got void * arch/x86/mm/gup.c:235:6: warning: incorrect type in argument 1 (different base types) arch/x86/mm/gup.c:235:6: expected void const volatile [noderef] <asn:1>*<noident> arch/x86/mm/gup.c:235:6: got unsigned long [unsigned] [assigned] start Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86: fix init_memory_mapping for [dc000000 - e0000000) - v2Yinghai Lu
Impact: change over-mapping to precise mapping, fix /proc/meminfo output v2: fix less than 1G ram system handling when gart aperture is 0xdc000000 - 0xe0000000 it return 0xc0000000 - 0xe0000000 that is not right. this patch fix that will get exact mapping on 256g sytem with that aperture after patch LBSuse:~ # cat /proc/meminfo MemTotal: 264742432 kB MemFree: 263920628 kB Buffers: 1416 kB Cached: 24468 kB ... DirectMap4k: 5760 kB DirectMap2M: 3205120 kB DirectMap1G: 265289728 kB it is consistent to LBSuse:~ # cat /sys/kernel/debug/kernel_page_tables .. ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff880000200000 2M RW GLB x pte 0xffff880000200000-0xffff880040000000 1022M RW PSE GLB x pmd 0xffff880040000000-0xffff8800c0000000 2G RW PSE GLB NX pud 0xffff8800c0000000-0xffff8800d7e00000 382M RW PSE GLB NX pmd 0xffff8800d7e00000-0xffff8800d7fa0000 1664K RW GLB NX pte 0xffff8800d7fa0000-0xffff8800d8000000 384K pte 0xffff8800d8000000-0xffff8800dc000000 64M pmd 0xffff8800dc000000-0xffff8800e0000000 64M RW PSE GLB NX pmd 0xffff8800e0000000-0xffff880100000000 512M pmd 0xffff880100000000-0xffff880800000000 28G RW PSE GLB NX pud 0xffff880800000000-0xffff880824600000 582M RW PSE GLB NX pmd 0xffff880824600000-0xffff8808247f0000 1984K RW GLB NX pte 0xffff8808247f0000-0xffff880824800000 64K RW PCD GLB NX pte 0xffff880824800000-0xffff880840000000 440M RW PSE GLB NX pmd 0xffff880840000000-0xffff884000000000 223G RW PSE GLB NX pud 0xffff884000000000-0xffff884028000000 640M RW PSE GLB NX pmd 0xffff884028000000-0xffff884040000000 384M pmd 0xffff884040000000-0xffff888000000000 255G pud 0xffff888000000000-0xffffc20000000000 58880G pgd Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28Merge branch 'tracing-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (31 commits) ftrace: fix current_tracer error return tracing: fix a build error on alpha ftrace: use a real variable for ftrace_nop in x86 tracing/ftrace: make boot tracer select the sched_switch tracer tracepoint: check if the probe has been registered asm-generic: define DIE_OOPS in asm-generic trace: fix printk warning for u64 ftrace: warning in kernel/trace/ftrace.c ftrace: fix build failure ftrace, powerpc, sparc64, x86: remove notrace from arch ftrace file ftrace: remove ftrace hash ftrace: remove mcount set ftrace: remove daemon ftrace: disable dynamic ftrace for all archs that use daemon ftrace: add ftrace warn on to disable ftrace ftrace: only have ftrace_kill atomic ftrace: use probe_kernel ftrace: comment arch ftrace code ftrace: return error on failed modified text. ftrace: dynamic ftrace process only text section ...
2008-10-28Merge branch 'kvm-updates/2.6.28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm * 'kvm-updates/2.6.28' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm: KVM: ia64: Makefile fix for forcing to re-generate asm-offsets.h KVM: Future-proof device assignment ABI KVM: ia64: Fix halt emulation logic KVM: Fix guest shared interrupt with in-kernel irqchip KVM: MMU: sync root on paravirt TLB flush
2008-10-28Merge branch 'core-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: lockdep: fix irqs on/off ip tracing lockdep: minor fix for debug_show_all_locks() x86: restore the old swiotlb alloc_coherent behavior x86: use GFP_DMA for 24bit coherent_dma_mask swiotlb: remove panic for alloc_coherent failure xen: compilation fix of drivers/xen/events.c on IA64 xen: portability clean up and some minor clean up for xencomm.c xen: don't reload cr3 on suspend kernel/resource: fix reserve_region_with_split() section mismatch printk: remove unused code from kernel/printk.c
2008-10-28x86, gart: fix gart detection for Fam11h CPUsJoerg Roedel
Impact: fix AMD Family 11h boot hangs / USB device problems The AMD Fam11h CPUs have a K8 northbridge. This northbridge is different from other family's because it lacks GART support (as I just learned). But the kernel implicitly expects a GART if it finds an AMD northbridge. Fix this by removing the Fam11h northbridge id from the scan list of K8 northbridges. This patch also changes the message in the GART driver about missing K8 northbridges to tell that the GART is missing which is the correct information in this case. Reported-by: Jouni Malinen <jkmalinen@gmail.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86: 64 bit print out absent pages num tooYinghai Lu
so users are not confused with memhole causing big total ram we don't need to worry about 32 bit, because memhole is always above max_low_pfn. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86, kdump: fix invalid access on i386 sparsememKen'ichi Ohmichi
Impact: fix kdump crash on 32-bit sparsemem kernels Since linux-2.6.27, kdump has failed on i386 sparsemem kernel. 1st-kernel gets a panic just before switching to 2nd-kernel. The cause is that a kernel accesses invalid mem_section by page_to_pfn(image->swap_page) at machine_kexec(). image->swap_page is allocated if kexec for hibernation, but it is not allocated if kdump. So if kdump, a kernel should not access the mem_section corresponding to image->swap_page. The attached patch fixes this invalid access. Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp> Cc: kexec-ml <kexec@lists.infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86: fix APIC_DEBUG with inquire_remote_apicYinghai Lu
APIC_DEBUG is always 2. need to update inquire_remote_apic to check apic_verbosity with it instead. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86: AMD microcode patch loader author updatePeter Oruba
Removed author's email address from MODULE_AUTHOR. Signed-off-by: Peter Oruba <peter.oruba@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86: microcode patch loader author updatePeter Oruba
Removed one author's email address from module init message. Signed-off-by: Peter Oruba <peter.oruba@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28x86, bts: improve help text for BTS configMarkus Metzger
Improve the help text of the X86_PTRACE_BTS config. Make X86_DS invisible and depend on X86_PTRACE_BTS. Reported-by: Roland Dreier <rdreier@cisco.com> Signed-off-by: Markus Metzger <markus.t.metzger@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-28KVM: Fix guest shared interrupt with in-kernel irqchipSheng Yang
Every call of kvm_set_irq() should offer an irq_source_id, which is allocated by kvm_request_irq_source_id(). Based on irq_source_id, we identify the irq source and implement logical OR for shared level interrupts. The allocated irq_source_id can be freed by kvm_free_irq_source_id(). Currently, we support at most sizeof(unsigned long) different irq sources. [Amit: - rebase to kvm.git HEAD - move definition of KVM_USERSPACE_IRQ_SOURCE_ID to common file - move kvm_request_irq_source_id to the update_irq ioctl] [Xiantao: - Add kvm/ia64 stuff and make it work for kvm/ia64 guests] Signed-off-by: Sheng Yang <sheng@linux.intel.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com> Signed-off-by: Avi Kivity <avi@redhat.com>
2008-10-28KVM: MMU: sync root on paravirt TLB flushMarcelo Tosatti
The pvmmu TLB flush handler should request a root sync, similarly to a native read-write CR3. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
2008-10-28x86, memory hotplug: remove wrong -1 in calling init_memory_mapping()Shaohua Li
Impact: fix crash with memory hotplug Shuahua Li found: | I just did some experiments on a desktop for memory hotplug and this bug | triggered a crash in my test. | | Yinghai's suggestion also fixed the bug. We don't need to round it, just remove that extra -1 Signed-off-by: Yinghai <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-27x86: keep the /proc/meminfo page count correctYinghai Lu
Impact: get correct page count in /proc/meminfo found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4 # cat /proc/meminfo MemTotal: 1017508 kB MemFree: 822700 kB Buffers: 1456 kB Cached: 26632 kB SwapCached: 0 kB ... Hugepagesize: 2048 kB DirectMap4k: 4032 kB DirectMap2M: 18446744073709549568 kB with this patch get: ... DirectMap4k: 4032 kB DirectMap2M: 1044480 kB which is consistent to kernel_page_tables ---[ Low Kernel Mapping ]--- 0xffff880000000000-0xffff880000001000 4K RW PCD GLB x pte 0xffff880000001000-0xffff88000009f000 632K RW GLB x pte 0xffff88000009f000-0xffff8800000a0000 4K RW PCD GLB x pte 0xffff8800000a0000-0xffff880000200000 1408K RW GLB x pte 0xffff880000200000-0xffff88003fe00000 1020M RW PSE GLB x pmd 0xffff88003fe00000-0xffff88003fff0000 1984K RW GLB NX pte 0xffff88003fff0000-0xffff880040000000 64K pte 0xffff880040000000-0xffff888000000000 511G pud 0xffff888000000000-0xffffc20000000000 58880G pgd Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-27ftrace: use a real variable for ftrace_nop in x86Steven Rostedt
Impact: avoid section mismatch warning, clean up The dynamic ftrace determines which nop is safe to use at start up. When it finds a safe nop for patching, it sets a pointer called ftrace_nop to point to the code. All call sites are then patched to this nop. Later, when tracing is turned on, this ftrace_nop variable is again used to compare the location to make sure it is a nop before we update it to an mcount call. If this fails just once, a warning is printed and ftrace is disabled. Rakib Mullick noted that the code that sets up the nop is a .init section where as the nop itself is in the .text section. This is needed because the nop is used later on after boot up. The problem is that the test of the nop jumps back to the setup code and causes a "section mismatch" warning. Rakib first recommended to convert the nop to .init.text, but as stated above, this would fail since that text is used later. The real solution is to extend Rabik's patch, and to make the ftrace_nop into an array, and just save the code from the assembly to this array. Now the section can stay as an init section, and we have a nop to use later on. Reported-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-27x86/uv: memory allocation at initializationCliff Wickman
Impact: on SGI UV platforms, fix boot crash UV initialization is currently called too late to call alloc_bootmem_pages(). The current sequence is: start_kernel() mem_init() free_all_bootmem() <--- discard of bootmem rest_init() kernel_init() smp_prepare_cpus() native_smp_prepare_cpus() uv_system_init() <--- uses alloc_bootmem_pages() It should be calling kmalloc(). Signed-off-by: Cliff Wickman <cpw@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-27xen: fix Xen domU boot with batched mprotectChris Lalancette
Impact: fix guest kernel boot crash on certain configs Recent i686 2.6.27 kernels with a certain amount of memory (between 736 and 855MB) have a problem booting under a hypervisor that supports batched mprotect (this includes the RHEL-5 Xen hypervisor as well as any 3.3 or later Xen hypervisor). The problem ends up being that xen_ptep_modify_prot_commit() is using virt_to_machine to calculate which pfn to update. However, this only works for pages that are in the p2m list, and the pages coming from change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because of this, we can run into the situation where the lookup in the p2m table returns an INVALID_MFN, which we then try to pass to the hypervisor, which then (correctly) denies the request to a totally bogus pfn. The right thing to do is to use arbitrary_virt_to_machine, so that we can be sure we are modifying the right pfn. This unfortunately introduces a performance penalty because of a full page-table-walk, but we can avoid that penalty for pages in the p2m list by checking if virt_addr_valid is true, and if so, just doing the lookup in the p2m table. The attached patch implements this, and allows my 2.6.27 i686 based guest with 768MB of memory to boot on a RHEL-5 hypervisor again. Thanks to Jeremy for the suggestions about how to fix this particular issue. Signed-off-by: Chris Lalancette <clalance@redhat.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Chris Lalancette <clalance@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-27Merge commit 'v2.6.28-rc2' into tracing/urgentIngo Molnar
2008-10-24x86/PCI: build failure at x86/kernel/pci-dma.c with !CONFIG_PCIFenghua Yu
On Thu, Oct 23, 2008 at 04:09:52PM -0700, Alexander Beregalov wrote: > arch/x86/kernel/built-in.o: In function `iommu_setup': > pci-dma.c:(.init.text+0x36ad): undefined reference to `forbid_dac' > pci-dma.c:(.init.text+0x36cc): undefined reference to `forbid_dac' > pci-dma.c:(.init.text+0x3711): undefined reference to `forbid_dac This patch partially reverts a patch to add IOMMU support to ia64. The forbid_dac variable was incorrectly moved to quirks.c, which isn't built when PCI is disabled. Tested-by: "Alexander Beregalov" <a.beregalov@gmail.com> Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-10-23x86: restore the old swiotlb alloc_coherent behaviorFUJITA Tomonori
This restores the old swiotlb alloc_coherent behavior (before the alloc_coherent rewrite): http://lkml.org/lkml/2008/8/12/200 The old alloc_coherent avoids GFP_DMA allocation first and if the allocated address is not fit for the device's coherent_dma_mask, then dma_alloc_coherent does GFP_DMA allocation. If it fails, alloc_coherent calls swiotlb_alloc_coherent (in short, we rarely used swiotlb_alloc_coherent). After the alloc_coherent rewrite, dma_alloc_coherent (include/asm-x86/dma-mapping.h) directly calls swiotlb_alloc_coherent. It means that we possibly can't handle a device having dma_masks > 24bit < 32bits since swiotlb_alloc_coherent doesn't have the above GFP_DMA retry mechanism. This patch fixes x86's swiotlb alloc_coherent to use the GFP_DMA retry mechanism, which dma_generic_alloc_coherent() provides now (pci-nommu.c and GART IOMMU driver also use dma_generic_alloc_coherent). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-23x86: use GFP_DMA for 24bit coherent_dma_maskFUJITA Tomonori
dma_alloc_coherent (include/asm-x86/dma-mapping.h) avoids GFP_DMA allocation first and if the allocated address is not fit for the device's coherent_dma_mask, then dma_alloc_coherent does GFP_DMA allocation. This is because dma_alloc_coherent avoids precious GFP_DMA zone if possible. This is also how the old dma_alloc_coherent (arch/x86/kernel/pci-dma.c) works. However, if the coherent_dma_mask of a device is 24bit, there is no point to go into the above GFP_DMA retry mechanism. We had better use GFP_DMA in the first place. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-23Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: fix section mismatch warning - apic_x2apic_phys x86: fix section mismatch warning - apic_x2apic_cluster x86: fix section mismatch warning - apic_x2apic_uv_x x86: fix section mismatch warning - apic_physflat x86: fix section mismatch warning - apic_flat x86: memtest fix use of reserve_early() x86 syscall.h: fix argument order x86/tlb_uv: remove strange mc146818rtc include x86: remove redundant KERN_DEBUG on pr_debug x86: do_boot_cpu - check if we have ESR register x86: MAINTAINERS change for AMD microcode patch loader x86/proc: fix /proc/cpuinfo cpu offline bug x86: call dmi-quirks for HP Laptops after early-quirks are executed x86, kexec: fix hang on i386 when panic occurs while console_sem is held MCE: Don't run 32bit machine checks with interrupts on x86: SB600: skip IRQ0 override if it is not routed to INT2 of IOAPIC x86: make variables static
2008-10-23Merge branch 'proc' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/adobriyan/proc * 'proc' of git://git.kernel.org/pub/scm/linux/kernel/git/adobriyan/proc: (35 commits) proc: remove fs/proc/proc_misc.c proc: move /proc/vmcore creation to fs/proc/vmcore.c proc: move pagecount stuff to fs/proc/page.c proc: move all /proc/kcore stuff to fs/proc/kcore.c proc: move /proc/schedstat boilerplate to kernel/sched_stats.h proc: move /proc/modules boilerplate to kernel/module.c proc: move /proc/diskstats boilerplate to block/genhd.c proc: move /proc/zoneinfo boilerplate to mm/vmstat.c proc: move /proc/vmstat boilerplate to mm/vmstat.c proc: move /proc/pagetypeinfo boilerplate to mm/vmstat.c proc: move /proc/buddyinfo boilerplate to mm/vmstat.c proc: move /proc/vmallocinfo to mm/vmalloc.c proc: move /proc/slabinfo boilerplate to mm/slub.c, mm/slab.c proc: move /proc/slab_allocators boilerplate to mm/slab.c proc: move /proc/interrupts boilerplate code to fs/proc/interrupts.c proc: move /proc/stat to fs/proc/stat.c proc: move rest of /proc/partitions code to block/genhd.c proc: move /proc/cpuinfo code to fs/proc/cpuinfo.c proc: move /proc/devices code to fs/proc/devices.c proc: move rest of /proc/locks to fs/locks.c ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 05:51:20 +0000