1. 27 1月, 2009 2 次提交
  2. 21 1月, 2009 4 次提交
    • N
      x86: make UV support configurable · 03b48632
      Nick Piggin 提交于
      Make X86 SGI Ultraviolet support configurable. Saves about 13K of text size
      on my modest config.
      
         text    data     bss     dec     hex filename
      6770537 1158680  694356 8623573  8395d5 vmlinux
      6757492 1157664  694228 8609384  835e68 vmlinux.nouv
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      03b48632
    • I
      x86, mm: move tlb.c to arch/x86/mm/ · 55f4949f
      Ingo Molnar 提交于
      Impact: cleanup
      
      Now that it's unified, move the (SMP) TLB flushing code from arch/x86/kernel/
      to arch/x86/mm/, where it belongs logically.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      55f4949f
    • T
      x86: rename tlb_64.c to tlb.c · 16c2d3f8
      Tejun Heo 提交于
      Impact: file rename
      
      tlb_64.c is now the tlb code for both 32 and 64.  Rename it to tlb.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      16c2d3f8
    • T
      x86: make x86_32 use tlb_64.c · 02cf94c3
      Tejun Heo 提交于
      Impact: less contention when issuing invalidate IPI, cleanup
      
      Make x86_32 use the same tlb code as 64bit.  The 64bit code uses
      multiple IPI vectors for tlb shootdown to reduce contention.  This
      patch makes x86_32 allocate the same 8 IPIs as x86_64 and share the
      code paths.
      
      Note that the usage of asmlinkage is inconsistent for x86_32 and 64
      and calls for further cleanup.  This has been noted with a FIXME
      comment in tlb_64.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      02cf94c3
  3. 18 12月, 2008 1 次提交
  4. 08 12月, 2008 1 次提交
    • F
      tracing/function-graph-tracer: introduce __notrace_funcgraph to filter special functions · 8b96f011
      Frederic Weisbecker 提交于
      Impact: trace more functions
      
      When the function graph tracer is configured, three more files are not
      traced to prevent only four functions to be traced. And this impacts the
      normal function tracer too.
      
      arch/x86/kernel/process_64/32.c:
      
      I had crashes when I let this file traced. After some debugging, I saw
      that the "current" task point was changed inside__swtich_to(), ie:
      "write_pda(pcurrent, next_p);" inside process_64.c Since the tracer store
      the original return address of the function inside current, we had
      crashes. Only __switch_to() has to be excluded from tracing.
      
      kernel/module.c and kernel/extable.c:
      
      Because of a function used internally by the function graph tracer:
      __kernel_text_address()
      
      To let the other functions inside these files to be traced, this patch
      introduces the __notrace_funcgraph function prefix which is __notrace if
      function graph tracer is configured and nothing if not.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b96f011
  5. 02 12月, 2008 1 次提交
    • F
      tracing/function-graph-tracer: support for x86-64 · 48d68b20
      Frederic 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: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tim Bird <tim.bird@am.sony.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      48d68b20
  6. 26 11月, 2008 3 次提交
  7. 11 11月, 2008 1 次提交
    • F
      tracing, x86: add low level support for ftrace return tracing · caf4b323
      Frederic Weisbecker 提交于
      Impact: add infrastructure for function-return tracing
      
      Add low level support for ftrace return tracing.
      
      This plug-in stores return addresses on the thread_info structure of
      the current task.
      
      The index of the current return address is initialized when the task
      is the first one (init) and when a process forks (the child). It is
      not needed when a task does a sys_execve because after this syscall,
      it still needs to return on the kernel functions it called.
      
      Note that the code of return_to_handler has been suggested by Steven
      Rostedt as almost all of the ideas of improvements in this V3.
      
      For purpose of security, arch/x86/kernel/process_32.c is not traced
      because __switch_to() changes the current task during its execution.
      That could cause inconsistency in the stored return address of this
      function even if I didn't have any crash after testing with tracing on
      this function enabled.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      caf4b323
  8. 04 11月, 2008 1 次提交
  9. 28 10月, 2008 3 次提交
  10. 23 10月, 2008 1 次提交
  11. 21 10月, 2008 1 次提交
  12. 16 10月, 2008 5 次提交
  13. 13 10月, 2008 3 次提交
  14. 23 9月, 2008 1 次提交
  15. 04 9月, 2008 1 次提交
  16. 31 7月, 2008 1 次提交
  17. 29 7月, 2008 4 次提交
    • P
      x86: AMD microcode patch loading support · 80cc9f10
      Peter Oruba 提交于
      This patch introduces microcode patch loading for AMD
      processors. It is based on previous corresponding work
      for Intel processors.
      
      It hooks into the general patch loading module. Main
      difference is that a container file format is used to hold
      all patch data for multiple processors as well as an
      equivalent CPU table, which comes seperately, as opposed
      to Intel's microcode patching solution.
      
      Kconfig and Makefile have been changed provice config
      and build option for new source file.
      Signed-off-by: NPeter Oruba <peter.oruba@amd.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      80cc9f10
    • P
      x86: major refactoring · 8d86f390
      Peter Oruba 提交于
      Refactored code by introducing a two-module solution.
      
      There is one general module in which vendor specific modules can hook into.
      However, that is exclusive, there is only one vendor specific module
      allowed at a time. A CPU vendor check makes sure only the correct
      module for the underlying system gets called.
      
      Functinally in terms of patch loading itself there are no changes. This
      refactoring provides a basis for future implementations of other vendors'
      patch loaders.
      Signed-off-by: NPeter Oruba <peter.oruba@amd.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d86f390
    • P
      x86: code split to two parts · 3e135d88
      Peter Oruba 提交于
      Split off existing code into two seperate files. One file holds general
      code, the other file vendor specific parts.
      
      No functional changes, only refactoring.
      
      Temporarily Introduced a new module name 'ucode' for result,
      due to already taken name 'microcode'.
      Signed-off-by: NPeter Oruba <peter.oruba@amd.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3e135d88
    • P
      x86: move microcode.c to microcode_intel.c · 1abae310
      Peter Oruba 提交于
      Signed-off-by: NPeter Oruba <peter.oruba@amd.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1abae310
  18. 24 7月, 2008 1 次提交
  19. 18 7月, 2008 1 次提交
    • R
      x86 BIOS interface for RTC on SGI UV · 7019cc2d
      Russ Anderson 提交于
      Real-time code needs to know the number of cycles per second
      on SGI UV.  The information is provided via a run time BIOS
      call.  This patch provides the linux side of that interface.
      This is the first of several run time BIOS calls to be defined
      in uv/bios.h and bios_uv.c.
      
      Note that BIOS_CALL() is just a stub for now.  The bios
      side is being worked on.
      Signed-off-by: NRuss Anderson <rja@sgi.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7019cc2d
  20. 17 7月, 2008 1 次提交
    • I
      ftrace: fix merge buglet · 8e9509c8
      Ingo Molnar 提交于
      -tip testing found a bootup hang here:
      
        initcall anon_inode_init+0x0/0x130 returned 0 after 0 msecs
        calling  acpi_event_init+0x0/0x57
      
      the bootup should have continued with:
      
        initcall acpi_event_init+0x0/0x57 returned 0 after 45 msecs
      
      but it hung hard there instead.
      
      bisection led to this commit:
      
      | commit 5806b81a
      | Merge: d14c8a68... 6712e299...
      | Author: Ingo Molnar <mingo@elte.hu>
      | Date:   Mon Jul 14 16:11:52 2008 +0200
      |     Merge branch 'auto-ftrace-next' into tracing/for-linus
      
      turns out that i made this mistake in the merge:
      
        ifdef CONFIG_FTRACE
        # Do not profile debug utilities
        CFLAGS_REMOVE_tsc_64.o = -pg
        CFLAGS_REMOVE_tsc_32.o = -pg
      
      those two files got unified meanwhile - so the dont-profile annotation
      got lost. The proper rule is:
      
        CFLAGS_REMOVE_tsc.o = -pg
      
      i guess this could have been caught sooner if the CFLAGS_REMOVE* kbuild
      rule aborted the build if it met a target that does not exist anymore?
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8e9509c8
  21. 16 7月, 2008 1 次提交
    • I
      x86, paravirt-spinlocks: fix boot hang · 34646bca
      Ingo Molnar 提交于
      the paravirt-spinlock patches caused a boot hang with this config:
      
       http://redhat.com/~mingo/misc/config-Wed_Jul__9_14_47_04_CEST_2008.bad
      
      i have bisected it down to:
      
      |  commit e17b58c2e85bc2ad2afc07fb8d898017c2b75ed1
      |  Author: Jeremy Fitzhardinge <jeremy@goop.org>
      |  Date:   Mon Jul 7 12:07:53 2008 -0700
      |
      |      xen: implement Xen-specific spinlocks
      
      i.e. applying that patch alone causes the hang. The hang happens in the
      ftrace self-test:
      
        initcall utsname_sysctl_init+0x0/0x19 returned 0 after 0 msecs
        calling  init_sched_switch_trace+0x0/0x4c
        Testing tracer sched_switch: PASSED
        initcall init_sched_switch_trace+0x0/0x4c returned 0 after 167 msecs
        calling  init_function_trace+0x0/0x12
        Testing tracer ftrace:
        [hard hang]
      
      it should have continued like this:
      
        Testing tracer ftrace: PASSED
        initcall init_function_trace+0x0/0x12 returned 0 after 198 msecs
        calling  init_irqsoff_tracer+0x0/0x14
        Testing tracer irqsoff: PASSED
        initcall init_irqsoff_tracer+0x0/0x14 returned 0 after 3 msecs
        calling  init_mmio_trace+0x0/0x12
        initcall init_mmio_trace+0x0/0x12 returned 0 after 0 msecs
      
      the problem is that such lowlevel primitives as spinlocks should never
      be built with -pg (which ftrace does). Marking paravirt.o as non-pg and
      marking all spinlock ops as always-inline solve the hang.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      34646bca
  22. 12 7月, 2008 2 次提交