- 12 12月, 2008 1 次提交
-
-
由 Hiroshi Shimamoto 提交于
Impact: cleanup Introduce inc_irq_stat() macro and unify irq_stat accounting code. Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 12月, 2008 6 次提交
-
-
由 Ingo Molnar 提交于
these warnings: arch/x86/kernel/paravirt-spinlocks.c: In function ‘default_spin_lock_flags’: arch/x86/kernel/paravirt-spinlocks.c:12: warning: passing argument 1 of ‘__raw_spin_lock’ from incompatible pointer type arch/x86/kernel/paravirt-spinlocks.c: At top level: arch/x86/kernel/paravirt-spinlocks.c:11: warning: ‘default_spin_lock_flags’ defined but not used showed that the prototype of default_spin_lock_flags() was confused about what type spinlocks have. the proper type on UP is raw_spinlock_t. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Joerg Roedel 提交于
Impact: minor fix Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
Impact: minor fix Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
Impact: cleanup Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
Impact: bugfix Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg Roedel 提交于
Impact: bugfix in iommu_map_page function Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
- 04 12月, 2008 2 次提交
-
-
由 Andi Kleen 提交于
Impact: fix boot crash with numcpus=0 on certain systems Fix early exception in __get_smp_config with nosmp. Bail out early when there is no MP table. Reported-by: NWu Fengguang <fengguang.wu@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Tested-by: NWu Fengguang <fengguang.wu@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 William 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: NWilliam Cohen <wcohen@redhat.com> Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
- 03 12月, 2008 5 次提交
-
-
由 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: NEric Dumazet <dada1@cosmosbay.com> Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
由 Joerg 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: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg 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: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Richard 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: NRichard Kennedy <richard@rsk.demon.co.uk> Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Joerg 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: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 01 12月, 2008 6 次提交
-
-
由 Mahesh 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: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Acked-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Christoph 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: NChristoph Hellwig <hch@lst.de> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Al Viro 提交于
... so get xen-ops.h in agreement with xen/smp.c Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Al Viro 提交于
calls __init, called only from __init Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 11月, 2008 1 次提交
-
-
由 Thomas 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: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 28 11月, 2008 3 次提交
-
-
由 Ingo 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: NCyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Tested-by: NCyrill Gorcunov <gorcunov@gmail.com>
-
由 Cyrill Gorcunov 提交于
Impact: cleanup Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Cyrill Gorcunov 提交于
Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Acked-by: NCliff Wickman <cpw@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 27 11月, 2008 5 次提交
-
-
由 Cyrill Gorcunov 提交于
child_rip is called not by its name but indirectly rather so make it global and aligned. Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Acked-by: NAlexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 gorcunov@gmail.com 提交于
Impact: cleanup Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Acked-by: NAlexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Joerg 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: NJoerg Roedel <joerg.roedel@amd.com> Cc: <stable@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Alexander 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: NAlexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Alexander 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: NAlexander van Heukelum <heukelum@fastmail.fm> Acked-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 26 11月, 2008 7 次提交
-
-
由 Marcelo Tosatti 提交于
It is possible for a shadow page to have a parent link pointing to a freed page. When zapping a high level table, kvm_mmu_page_unlink_children fails to remove the parent_pte link. For that to happen, the child must be unreachable via the shadow tree, which can happen in shadow_walk_entry if the guest pte was modified in between walk() and fetch(). Remove the parent pte reference in such case. Possible cause for oops in bug #2217430. Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com> Signed-off-by: NAvi Kivity <avi@redhat.com>
-
由 Andreas Herrmann 提交于
Impact: extend allowed configuration space access on 11h CPUs from 256 to 4K Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Andreas Herrmann 提交于
A workaround for AMD CPU family 11h erratum 311 might cause that the P-state Status Register shows a "current P-state" which is larger than the "current P-state limit" in P-state Current Limit Register. For the wrong P-state value there is no ACPI _PSS object defined and powernow-k8/cpufreq can't determine the proper CPU frequency for that state. As a consequence this can cause a panic during boot (potentially with all recent kernel versions -- at least I have reproduced it with various 2.6.27 kernels and with the current .28 series), as an example: powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \ ) powernow-k8: 0 : pstate 0 (2200 MHz) powernow-k8: 1 : pstate 1 (1100 MHz) powernow-k8: 2 : pstate 2 (600 MHz) BUG: unable to handle kernel paging request at ffff88086e7528b8 IP: [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f PGD 202063 PUD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 1 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16 RIP: 0010:[<ffffffff80486361>] [<ffffffff80486361>] cpufreq_stats_update+0x4a/0\ f Synaptics claims to have extended capabilities, but I'm not able to read them.<6\ 6 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0 RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080 R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10 R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000 Unable to initialize Synaptics hardware. CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0) Stack: ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7 ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000 ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10 Call Trace: [<ffffffff804863c7>] ? cpufreq_stat_notifier_trans+0x51/0x83 [<ffffffff8024b46c>] ? notifier_call_chain+0x29/0x4c [<ffffffff8024b561>] ? __srcu_notifier_call_chain+0x46/0x61 [<ffffffff8048496d>] ? cpufreq_notify_transition+0x93/0xa9 [<ffffffff8021ab8d>] ? powernowk8_target+0x1e8/0x5f3 [<ffffffff80486687>] ? cpufreq_governor_performance+0x1b/0x20 [<ffffffff80484886>] ? __cpufreq_governor+0x71/0xa8 [<ffffffff80484b21>] ? __cpufreq_set_policy+0x101/0x13e [<ffffffff80485bcd>] ? cpufreq_add_dev+0x3f0/0x4cd [<ffffffff8048577a>] ? handle_update+0x0/0x8 [<ffffffff803c2062>] ? sysdev_driver_register+0xb6/0x10d [<ffffffff8056592c>] ? powernowk8_init+0x0/0x7e [<ffffffff8048604c>] ? cpufreq_register_driver+0x8f/0x140 [<ffffffff80209056>] ? _stext+0x56/0x14f [<ffffffff802c2234>] ? proc_register+0x122/0x17d [<ffffffff802c23a0>] ? create_proc_entry+0x73/0x8a [<ffffffff8025c259>] ? register_irq_proc+0x92/0xaa [<ffffffff8025c2c8>] ? init_irq_proc+0x57/0x69 [<ffffffff807fc85f>] ? kernel_init+0x116/0x169 [<ffffffff8020cc79>] ? child_rip+0xa/0x11 [<ffffffff807fc749>] ? kernel_init+0x0/0x169 [<ffffffff8020cc6f>] ? child_rip+0x0/0x11 Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\ RIP [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f RSP <ffff88006fb83b20> CR2: ffff88086e7528b8 ---[ end trace 0678bac75e67a2f7 ]--- Kernel panic - not syncing: Attempted to kill init! In short, aftereffect of the wrong P-state is that cpufreq_stats_update() uses "-1" as index for some array in cpufreq_stats_update (unsigned int cpu) { ... if (stat->time_in_state) stat->time_in_state[stat->last_index] = cputime64_add(stat->time_in_state[stat->last_index], cputime_sub(cur_time, stat->last_time)); ... } Fortunately, the wrong P-state value is returned only if the core is in P-state 0. This fix solves the problem by detecting the out-of-range P-state, ignoring it, and using "0" instead. Cc: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Markus Metzger 提交于
Impact: fix sleeping-with-spinlock-held bugs/crashes - Turn a wrmsr to write the DS_AREA MSR into a wrmsrl. - Use irqsave variants of spinlocks. - Do not allocate memory while holding spinlocks. Reported-by: NStephane Eranian <eranian@googlemail.com> Reported-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Markus Metzger 提交于
Impact: fix DS hw enablement on 64-bit x86 Fix the PEBS record size in the DS configuration. Reported-by: NStephane Eranian <eranian@googlemail.com> Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Markus Metzger 提交于
Impact: cleanup Replace a macro with a static inline function. Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Markus Metzger 提交于
Impact: cleanup Move the CONFIG guard from the .c file into the makefile. Reported-by: NAndi Kleen <andi-suse@firstfloor.org> Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 25 11月, 2008 2 次提交
-
-
由 Julia Lawall 提交于
Impact: fix theoretical option string parsing overflow Since bridge is unsigned, it would seem better to use simple_strtoul that simple_strtol. A simplified version of the semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r2@ long e; position p; @@ e = simple_strtol@p(...) @@ position p != r2.p; type T; T e; @@ e = - simple_strtol@p + simple_strtoul (...) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Cc: muli@il.ibm.com Cc: jdmason@kudzu.us Cc: discuss@x86-64.org Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Steven Rostedt 提交于
Impact: build fix with certain compilers GCC can decide to use %dil when "r" is used, which is not valid for setnz. This bug was brought out by Stephen Rothwell's merging of the branch tracer into linux-next. [ Thanks to Uros Bizjak for recommending 'q' over 'Q' ] Signed-off-by: NSteven Rostedt <srostedt@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 24 11月, 2008 2 次提交
-
-
由 jia zhang 提交于
Impact: improve backtrace quality avoid the confusion in call trace because of the lack of padding at the tail of function. When do_exit gets called, the return address behind call instruction is pushed into stack. If something get wrong in do_exit, for x86_64, the entry "kernel_execve +0x00/0xXX" rather than "child_rip +0xYY/0xZZ" is in the call trace. That looks confusing, so add a u2d to make the return address still part of the original call site. (This also catches any instances of us returning from that function somehow.) Signed-off-by: Njia zhang <jia.zhang2008@gmail.com> Acked-by: NAlexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Cyrill Gorcunov 提交于
Impact: make ENTRY()/END() macros more capable It's usefull to catch unbalanced or messed or mixed declarations of ENTRY and KPROBES. These macros would help a bit. For example the following code would compile without problems ENTRY_X86(mcount) retq END_X86(mcount) But if you forget and mess the following form ENTRY_X86(mcount) retq END(mcount) ENTRY_X86(ftrace_caller) The assembler will issue the following message: Error: ENTRY_X86/KPROBE_X86 unbalanced,missed,mixed Actually the checking is performed at every _X86 macro so maybe it's good idea to put ENTRY_KPROBE_FINAL_X86 at the end of .S file to be sure you didn't miss anything. Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Cc: Alexander van Heukelum <heukelum@mailshack.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-