The STAB code used on Power3 and RS/64 uses a second scratch SPRG to
save a GPR in order to decide whether to go to do_stab_bolted_* or
to handle a normal data access exception.
This prevents our scheme of freeing SPRG3 which is user visible for
user uses since we cannot use SPRG0 which, on RS/64,
The kernel uses SPRG registers for various purposes, typically in
low level assembly code as scratch registers or to hold per-cpu
global infos such as the PACA or the current thread_info pointer.
We want to be able to easily shuffle the usage of those registers
as some implementations have specifi
The file include/asm/exception.h contains definitions
that are specific to exception handling on 64-bit server
type processors.
This renames the file to exception-64s.h to reflect that
fact and avoid confusion.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/exception-64s.h
Hello
I am newbie to RISCWatch and debugging using JTAG interface .I want to debug
Linux Kernel on target board
using jtag interface provided on board.
To debug 970MP dual core ppc processor on traget board, I installed
RISCWatch software on my window host.
My Setup:
--
Host <--(over
On Tue, 14 Jul 2009, Sachin Sant wrote:
> While enabling function_graph tracer on a Power6 box, machine
> crashed with following trace. Kernel version is 2.6.31-rc3.
Thanks,
I've seen issues with my PPC box and function graph, but the bugs were
also caused by other changes. I'll boot up my PPC6
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
[...]
> >But any users of the legacy bindings should be in-tree.
>
> ehh, it was working until you made it OF only. Why do call the native
> way legacy? It is the method all non OF arch uses.
It's legacy because there are no in-tr
-Anton Vorontsov skrev: -
>Till: Joakim Tjernlund
>Från: Anton Vorontsov
>Datum: 07/14/2009 00:20
>Kopia: David Brownell ,
>linux-ker...@vger.kernel.org, linuxppc-...@ozlabs.org
>Ärende: Re: [PATCH 0/2] Setting GPIOs simultaneously
>
>
>On Mon, Jul 13, 2009 at 09:59:54PM +0200, Joakim T
I have a powerpc board with 512BM of memory. The BIOS has a chunk of
memory at the top end of physical memory which it does not zero out over
a reboot.
What's the proper way to tell linux that this chunk of physical memory
should be ignored (so that we can access it later without worrying that
Li
By default, EEH does what's known as a "hot reset" during error recovery of a PCI Express
device. We've found a case where the device needs a "fundamental reset" to recover
properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtes
[Sorry for not replying earlier, somehow I missed this mail]
On the other hand, *using* -fno-omit-frame-pointer causes gcc to
produce buggy code on PowerPC targets.
It doesn't cause the problem, it only exposes it. And, of course,
only on certain GCC versions.
Segher, do you know if all GCC
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk
Cc: Grant Likely
Cc: Kumar Gal
On Wed, Jun 17, 2009 at 12:16:30AM +0400, Anton Vorontsov wrote:
> According to Segher Boessenkool and GCC manual, -fomit-frame-pointer
> is only the default when optimising on archs/ABIs where it doesn't
> hinder debugging and -pg. So, we do not get it by default on x86,
> not at any optimisation
On Wed, Jun 24, 2009 at 08:30:28PM +0400, Anton Vorontsov wrote:
> Linux isn't able to detect link changes on ethernet ports that were
> used by U-Boot. This is because U-Boot wrongly clears interrupt
> polarity bit (INTPOL, 0x400) in the extended status register (EXT_SR,
> 0x1b) of Marvell PHYs.
>
On Wed, Jul 01, 2009 at 09:39:25PM +0400, Anton Vorontsov wrote:
> Sometimes (e.g. when there are no UEMs attached to a board)
> fsl_pq_mdio_find_free() fails to find a spare address for a TBI PHY,
> this is because get_phy_id() returns bogus 0x values
> (0x is expected), and theref
Hi Ben,
> Don't we lose randomization ? Or do we randomize the whole mem map
> nowadays ?
The start of the top down mmap region is randomized, so the VDSO will be in a
different position each time. A quick example:
run 1:
fffb01f6000-fffb01f9000 r-xp 00:00 0 [vdso]
fffb01f9000
Hi Ben,
> Any chance you can put that little test program online somewhere ?
Sure, it's here:
http://ozlabs.org/~anton/junkcode/context_switch.c
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linux
On Tue, 2009-07-14 at 16:53 +1000, Anton Blanchard wrote:
> plain text document attachment (preload_0x1000)
> TASK_UNMAPPED_BASE is not used with the new top down mmap layout. We can
> reuse this preload slot by loading in the segment at 0x1000, where almost
> all PowerPC binaries are linke
With the new top down layout it is likely that the pc and stack will be in the
same segment, because the pc is most likely in a library allocated via a top
down mmap. Right now we bail out early if these segments match.
Rearrange the SLB preload code to sanity check all SLB preload addresses
are n
TASK_UNMAPPED_BASE is not used with the new top down mmap layout. We can
reuse this preload slot by loading in the segment at 0x1000, where almost
all PowerPC binaries are linked at.
On a microbenchmark that bounces a token between two 64bit processes over pipes
and calls gettimeofday each ite
On 64bit applications the VDSO is the only thing in segment 0. Since the VDSO
is position independent we can remove the hint and let get_unmapped_area pick
an area. This will mean the vdso will be near other mmaps and will share
an SLB entry:
1000-10001000 r-xp 08:06 5778459/r
Here are a few optimisations that improve context switch performance.
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2009-07-14 at 16:53 +1000, Anton Blanchard wrote:
> plain text document attachment (move_vdso_v2)
> On 64bit applications the VDSO is the only thing in segment 0. Since the VDSO
> is position independent we can remove the hint and let get_unmapped_area pick
> an area. This will mean the vds
22 matches
Mail list logo
