1. 01 7月, 2006 1 次提交
  2. 09 6月, 2006 2 次提交
    • P
      [PATCH] powerpc: Implement PR_[GS]ET_UNALIGN prctls for powerpc · e9370ae1
      Paul Mackerras 提交于
      This gives the ability to control whether alignment exceptions get
      fixed up or reported to the process as a SIGBUS, using the existing
      PR_SET_UNALIGN and PR_GET_UNALIGN prctls.  We do not implement the
      option of logging a message on alignment exceptions.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e9370ae1
    • P
      [PATCH] powerpc: Implement support for setting little-endian mode via prctl · fab5db97
      Paul Mackerras 提交于
      This adds the PowerPC part of the code to allow processes to change
      their endian mode via prctl.
      
      This also extends the alignment exception handler to be able to fix up
      alignment exceptions that occur in little-endian mode, both for
      "PowerPC" little-endian and true little-endian.
      
      We always enter signal handlers in big-endian mode -- the support for
      little-endian mode does not amount to the creation of a little-endian
      user/kernel ABI.  If the signal handler returns, the endian mode is
      restored to what it was when the signal was delivered.
      
      We have two new kernel CPU feature bits, one for PPC little-endian and
      one for true little-endian.  Most of the classic 32-bit processors
      support PPC little-endian, and this is reflected in the CPU feature
      table.  There are two corresponding feature bits reported to userland
      in the AT_HWCAP aux vector entry.
      
      This is based on an earlier patch by Anton Blanchard.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fab5db97
  3. 01 4月, 2006 1 次提交
  4. 28 3月, 2006 1 次提交
  5. 27 3月, 2006 3 次提交
  6. 24 2月, 2006 2 次提交
    • P
      powerpc: Implement accurate task and CPU time accounting · c6622f63
      Paul Mackerras 提交于
      This implements accurate task and cpu time accounting for 64-bit
      powerpc kernels.  Instead of accounting a whole jiffy of time to a
      task on a timer interrupt because that task happened to be running at
      the time, we now account time in units of timebase ticks according to
      the actual time spent by the task in user mode and kernel mode.  We
      also count the time spent processing hardware and software interrupts
      accurately.  This is conditional on CONFIG_VIRT_CPU_ACCOUNTING.  If
      that is not set, we do tick-based approximate accounting as before.
      
      To get this accurate information, we read either the PURR (processor
      utilization of resources register) on POWER5 machines, or the timebase
      on other machines on
      
      * each entry to the kernel from usermode
      * each exit to usermode
      * transitions between process context, hard irq context and soft irq
        context in kernel mode
      * context switches.
      
      On POWER5 systems with shared-processor logical partitioning we also
      read both the PURR and the timebase at each timer interrupt and
      context switch in order to determine how much time has been taken by
      the hypervisor to run other partitions ("steal" time).  Unfortunately,
      since we need values of the PURR on both threads at the same time to
      accurately calculate the steal time, and since we can only calculate
      steal time on a per-core basis, the apportioning of the steal time
      between idle time (time which we ceded to the hypervisor in the idle
      loop) and actual stolen time is somewhat approximate at the moment.
      
      This is all based quite heavily on what s390 does, and it uses the
      generic interfaces that were added by the s390 developers,
      i.e. account_system_time(), account_user_time(), etc.
      
      This patch doesn't add any new interfaces between the kernel and
      userspace, and doesn't change the units in which time is reported to
      userspace by things such as /proc/stat, /proc/<pid>/stat, getrusage(),
      times(), etc.  Internally the various task and cpu times are stored in
      timebase units, but they are converted to USER_HZ units (1/100th of a
      second) when reported to userspace.  Some precision is therefore lost
      but there should not be any accumulating error, since the internal
      accumulation is at full precision.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c6622f63
    • A
      [PATCH] powerpc: Fix runlatch performance issues · cb2c9b27
      Anton Blanchard 提交于
      The runlatch SPR can take a lot of time to write. My original runlatch
      code would set it on every exception entry even though most of the time
      this was not required. It would also continually set it in the idle
      loop, which is an issue on an SMT capable processor.
      
      Now we cache the runlatch value in a threadinfo bit, and only check for
      it in decrementer and hardware interrupt exceptions as well as the idle
      loop. Boot on POWER3, POWER5 and iseries, and compile tested on pmac32.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cb2c9b27
  7. 10 2月, 2006 1 次提交
  8. 13 1月, 2006 2 次提交
  9. 12 1月, 2006 2 次提交
    • P
      powerpc: make ARCH=ppc use arch/powerpc/kernel/process.c · 624cee31
      Paul Mackerras 提交于
      Commit 5388fb10 made signal_32.c
      use discard_lazy_cpu_state, which broke ARCH=ppc because that
      uses the common signal_32.c but has its own process.c.  Make ARCH=ppc
      use the common process.c to fix this and to reduce the amount
      of duplicated code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      624cee31
    • P
      [PATCH] powerpc: Avoid potential FP corruption with preempt and UP · 5388fb10
      Paul Mackerras 提交于
      Heikki Lindholm pointed out that there was a potential race with the
      lazy CPU state (FP, VR, EVR) stuff if preempt is enabled.  The race
      is that in the process of restoring FP state on sigreturn, the task
      gets preempted by a user task that wants to use the FPU.  It will take
      an FP unavailable exception, which will write the current FPU state
      to the thread_struct, overwriting the values which sigreturn has
      stored.  Note that this can only happen on UP since we don't implement
      lazy CPU state on SMP.
      
      The fix is to flush the lazy CPU state before updating the
      thread_struct.  To do this we re-use the flush_lazy_cpu_state()
      function from process.c.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5388fb10
  10. 30 11月, 2005 1 次提交
    • P
      powerpc: Fix bug causing FP registers corruption on UP + preempt · 48abec07
      Paul Mackerras 提交于
      This fixes a bug noticed by Paolo Galtieri and fixed for ARCH=ppc in
      the previous commit (ppc: fix floating point register corruption).
      This fixes the arch/powerpc code by adding preempt_disable/enable,
      and also cleans it up a bit by pulling out the code that discards
      any lazily-switched CPU register state into a new function, rather
      than having that code repeated in three places.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      48abec07
  11. 24 11月, 2005 1 次提交
    • J
      [PATCH] kprobes: Fix return probes on sys_execve · 8bf1101b
      Jim Keniston 提交于
      Fix a bug in kprobes that can cause an Oops or even a crash when a return
      probe is installed on one of the following functions: sys_execve,
      do_execve, load_*_binary, flush_old_exec, or flush_thread.  The fix is to
      remove the call to kprobe_flush_task() in flush_thread().  This fix has
      been tested on all architectures for which the return-probes feature has
      been implemented (i386, x86_64, ppc64, ia64).  Please apply.
      
      BACKGROUND
      
      Up to now, we have called kprobe_flush_task() under two situations: when a
      task exits, and when it execs.  Flushing kretprobe_instances on exit is
      correct because (a) do_exit() doesn't return, and (b) one or more
      return-probed functions may be active when a task calls do_exit().  Neither
      is the case for sys_execve() and its callees.
      
      Initially, the mistaken call to kprobe_flush_task() on exec was harmless
      because we put the "real" return address of each active probed function
      back in the stack, just to be safe, when we recycled its
      kretprobe_instance.  When support for ppc64 and ia64 was added, this safety
      measure couldn't be employed, and was eventually dropped even for i386 and
      x86_64.  sys_execve() and its callees were informally blacklisted for
      return probes until this fix was developed.
      Acked-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8bf1101b
  12. 07 11月, 2005 2 次提交
  13. 03 11月, 2005 1 次提交
  14. 27 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Fix handling of fpscr on 64-bit · 25c8a78b
      David Gibson 提交于
      The recent merge of fpu.S broken the handling of fpscr for
      ARCH=powerpc and CONFIG_PPC64=y.  FP registers could be corrupted,
      leading to strange random application crashes.
      
      The confusion arises, because the thread_struct has (and requires) a
      64-bit area to save the fpscr, because we use load/store double
      instructions to get it in to/out of the FPU.  However, only the low
      32-bits are actually used, so we want to treat it as a 32-bit quantity
      when manipulating its bits to avoid extra load/stores on 32-bit.  This
      patch replaces the current definition with a structure of two 32-bit
      quantities (pad and val), to clarify things as much as is possible.
      The 'val' field is used when manipulating bits, the structure itself
      is used when obtaining the address for loading/unloading the value
      from the FPU.
      
      While we're at it, consolidate the 4 (!) almost identical versions of
      cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
      arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
      arch/powerpc/kernel/misc_64.S) into a single version in fpu.S.  The
      new version takes a pointer to thread_struct and applies the correct
      offset itself, rather than a pointer to the fpscr field itself, again
      to avoid confusion as to which is the correct field to use.
      
      Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
      code, which it previously did not.
      
      Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
      and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
      Booted on G5 (ARCH=powerpc) and things which previously fell over no
      longer do.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      25c8a78b
  15. 21 10月, 2005 1 次提交
  16. 13 10月, 2005 2 次提交
  17. 10 10月, 2005 1 次提交
  18. 01 10月, 2005 1 次提交
  19. 28 9月, 2005 1 次提交
  20. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  21. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4