summaryrefslogtreecommitdiffstats
path: root/arch/x86
AgeCommit message (Collapse)Author
2008-12-03Merge branch 'oprofile-for-tip' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile into x86/urgent
2008-12-03x86/oprofile: fix Intel cpu family 6 detectionWilliam Cohen
Alan Jenkins wrote: > This is on an EeePC 701, /proc/cpuinfo as attached. > > Is this expected? Will the next release work? > > Thanks, Alan > > # opcontrol --setup --no-vmlinux > cpu_type 'unset' is not valid > you should upgrade oprofile or force the use of timer mode > > # opcontrol -v > opcontrol: oprofile 0.9.4 compiled on Nov 29 2008 22:44:10 > > # cat /dev/oprofile/cpu_type > i386/p6 > # uname -r > 2.6.28-rc6eeepc Hi Alan, Looking at the kernel driver code for oprofile it can return the "i386/p6" for the cpu_type. However, looking at the user-space oprofile code there isn't the matching entry in libop/op_cpu_type.c or the events/unit_mask files in events/i386 directory. The Intel AP-485 says this is a "Intel Pentium M processor model D". Seems like the oprofile kernel driver should be identifying the processor as "i386/p6_mobile" The driver identification code doesn't look quite right in nmi_init.c http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=blob;f=arch/x86/oprofile/nmi_int.c;h=022cd41ea9b4106e5884277096e80e9088a7c7a9;hb=HEAD has: 409 case 10 ... 13: 410 *cpu_type = "i386/p6"; 411 break; Referring to the Intel AP-485: case 10 and 11 should produce "i386/piii" case 13 should produce "i386/p6_mobile" I didn't see anything for case 12. Something like the attached patch. I don't have a celeron machine to verify that changes in this area of the kernel fix thing. -Will Signed-off-by: William Cohen <wcohen@redhat.com> Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Robert Richter <robert.richter@amd.com>
2008-12-03oprofile: fix CPU unplug panic in ppro_stop()Eric Dumazet
If oprofile statically compiled in kernel, a cpu unplug triggers a panic in ppro_stop(), because a NULL pointer is dereferenced. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Robert Richter <robert.richter@amd.com>
2008-12-03Merge branch 'iommu-fixes-2.6.28' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/joro/linux-2.6-iommu into x86/urgent
2008-12-03AMD IOMMU: fix possible race while accessing iommu->need_syncJoerg Roedel
The access to the iommu->need_sync member needs to be protected by the iommu->lock. Otherwise this is a possible race condition. Fix it with this patch. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2008-12-03AMD IOMMU: set device table entry for aliased devicesJoerg Roedel
In some rare cases a request can arrive an IOMMU with its originial requestor id even it is aliased. Handle this by setting the device table entry to the same protection domain for the original and the aliased requestor id. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2008-12-03AMD IOMMU: struct amd_iommu remove padding on 64 bitRichard Kennedy
Remove 16 bytes of padding from struct amd_iommu on 64bit builds reducing its size to 120 bytes, allowing it to span one fewer cachelines. Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2008-12-03x86: fix broken flushing in GART nofullflush pathJoerg Roedel
Impact: remove stale IOTLB entries In the non-default nofullflush case the GART is only flushed when next_bit wraps around. But it can happen that an unmap operation unmaps memory which is behind the current next_bit location. If these addresses are reused it may result in stale GART IO/TLB entries. Fix this by setting the GART next_bit always behind an unmapped location. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: add checks on ret stack in function graphSteven Rostedt
Import: robustness checks Add more checks in the function graph code to detect errors and perhaps print out better information if a bug happens. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: function graph return for function entrySteven Rostedt
Impact: feature, let entry function decide to trace or not This patch lets the graph tracer entry function decide if the tracing should be done at the end as well. This requires all function graph entry functions return 1 if it should trace, or 0 if the return should not be traced. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: print real return in dumpstack for function graphSteven Rostedt
Impact: better dumpstack output I noticed in my crash dumps and even in the stack tracer that a lot of functions listed in the stack trace are simply return_to_handler which is ftrace graphs way to insert its own call into the return of a function. But we lose out where the actually function was called from. This patch adds in hooks to the dumpstack mechanism that detects this and finds the real function to print. Both are printed to let the user know that a hook is still in place. This does give a funny side effect in the stack tracer output: Depth Size Location (80 entries) ----- ---- -------- 0) 4144 48 save_stack_trace+0x2f/0x4d 1) 4096 128 ftrace_call+0x5/0x2b 2) 3968 16 mempool_alloc_slab+0x16/0x18 3) 3952 384 return_to_handler+0x0/0x73 4) 3568 -240 stack_trace_call+0x11d/0x209 5) 3808 144 return_to_handler+0x0/0x73 6) 3664 -128 mempool_alloc+0x4d/0xfe 7) 3792 128 return_to_handler+0x0/0x73 8) 3664 -32 scsi_sg_alloc+0x48/0x4a [scsi_mod] As you can see, the real functions are now negative. This is due to them not being found inside the stack. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: add ftrace_graph_stop()Steven Rostedt
Impact: new ftrace_graph_stop function While developing more features of function graph, I hit a bug that caused the WARN_ON to trigger in the prepare_ftrace_return function. Well, it was hard for me to find out that was happening because the bug would not print, it would just cause a hard lockup or reboot. The reason is that it is not safe to call printk from this function. Looking further, I also found that it calls unregister_ftrace_graph, which grabs a mutex and calls kstop machine. This would definitely lock the box up if it were to trigger. This patch adds a fast and safe ftrace_graph_stop() which will stop the function tracer. Then it is safe to call the WARN ON. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: have function graph use mcount caller addressSteven Rostedt
Impact: consistency change for function graph This patch makes function graph record the mcount caller address the same way the function tracer does. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03ftrace: clean up function graph asmSteven Rostedt
Impact: clean up There exists macros for x86 asm to handle x86_64 and i386. This patch updates function graph asm to use them. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03Merge commit 'v2.6.28-rc7'; branch 'x86/dumpstack' into tracing/ftraceIngo Molnar
Merge x86/dumpstack into tracing/ftrace because upcoming ftrace changes depend on cleanups already in x86/dumpstack. Also merge to latest upstream -rc.
2008-12-03x86: remove dead BIO_VMERGE_BOUNDARY definitionFUJITA Tomonori
Impact: cleanup, remove dead code The block layer dropped the virtual merge feature (b8b3e16cfe6435d961f6aaebcfd52a1ff2a988c5). BIO_VMERGE_BOUNDARY definition is meaningless now. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-03Merge branch 'x86/io' into x86/iommuIngo Molnar
Merge x86/io into x86/iommu due to a small patch conflict in io.h.
2008-12-02Merge 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: MMU: avoid creation of unreachable pages in the shadow KVM: ppc: stop leaking host memory on VM exit KVM: MMU: fix sync of ptes addressed at owner pagetable KVM: ia64: Fix: Use correct calling convention for PAL_VPS_RESUME_HANDLER KVM: ia64: Fix incorrect kbuild CFLAGS override KVM: VMX: Fix interrupt loss during race with NMI KVM: s390: Fix problem state handling in guest sigp handler
2008-12-02x86: fix broken flushing in GART nofullflush pathJoerg Roedel
Impact: remove stale IOTLB entries In the non-default nofullflush case the GART is only flushed when next_bit wraps around. But it can happen that an unmap operation unmaps memory which is behind the current next_bit location. If these addresses are reused it may result in stale GART IO/TLB entries. Fix this by setting the GART next_bit always behind an unmapped location. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-02Merge branch 'linus' into cpus4096Ingo Molnar
Conflicts: kernel/trace/ring_buffer.c
2008-12-02x86, apm: remove CONFIG_APM_REAL_MODE_POWER_OFF in favor of a kernel parameterNiels de Vos
Remove CONFIG_APM_REAL_MODE_POWER_OFF like CONFIG_APM_POWER_OFF which has been done for linux-2.2.14pre8 (http://lkml.org/lkml/1999/11/23/3). Re-introducing CONFIG_APM_POWER_OFF got nack-ed. Stephen didn't bother to remove CONFIG_APM_REAL_MODE_POWER_OFF, let's get rid of it now. Reference: http://lkml.org/lkml/2008/5/7/97 Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-02tracing/function-graph-tracer: support for x86-64Frederic Weisbecker
Impact: extend and enable the function graph tracer to 64-bit x86 This patch implements the support for function graph tracer under x86-64. Both static and dynamic tracing are supported. This causes some small CPP conditional asm on arch/x86/kernel/ftrace.c I wanted to use probe_kernel_read/write to make the return address saving/patching code more generic but it causes tracing recursion. That would be perhaps useful to implement a notrace version of these function for other archs ports. Note that arch/x86/process_64.c is not traced, as in X86-32. I first thought __switch_to() was responsible of crashes during tracing because I believed current task were changed inside but that's actually not the case (actually yes, but not the "current" pointer). So I will have to investigate to find the functions that harm here, to enable tracing of the other functions inside (but there is no issue at this time, while process_64.c stays out of -pg flags). A little possible race condition is fixed inside this patch too. When the tracer allocate a return stack dynamically, the current depth is not initialized before but after. An interrupt could occur at this time and, after seeing that the return stack is allocated, the tracer could try to trace it with a random uninitialized depth. It's a prevention, even if I hadn't problems with it. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tim Bird <tim.bird@am.sony.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-01x86: fix dma_mapping_error for 32bit x86, cleanupFUJITA Tomonori
This removes ifdef CONFIG_X86_64 in dma_mapping_error(): 1) Xen people plan to use swiotlb on X86_32 for Dom0 support. swiotlb uses ops->mapping_error so X86_32 also needs to check ops->mapping_error. 2) Removing #ifdef hack is almost always a good thing. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-01Merge branch 'x86/urgent' into x86/iommuIngo Molnar
2008-12-01sched: don't export sched_mc_power_savings in laptopsMahesh Salgaonkar
Impact: do not expose a control that has no effect Fix to prevent sched_mc_power_saving from being exported through sysfs on single-socket systems. (Say multicore single socket (Laptop)) CPU core map of the boot cpu should be equal to possible number of cpus for single socket system. This fix has been developed at FOSS.in kernel workout. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-30Merge branch 'irq-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: irq.h: fix missing/extra kernel-doc genirq: __irq_set_trigger: change pr_warning to pr_debug irq: fix typo x86: apic honour irq affinity which was set in early boot genirq: fix the affinity setting in setup_irq genirq: keep affinities set from userspace across free/request_irq()
2008-11-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: always define DECLARE_PCI_UNMAP* macros x86: fixup config space size of CPU functions for AMD family 11h x86, bts: fix wrmsr and spinlock over kmalloc x86, pebs: fix PEBS record size configuration x86, bts: turn macro into static inline function x86, bts: exclude ds.c from build when disabled arch/x86/kernel/pci-calgary_64.c: change simple_strtol to simple_strtoul x86: use limited register constraint for setnz xen: pin correct PGD on suspend x86: revert irq number limitation x86: fixing __cpuinit/__init tangle, xsave_cntxt_init() x86: fix __cpuinit/__init tangle in init_thread_xstate() oprofile: fix an overflow in ppro code
2008-11-30Merge branch 'fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] powernow-k8: ignore out-of-range PstateStatus value [CPUFREQ] Documentation: Add Blackfin to list of supported processors
2008-11-30remove __ARCH_WANT_COMPAT_SYS_PTRACEChristoph Hellwig
All architectures now use the generic compat_sys_ptrace, as should every new architecture that needs 32bit compat (if we'll ever get another). Remove the now superflous __ARCH_WANT_COMPAT_SYS_PTRACE define, and also kill a comment about __ARCH_SYS_PTRACE that was added after __ARCH_SYS_PTRACE was already gone. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-30xen_play_dead() is __cpuinitAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-30xen_setup_vcpu_info_placement() is not init on x86Al Viro
... so get xen-ops.h in agreement with xen/smp.c Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-30kvm_setup_secondary_clock() is cpuinitAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-30enable_IR_x2apic() needs to be __initAl Viro
calls __init, called only from __init Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-30x86: provide readq()/writeq() on 32-bit too, completeIngo Molnar
if HAVE_READQ/HAVE_WRITEQ are defined, the full range of readq/writeq APIs has to be provided to drivers: drivers/infiniband/hw/amso1100/c2.c: In function 'c2_tx_ring_alloc': drivers/infiniband/hw/amso1100/c2.c:133: error: implicit declaration of function '__raw_writeq' So provide them on 32-bit as well. Also, map all the APIs to the strongest ordering variant. It's way too easy to mess such details up in drivers and the difference between "memory" and "" constrained asm() constructs is in the noise range. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-30x86: provide readq()/writeq() on 32-bit too, cleanupIngo Molnar
Impact: cleanup Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-30x86: provide readq()/writeq() on 32-bit tooHitoshi Mitake
Impact: add new API for drivers Add implementation of readq/writeq to x86_32, and add config value to the x86 architecture to determine existence of readq/writeq. Signed-off-by: Hitoshi Mitake <h.mitake@gmail.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-30x86: intel_cacheinfo, minor show_type cleanupJiri Slaby
Impact: cleanup Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-29x86: fix dma_mapping_error for 32bit x86Thomas Bogendoerfer
Devices like b44 ethernet can't dma from addresses above 1GB. The driver handles this cases by falling back to GFP_DMA allocation. But for detecting the problem it needs to get an indication from dma_mapping_error. The bug is triggered by using a VMSPLIT option of 2G/2G. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-28aperture_64.c: clarify that too small aperture is valid reason for this codePavel Machek
Impact: update comment Clarify that too small aperture is valid reason for this code. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-28x86: ret_from_fork - get rid of jump backIngo Molnar
Impact: remove dead code If we take a closer look at the rff_trace/rff_action ret_from_fork code, we have to realize that it does all the wrong things: for example it checks the TIF flag - while later on jumping back to the ret-from-syscall path - duplicating the check needlessly. But checking for _TIF_SYSCALL_TRACE is completely unnecessary here because we clear that flag for every freshly forked task. So the whole "tracing" code here, for which there is a out of line jump optimization that makes it even harder to read, is in reality completely dead code ... Reported-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Cyrill Gorcunov <gorcunov@gmail.com>
2008-11-28Merge branch 'x86/debug' into x86/irqIngo Molnar
We merge this branch because x86/debug touches code that we started cleaning up in x86/irq. The two branches started out independent, but as unexpected amount of activity went into x86/irq, they became dependent. Resolve that by this cross-merge.
2008-11-28x86: entry_64.S - trivial: space, comments fixupCyrill Gorcunov
Impact: cleanup Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-28x86: uv bau interrupt -- use proper interrupt numberCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Acked-by: Cliff Wickman <cpw@sgi.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-28x86: move GART specific stuff from iommu.h to gart.hJoerg Roedel
Impact: cleanup Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27x86: entry_64.S - use ENTRY to define child_ripCyrill Gorcunov
child_rip is called not by its name but indirectly rather so make it global and aligned. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Acked-by: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27x86: entry_64.S - use X86_EFLAGS_IF instead of hardcoded numbergorcunov@gmail.com
Impact: cleanup Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Acked-by: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27x86: always define DECLARE_PCI_UNMAP* macrosJoerg Roedel
Impact: fix boot crash on AMD IOMMU if CONFIG_GART_IOMMU is off Currently these macros evaluate to a no-op except the kernel is compiled with GART or Calgary support. But we also need these macros when we have SWIOTLB, VT-d or AMD IOMMU in the kernel. Since we always compile at least with SWIOTLB we can define these macros always. This patch is also for stable backport for the same reason the SWIOTLB default selection patch is. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27i386: get rid of the use of KPROBE_ENTRY / KPROBE_ENDAlexander van Heukelum
entry_32.S is now the only user of KPROBE_ENTRY / KPROBE_END, treewide. This patch reorders entry_64.S and explicitly generates a separate section for functions that need the protection. The generated code before and after the patch is equal. The KPROBE_ENTRY and KPROBE_END macro's are removed too. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27x86_64: get rid of the use of KPROBE_ENTRY / KPROBE_ENDAlexander van Heukelum
Impact: clean up assembly macros and annotations - with some object impact entry_64.S is the only user of KPROBE_ENTRY / KPROBE_END on x86_64. This patch reorders entry_64.S and explicitly generates a separate section for functions that need the protection. The generated code before and after the patch is equal. Implicitly changing sections in assembly files makes it more difficult to follow why the assembler is doing certain things. For example, .p2align 5 KPROBE_ENTRY(...) was not doing what you would expect. Other section changes (__ex_table, .fixup, .init.rodata) are done explicitly already. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> Acked-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-27Merge branches 'tracing/blktrace', 'tracing/ftrace', ↵Ingo Molnar
'tracing/function-graph-tracer' and 'tracing/power-tracer' into tracing/core