On 07/13/2013 11:26 PM, Benjamin Herrenschmidt wrote:
On Sun, 2013-07-14 at 14:36 +1000, Michael Ellerman wrote:
Is this expected behaviour? It seems to be the same in current git
versions of kexec-tools.
On my system I see /proc/device-tree/memory.
If I modify add_usable_mem_property() to
On 07/12/2013 04:59 PM, Chris Friesen wrote:
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input}: Assembler messages:
{standard input}:1619: Error: junk at end of line: `1'
{standard input}:2074: Error: junk at
On 07/11/2013 07:21 PM, Michael Ellerman wrote:
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
That 0x2 matches the fact that I'm seeing 8GB
On 07/12/2013 04:31 PM, Tony Breeds wrote:
On Fri, Jul 12, 2013 at 10:27:41AM -0600, Chris Friesen wrote:
Hi all,
I'm trying to build current mainline git with gcc version 4.4.1 as a
cross compiler and I'm getting the following:
CC arch/powerpc/kernel/ptrace.o
{standard input
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB
of memory. (It's an embedded system and I can't do much about the fact that
it's using older software.)
I booted the original kernel with crashkernel=224M@32M in the boot args. I
then loaded the crash kernel
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should probably clarify this...I may be able to update
On 07/11/2013 03:22 PM, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should
.
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.frie...@genband.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
SIG_DBG_BRANCH_TRACING return
-EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible
to use DBCR0_BT?
Thanks,
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.frie...@genband.com
On 04/17/2013 12:44 PM, Chris Friesen wrote:
Hi,
I'm trying to wrap my head around how linux handles branch tracing on
Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT],
and how we handle fixing things up if an instruction being traced causes
an exception.
While poking
On 04/11/2013 12:12 PM, Kumar Gala wrote:
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
Hi all,
We've got a powerpc system that uses u-boot. In our environment on
bootup u-boot does a DHCP to get networking info, then uses TFTP to
get the kernel, which then does DHCP again and NFS
On 04/11/2013 01:50 PM, Ira W. Snyder wrote:
I use a hardware setup which sounds similar to yours. The DHCP server
controls which file is sent to each card.
I use the FIT image format to combine a kernel, dtb, and initrd in one
package.
snip
I used the U-Boot doc/uImage.FIT/*.its examples to
?
task-thread.dbcr0 |= DBCR0_IDM | DBCR0_BT;
If not, then what's the point of clearing the DBCR0_IC bit in the
previous line?
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
?
Also, in sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return
-EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible
to use DBCR0_BRT?
Thanks,
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
On 04/06/2013 11:58 PM, David Gibson wrote:
On Thu, Apr 04, 2013 at 10:53:58PM -0600, Chris Friesen wrote:
Third, what's the most reliable way to ensure a block of addresses around
0xf600 don't get used for shared libraries? (We want to preserve
those addresses for emulating hardware
On 04/02/2013 09:07 AM, Segher Boessenkool wrote:
What I don't understand is where the /lib/ld.so.1 string is coming
from and how the length gets set to the invalid value.
It comes from the .interp input sections, i.e. the .interp sections in
the .o files you linked together. Perhaps you have
but after upgrading to new software the
libraries now extend further down the address space.
Any help is greatly appreciated.
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.frie...@genband.com
On 03/29/2013 06:01 AM, Segher Boessenkool wrote:
PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
snip
}
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0xf200); . = 0xf200 +
SIZEOF_HEADERS;
.interp : { *(.interp) } :text :interp
snip
}
the binutils documentation that I found and I don't see anything
that
would be messing with the length.
Any suggestions on where to look?
Thanks,
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
been picked up for mainline,
and I'm curious why not--is there something wrong with it?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie...@genband.com
www.genband.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
the control bit on task context switch if the prev and next processes
have different compatibility modes.
On the 970 you have to invalidate the entire icache whenever you change
the control bit. This is a pain involving a loop that calls icbi on 512
cachelines.
Chris
--
Chris Friesen
Software
Hi,
We're looking at maybe doing some work with an e5500-based system. Is
there any support existing/planned for this core?
Also, do we know what the cache line size is--we have some legacy apps
that assume 32-byte.
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.frie
On 09/16/2010 03:39 PM, Scott Wood wrote:
On Thu, 16 Sep 2010 14:06:37 -0600
Chris Friesen chris.frie...@genband.com wrote:
We're looking at maybe doing some work with an e5500-based system. Is
there any support existing/planned for this core?
Check with whoever you'd be getting
On 09/16/2010 04:03 PM, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-16 at 15:44 -0600, Chris Friesen wrote:
Right. We currently use a 970-series cpu and have implemented a
per-process flag to indicate whether 32-byte mode is needed or not.
We'd have to do something similar with the new cpu
On 03/25/2010 09:00 AM, Csdncannon wrote:
I am really sorry that the previously attached code is wrong, this one
timebase.c is the right one, and the log_timebase file is the right log.
We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.
volatile unsigned long long
Is anyone familiar with the mv64560? I'm curious how much difference
there might be from the older mv64360 as far as setting up the PCI bus,
cpu bus, i2c, memory, etc.
I don't see any mention of this chip in current linux sources, but
there's some mention of people trying it and it's referenced
On 11/04/2009 11:50 AM, Jonathan Haws wrote:
One more question about this approach: does the mmap() call prevent
the kernel from using this memory for other purposes? Will the
kernel be able to move this memory elsewhere? I guess what I am
asking is if this memory is locked for all other
Forwarding to the ppc mailing list.
Chris
Original Message
Subject: [PATCH] arch/powerpc: Improve _memcpy
Date: Tue, 3 Nov 2009 15:20:56 +0100
From: Dirk Eibach eib...@gdsys.de
To: linux-ker...@vger.kernel.org
CC: Dirk Eibach eib...@gdsys.de
The implementation of
as specified
by the user. It's been tested on e500 hardware and works as
expected.
The patch only modifies the CONFIG_FSL_BOOKE case, the CONFIG_4xx case
is left unmodified as I don't have any hardware to test it on.
Signed-off-by: Chris Friesen cfrie...@nortel.com
diff --git a/drivers/watchdog
Jonathan Haws wrote:
All,
I am having some issues with my target and was hoping that someone
could lend a hand. I am using an AMCC 405EX (Kilauea) board running
Linux kernel 2.6.31.
Here is the problem. I have some code that receives jumbo frames via
the EMAC, sticks the data in a
We've got some people that are currently running an older linux kernel
(from before the ppc/ppc64 merge and the conversion to device tree) on
an Emerson/Motorola cpci6115 (also known as mcpn905) compactPCI board.
They're wondering if it's possible to upgrade to a more recent kernel.
I don't see
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
wael showair wrote:
Hi All,
i have board that contains MPC8555 processor with linux 2.6.27 ported to it.
i want to use an accurate function to measure the time. i searched the
kernel code i found several functions but i read that the do_gettimeofday
is the most accurate one since it has a
Andi Kleen wrote:
Chris Friesen cfrie...@nortel.com writes:
One of the reasons I brought up this issue is that there is a lot of
documentation out there that says softirqs will be processed on return
from a syscall. The fact that it actually depends on the scheduler
parameters of the task
Andi Kleen wrote:
Thomas Gleixner t...@linutronix.de writes:
Err, no. Chris is completely correct:
if (!in_interrupt())
wakeup_softirqd();
Yes you have to wake it up just in case, but it doesn't normally
process the data because a normal softirq comes in faster. It's
Thomas Gleixner wrote:
On Wed, 13 May 2009, Chris Friesen wrote:
As far as I can tell, in this scenario softirqs may not get processed on
return from a syscall (contradicting the documentation). In the worst
case, they may not get processed until the next timer tick.
Right because your
Andi Kleen wrote:
network packets are normally processed by the network packet interrupt's
softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run.
My point is simply that the documentation says that softirqs are
processed on
Andi Kleen wrote:
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
Andi Kleen wrote:
network packets are normally processed by the network packet interrupt's
softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run
Ingo Molnar wrote:
* Chris Friesen cfrie...@nortel.com wrote:
I think I see a possible problem with this. Suppose I have a
SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under
the scenario above, schedule() would re-run the spinning task
rather than ksoftirqd, thus preventing
David Miller wrote:
You know, for networking over loopback (one of the only real cases
that even matters, if we get a hard interrupt then the return from
that would process any softints), we probably make out just fine
anyways. As long as we hit a local_bh_enable() (and in the return
path
This started out as a thread on the ppc list, but on the suggestion of
DaveM and Paul Mackerras I'm expanding the receiver list a bit.
Currently, if a softirq is raised in process context the
TIF_RESCHED_PENDING flag gets set and on return to userspace we run the
scheduler, expecting it to
Hi all,
I'm trying to figure out where exactly softirqs are called on return
from a syscall in 64-bit powerpc. I can see where they get called for a
normal interrupt via the irq_exit() path, but not for syscalls.
I'm sure I'm missing something obvious...can anyone help?
Thanks,
Chris
Paul Mackerras wrote:
If a soft irq is raised in process context, raise_softirq() in
kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
runs soon to process the soft irq. So what would happen is that we
would see the TIF_RESCHED_PENDING flag on the current task in the
syscall
Hi,
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never be inlined, it works fine.
Scott Wood wrote:
Chris Friesen wrote:
I've got a function that is used to overwrite opcodes in order to create
self-modifying code. It worked just fine with previous compilers, but
with gcc 4.3 it seems like it sometimes (but not always) causes problems
when inlined. If I force it to never
Scott Wood wrote:
Chris Friesen wrote:
Scott Wood wrote:
Is the compiler assigning r0 to addr? That will be treated as a
literal zero instead. Try changing r (addr) to b (addr), or use
stwx.
Bingo! Is there a constraint to tell the compiler to not use r0 for addr?
Yes, b.
Doh. Sorry
Hugh Dickins wrote:
On Thu, 2 Apr 2009, Michael Ellerman wrote:
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
Thanks
Hugh Dickins wrote:
This is a cosmetic matter, not worth more than a couple of lines of
code: I suggested masking off the high bits in the display, but when
KAMEZAWA-san suggested just showing 0, it was hard to argue against
his brutal simplicity.
snip
Consider this change a fix: it used to
Resending due to lack of response to original post.
I was validating some code dealing with /proc/pid/maps on 2.6.29 and
was surprised when it failed. It turns out that at least on my ppc64 G5
machine the offset value for the last entry is strange--it shows up as a
64-bit value even though
I was validating some code dealing with /proc/pid/maps on 2.6.29 and
was surprised when it failed. It turns out that at least on my ppc64 G5
machine the offset value for the last entry is strange--it shows up as a
64-bit value even though the process itself is only 32-bit.
This behaviour
Kevin Diggs wrote:
Does anyone know what the statement:
This technology has been retired.
on this page:
http://www.alphaworks.ibm.com/tech/powerscale4ppc
means? Something about 970FX frequency scaling?
I'm guessing they simply don't want to bother supporting the maple/970
anymore.
The code below sets up a simple timer with SIGEV_THREAD. I compiled the
code as g++ timertest.cc -o timertest -lrt -pthread.
Running it on my G5 with 2.6.27 (but with an older glibc), it prints:
Creating timer
Setting timer 268509264 for 5-second expiration...
and then the timer never
Chris Friesen wrote:
The code below sets up a simple timer with SIGEV_THREAD. I compiled the
code as g++ timertest.cc -o timertest -lrt -pthread.
Running it on my G5 with 2.6.27 (but with an older glibc), it prints:
Creating timer
Setting timer 268509264 for 5-second expiration
Chris Friesen wrote:
I'm getting suspicious of either glibc or my version of strace, as it
shows the child thread calling rt_sigtimedwait() with an empty signal set.
Looks like glibc was the culprit. It works fine with a newer version.
Sorry for the false alarm.
Chris
As far as I can tell, the PrPMC2800 is basically a lead-free PowerPMC280
with a bit more boot flash.
Has anyone booted current mainline kernels on a PowerPMC280? If so,
what config and bootloader options are required?
Thanks,
Chris
___
Hi,
I'm trying to boot 2.6.27 on a Moto PrPMC280. Currently it just hangs
after Passing control to the loaded file/image..
With an earlier kernel (2.6.14) I use a zImage.pplus file and netboot
with the -z option telling it to use PReP mode. With new kernels I
assume I use the
David Miller wrote:
From: Chris Friesen [EMAIL PROTECTED]
Date: Mon, 27 Oct 2008 18:13:54 -0600
[PATCH] fix amd8111e rx return code
The amd8111e rx poll routine currently mishandles the case when we process
exactly the number of packets specified in the budget.
This patch is basically
David Miller wrote:
From: Kevin Diggs [EMAIL PROTECTED]
Date: Sat, 25 Oct 2008 15:53:46 -0700
What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
thing supposed to be able to spread irq between its cpus?
Networking interrupts should lock onto a single CPU, unconditionally.
David Miller wrote:
From: Chris Friesen [EMAIL PROTECTED]
What about something like the Cavium Octeon, where we have 16 cores but a
single core isn't powerful enough to keep up with a gigE device?
Hello, we either have hardware that does flow seperation and has multiple
RX queues going
From: Chris Friesen[EMAIL PROTECTED]
Subject: [PATCH] fix amd8111e rx return code
The amd8111e rx poll routine currently mishandles the case when we process
exactly the number of packets specified in the budget.
This patch is basically as suggested by David Miller.
Signed-off-by: Chris
David Miller wrote:
From: Chris Friesen [EMAIL PROTECTED]
Are there any plans for a mechanism to allow the kernel to figure
out (or be told) what packets cpu-affined tasks are interested in
and route the interrupts appropriately?
No, not at all.
Now there are plans to allow the user
Rafael J. Wysocki wrote:
On Friday, 17 of October 2008, Kumar Gala wrote:
I've got a patch that seems to address this for me building w/
CONFIG_RELOCATABLE on ppc32/85xx.
Has that been fixed in 2.6.27 and/or current mainline?
I think CONFIG_RELOCATABLE was introduced post 2.6.27, so
David Miller wrote:
From: Brandeburg, Jesse [EMAIL PROTECTED] Date: Thu, 23 Oct
2008 14:50:06 -0700
Chris Friesen wrote:
I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
to a Maple board). The first time I booted I got the first log below
via the serial console. I
I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar to a
Maple board). The first time I booted I got the first log below via the
serial console. I rebooted and got as far as a login prompt. I was able to
log in via the serial console, but then got an almost identical oops
I just tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
to a Maple board). The first time I booted I got the first log below. I
rebooted and got as far as a login prompt. I was able to log in via the
serial console, but then got an almost identical oops again, as shown
Paul Mackerras wrote:
Chris, could you try just the following change (my previous patch
without the arch/powerpc/boot/wrapper change) and let me know if it
fixes things with the ld you use?
The build completes with no errors. Haven't actually booted it though.
Gets my vote...
Chris
Hollis Blanchard wrote:
binutils 2.16.1 is the most recent binutils that will build with
crosstool, so IMHO it's worth supporting. :)
I was wondering about thatwasted a bunch of time trying to build something
more recent.
Chris
___
The current -git fails to build on 64-bit powerpc (failure log below) .
Initially I tried using my older toolchain, when I first saw the
problem I built a new toolchain with crosstool (gcc 4.1.2 and binutils
2.16.1) and tried again but got the same problem.
2.6.27 doesn't show this problem.
Josh Boyer wrote:
Are these two merged yet? I just spent the better part of the morning
trying to figure out why various Fedora kernels based on 2.6.27-rcX and
2.6.27 final hung on my G5 and finally got one booting with FTRACE
disabled.
Until recently I could boot my G5 with FTRACE
Christoph Hellwig wrote:
On Fri, Sep 05, 2008 at 03:06:18AM +0200, Christoph Hellwig wrote:
Current linus tree fail to build for me for a 64bit powerpc config with:
This is cause by
commit 7563dc64585324f443f5ac107eb6d89ee813a2d2
Author: Tony Breeds [EMAIL PROTECTED]
Date: Tue Sep 2
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no
Grant Likely wrote:
Doing so should simplify adding new board ports. In many cases it
would just involve dropping in a new .dts file. However, it retains
the flexability of overriding generic code with platform specific
fixups as the need arises.
If it makes it easier for board vendors to
Nathan Lynch wrote:
Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
Sweet. One week from mention to working in -next...not bad.
My thanks to Arnd
Just wondering if anyone has looked at what it would take to support
latency top on powerpc?
I've got a dual G5 and I'd like to be able to track causes of latency.
Based on the s390 implementation it doesn't look all that complicated
for someone who understands what's going on...
Chris
Paolo Doz wrote:
Hi folks,
I'm developing a custom SPI driver (char device) on a MPC5200b, the
microcontroller linked as slave implements a protocol that must follow
strict timing constraints. I need to receive and send messages every
6msec.
What are your timing requirements? How much
Roland Dreier wrote:
Writes are posted yes, but not reordered arbitrarily. If I have code like:
spin_lock(mmio_lock);
writel(val1, reg1);
writel(val2, reg2);
spin_unlock(mmio_lock);
then I have a reasonable expectation that if two CPUs run this at the
same
I got the following warnings when building current git head for powerpc
64bit:
LD net/ipv4/built-in.o
LD drivers/scsi/built-in.o
LD net/built-in.o
LD drivers/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x73bc): Section mismatch in
Roland McGrath wrote:
Ok. That looks like a bug in the older binutils (objcopy) you are using.
It is confused by the empty .rela.dyn section right next to the .dynamic
section. Current binutils don't seem to have a problem with this.
I haven't tried to get an old binutils running to reproduce
I'm using gcc 3.4.3 and binutils 2.15.92.0.2. I originally saw the
following problem in 2.6.25 but it's present in git head as well:
CALL /home/cfriesen/kernels/2.6.25/linux-2.6.25/scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL
Roland McGrath wrote:
I haven't seen that error before. Can you show the output of {eu-,}readelf -lS
on vdso64.so.dbg, and also on the vdso64.so successfully built when you
revert the patch?
I've attached the raw output from the two commands. The delta between
the two is as follows:
Hi,
I'm getting the following error when building 2.6.25. Has anyone else
seen anything like this? This is using gcc 3.4.3.
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL
Chris Friesen wrote:
Hi,
I'm getting the following error when building 2.6.25. Has anyone else
seen anything like this? This is using gcc 3.4.3.
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a
Hi all,
We've got some kernel code that monitors which pages have been dirtied
by an application.
The pages are locked in memory, and the system has no swap. Initially
we mark the pages clean using ptep_clear_flush_dirty(), then when
requested by the app we scanning through the pages and
Grant Likely wrote:
Mild question; What the [EMAIL PROTECTED] are you doing trying to backport to
a
2 year old kernel?!? :-)
That's what happens in the embedded space. It's the current version
from our distro vendor. It's also the version that all our different
board suppliers could
Hi all,
I'm porting kprobes to 2.6.14, and I think I've got it mostly done. The
last thing that I want to do is to mark flush_icache_range() as part of
the .kprobes.text section so that we don't accidently try to probe it.
On ppc64 this was done by duplicating the _GLOBAL macro and just
87 matches
Mail list logo
