Several small cleanups to the handling of octal and hex string
escapes:
- Use strncmp() instead dof what were essentially open-coded
versions of the same, with short fixed lengths.
- The call path to get_oct_char() means an empty escape is not
possible. So repla
The hypervisor can look at the value in wait_state_cycles for an estimate of
how busy dedicated processors are. Currently as the kernel never touches this
field so we appear to be 100% busy. Record the duration the kernel is in
powersave and pass that to the HV to provide a reasonable indication
The PT_DTRACE flag is meaningless and obsolete.
Don't touch it.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/process.c |5 -
arch/powerpc/kernel/sys_ppc32.c |5 -
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/pr
Since the PMU is an NMI now, it can come at any time we are only soft
disabled. We must hard disable around the two places we allow the kernel
stack SLB and r1 to go out of sync. Otherwise the PMU exception can
force a kernel stack SLB into another slot.
Signed-off-by: Anton Blanchard <[EMAIL PRO
Currently HEA requires 4K pages for IO resources. Just set the pages size to
IO to 4K.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
* Updated the comment aswell, sorry.
* Paul please consider this for 2.6.25
arch/powerpc/mm/hash_utils_64.c | 13 +
1 files changed, 5 insertio
Currently HEA requires 4K pages for IO resources. Just set the pages size to
IO to 4K.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
Paul, please consider this for 2.6.25
arch/powerpc/mm/hash_utils_64.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
Fixes the following ooop
pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
DMA copy offload driver for PA Semi PWRficient. It uses the
platform-specific functions to allocate channels, etc.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Changes since last post:
* Add DMA_INTERRUPT support and handlin
On Fri, 2008-03-14 at 09:42 +0100, Segher Boessenkool wrote:
> > I saw no effect from that change. So now we're back to pure
> mystery,
> > I guess.
>
> Hey, we know something now: it's "just" a problem in the kernel :-)
We don't know that for sure. The DABR context switching code is trivial
e
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
Uh... could be the boot code setting it, the setting happening on LSU0
but not LSU1. No ?
Ben.
___
Linuxppc-dev mail
On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
<[EMAIL PROTECTED]> wrote:
> All,
>
> I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
> ... maybe someone could give me some hints.
> Up to now the systems have been running on 2.6.19 without any problems.
>
> This is what I'v
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :
- get a recent system with 2.6.19 running and keep the toolchain (gcc
11 matches
Mail list logo