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 vdso
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
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
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 linked
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
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]
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 therefore
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.
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 w...@denx.de
Cc: Grant Likely
[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
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 (courtesy
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
-Anton Vorontsov avoront...@ru.mvista.com skrev: -
Till: Joakim Tjernlund joakim.tjernl...@transmode.se
Från: Anton Vorontsov avoront...@ru.mvista.com
Datum: 07/14/2009 00:20
Kopia: David Brownell dbrown...@users.sourceforge.net,
linux-ker...@vger.kernel.org, linuxppc-...@ozlabs.org
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-tree
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 PPC64
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
16 matches
Mail list logo
