1. 13 4月, 2010 15 次提交
  2. 09 4月, 2010 6 次提交
  3. 08 4月, 2010 1 次提交
  4. 07 4月, 2010 5 次提交
  5. 06 4月, 2010 5 次提交
  6. 04 4月, 2010 3 次提交
  7. 03 4月, 2010 5 次提交
    • F
      perf: Always build the powerpc perf_arch_fetch_caller_regs version · 6e03bb5a
      Frederic Weisbecker 提交于
      Now that software events use perf_arch_fetch_caller_regs() too, we
      need the powerpc version to be always built.
      
      Fixes the following build error:
      
      	(.text+0x3210): undefined reference to `perf_arch_fetch_caller_regs'
      	(.text+0x3324): undefined reference to `perf_arch_fetch_caller_regs'
      	(.text+0x33bc): undefined reference to `perf_arch_fetch_caller_regs'
      	(.text+0x33ec): undefined reference to `perf_arch_fetch_caller_regs'
      	(.text+0xd4a0): undefined reference to `perf_arch_fetch_caller_regs'
      	arch/powerpc/kernel/built-in.o:(.text+0xd528): more undefined references to `perf_arch_fetch_caller_regs' follow
      	make[1]: *** [.tmp_vmlinux1] Error 1
      	make: *** [sub-make] Error 2
      Reported-by: NMichael Ellerman <michael@ellerman.id.au>
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      6e03bb5a
    • S
      x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards · 472a474c
      Suresh Siddha 提交于
      Jan Grossmann reported kernel boot panic while booting SMP
      kernel on his system with a single core cpu. SMP kernels call
      enable_IR_x2apic() from native_smp_prepare_cpus() and on
      platforms where the kernel doesn't find SMP configuration we
      ended up again calling enable_IR_x2apic() from the
      APIC_init_uniprocessor() call in the smp_sanity_check(). Thus
      leading to kernel panic.
      
      Don't call enable_IR_x2apic() and default_setup_apic_routing()
      from APIC_init_uniprocessor() in CONFIG_SMP case.
      
      NOTE: this kind of non-idempotent and assymetric initialization
      sequence is rather fragile and unclean, we'll clean that up
      in v2.6.35. This is the minimal fix for v2.6.34.
      
      Reported-by: Jan.Grossmann@kielnet.net
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: <jbarnes@virtuousgeek.org>
      Cc: <david.woodhouse@intel.com>
      Cc: <weidong.han@intel.com>
      Cc: <youquan.song@intel.com>
      Cc: <Jan.Grossmann@kielnet.net>
      Cc: <stable@kernel.org> # [v2.6.32.x, v2.6.33.x]
      LKML-Reference: <1270083887.7835.78.camel@sbs-t61.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      472a474c
    • T
      perf, x86: Fix callgraphs of 32-bit processes on 64-bit kernels · 257ef9d2
      Torok Edwin 提交于
      When profiling a 32-bit process on a 64-bit kernel, callgraph tracing
      stopped after the first function, because it has seen a garbage memory
      address (tried to interpret the frame pointer, and return address as a
      64-bit pointer).
      
      Fix this by using a struct stack_frame with 32-bit pointers when the
      TIF_IA32 flag is set.
      
      Note that TIF_IA32 flag must be used, and not is_compat_task(), because
      the latter is only set when the 32-bit process is executing a syscall,
      which may not always be the case (when tracing page fault events for
      example).
      Signed-off-by: NTörök Edwin <edwintorok@gmail.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: x86@kernel.org
      Cc: linux-kernel@vger.kernel.org
      LKML-Reference: <1268820436-13145-1-git-send-email-edwintorok@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      257ef9d2
    • P
      perf, x86: Fix AMD hotplug & constraint initialization · b38b24ea
      Peter Zijlstra 提交于
      Commit 3f6da390 ("perf: Rework and fix the arch CPU-hotplug hooks") moved
      the amd northbridge allocation from CPUS_ONLINE to CPUS_PREPARE_UP
      however amd_nb_id() doesn't work yet on prepare so it would simply bail
      basically reverting to a state where we do not properly track node wide
      constraints - causing weird perf results.
      
      Fix up the AMD NorthBridge initialization code by allocating from
      CPU_UP_PREPARE and installing it from CPU_STARTING once we have the
      proper nb_id. It also properly deals with the allocation failing.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      [ robustify using amd_has_nb() ]
      Signed-off-by: NStephane Eranian <eranian@google.com>
      LKML-Reference: <1269353485.5109.48.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b38b24ea
    • P
      x86: Move notify_cpu_starting() callback to a later stage · 85257024
      Peter Zijlstra 提交于
      Because we need to have cpu identification things done by the time we run
      CPU_STARTING notifiers.
      
      ( This init ordering will be relied on by the next fix. )
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1269353485.5109.48.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      85257024