linux.git/arch/powerpc/kernel/process.c, branch v2.6.24

[POWERPC] Fix hardware IRQ time accounting problem.

2007-12-06T05:08:59+00:00

The commit fa13a5a1f25f671d084d8884be96fc48d9b68275 (sched: restore
deterministic CPU accounting on powerpc), unconditionally calls
update_process_tick() in system context.  In the deterministic
accounting case this is the correct thing to do.  However, in the
non-deterministic accounting case we need to not do this, since doing
this results in the time accounted as hardware irq time being
artificially elevated.

Also this collapses 2 consecutive '#ifdef CONFIG_VIRT_CPU_ACCOUNTING'
checks in time.h into one for neatness.

Signed-off-by: Tony Breeds 
Signed-off-by: Paul Mackerras

sched: restore deterministic CPU accounting on powerpc

2007-11-09T21:39:38+00:00

Since powerpc started using CONFIG_GENERIC_CLOCKEVENTS, the
deterministic CPU accounting (CONFIG_VIRT_CPU_ACCOUNTING) has been
broken on powerpc, because we end up counting user time twice: once in
timer_interrupt() and once in update_process_times().

This fixes the problem by pulling the code in update_process_times
that updates utime and stime into a separate function called
account_process_tick.  If CONFIG_VIRT_CPU_ACCOUNTING is not defined,
there is a version of account_process_tick in kernel/timer.c that
simply accounts a whole tick to either utime or stime as before.  If
CONFIG_VIRT_CPU_ACCOUNTING is defined, then arch code gets to
implement account_process_tick.

This also lets us simplify the s390 code a bit; it means that the s390
timer interrupt can now call update_process_times even when
CONFIG_VIRT_CPU_ACCOUNTING is turned on, and can just implement a
suitable account_process_tick().

account_process_tick() now takes the task_struct * as an argument.
Tested both with and without CONFIG_VIRT_CPU_ACCOUNTING.

Signed-off-by: Paul Mackerras 
Signed-off-by: Ingo Molnar

Use helpers to obtain task pid in printks (arch code)

2007-10-19T18:53:43+00:00

One of the easiest things to isolate is the pid printed in kernel log.
There was a patch, that made this for arch-independent code, this one makes
so for arch/xxx files.

It took some time to cross-compile it, but hopefully these are all the
printks in arch code.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Pavel Emelyanov 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

powerpc: add Altivec/VMX state to coredumps

2007-10-17T15:42:44+00:00

Update dump_task_altivec() (which has so far never been put to use) so that
it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR and VRSAVE) in the
same format as the ptrace get_vrregs(), and add the appropriate glue
typedef and #defines to make it work.

A new note type of NT_PPC_VMX was chosen to be 0x100 (arbitrarily) because
it allows the low range values to be used for more generic purposes and
0x100 seems an adequate starting point for PowerPC extensions.

Signed-off-by: Mark Nelson 
Signed-off-by: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andi Kleen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[POWERPC] Use 1TB segments

2007-10-12T04:05:17+00:00

This makes the kernel use 1TB segments for all kernel mappings and for
user addresses of 1TB and above, on machines which support them
(currently POWER5+, POWER6 and PA6T).

We detect that the machine supports 1TB segments by looking at the
ibm,processor-segment-sizes property in the device tree.

We don't currently use 1TB segments for user addresses < 1T, since
that would effectively prevent 32-bit processes from using huge pages
unless we also had a way to revert to using 256MB segments.  That
would be possible but would involve extra complications (such as
keeping track of which segment size was used when HPTEs were inserted)
and is not addressed here.

Parts of this patch were originally written by Ben Herrenschmidt.

Signed-off-by: Paul Mackerras

Merge branch 'linux-2.6' into for-2.6.24

2007-10-03T05:33:17+00:00

[POWERPC] Make instruction dumping work in real mode

2007-10-03T01:48:44+00:00

On non-book-E, exceptions execute in real mode.  If a fault happens
that leads to a register dump, the kernel currently prints XXXXXXXX
because it doesn't realize that PC is a physical address.

This patch checks whether instruction address translation is turned
on, and if not converts PC into a virtual address.

Signed-off-by: Scott Wood 
Acked-by: Kumar Gala 
Acked-by: Olof Johansson 
Signed-off-by: Paul Mackerras

[POWERPC] Ensure FULL_REGS on exec

2007-09-25T10:40:41+00:00

When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
the (gdb) prompt is sufficient to produce this.  I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.

This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again.  This is correct since all of
the GPRs that "full" refers to are cleared in start_thread.

Signed-off-by: Roland McGrath 
Signed-off-by: Paul Mackerras

[POWERPC] Add cpu feature for SPE handling

2007-09-14T13:53:30+00:00

Make it so that SPE support can be determined at runtime.  This is similiar
to how we handle AltiVec.  This allows us to have SPE support built in and
work on processors with and without SPE.

Signed-off-by: Kumar Gala

[POWERPC] Flush registers to proper task context

2007-08-29T02:15:53+00:00

When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
we need to respect the task_struct that the caller has passed to us.

Most cases we are called with current, however sometimes (ptrace) we may
be passed a different task_struct.

This showed up when using gdbserver debugging a simple program that used
floating point. When gdb tried to show the FP regs they all showed up as
0, because the child's FP registers were never properly flushed to memory.

Signed-off-by: Kumar Gala