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 a
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
That
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
{stan
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 8
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
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 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 s
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 m
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
ernel.
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.ozlab
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 p
ntext() why does 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.fri
R0_BT?
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.genban
d it be as follows?
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.
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.
I used the U-Boot doc/uImage.FIT/*.its examples to get
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 an
age. build target but it was shot down because it used the
legacy multi-file format. Is there an equivalent build target that uses
the FIT format?
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
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 h
end 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
___
Linux
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 hav
On 03/29/2013 06:01 AM, Segher Boessenkool wrote:
PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
}
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0xf200); . = 0xf200 +
SIZEOF_HEADERS;
.interp : { *(.interp) } :text :interp
}
So I'm won
in the
script
seem to match 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
ar to have 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@l
s use dcbzl, process flag indicates compatibility, touch
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
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
On 09/16/2010 03:39 PM, Scott Wood wrote:
> On Thu, 16 Sep 2010 14:06:37 -0600
> Chris Friesen 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'
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
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
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 i
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 oth
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
To: linux-ker...@vger.kernel.org
CC: Dirk Eibach
The implementation of _memcpy_fromio and _memcpy_toio seems to
On 09/26/2009 05:38 AM, Konstantinos Margaritis wrote:
> I'm considering funding the design & production of a new PowerPC
> system (well, the motherboard, the rest are typical pc stuff and a
> case).
It might be interesting as a low-power system. For a development box,
this looks more intere
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
eout that is at least as large 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
dif
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 s
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
Chris Friesen wrote:
> Hi all,
>
> This probably isn't the right place to ask about this, but does anyone
> know where the implied memory barrier happens for pthread mutexes in the
> uncontended case? I'm looking at the glibc code and I don't see any
> barri
Hi all,
This probably isn't the right place to ask about this, but does anyone
know where the implied memory barrier happens for pthread mutexes in the
uncontended case? I'm looking at the glibc code and I don't see any
barrier instructions for mutexes, only semaphores and spinlocks.
Thanks,
C
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
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
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 ret
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 t
Andi Kleen wrote:
> Thomas Gleixner 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
> just a
Andi Kleen wrote:
> "Chris Friesen" 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 th
Ingo Molnar wrote:
> * Chris Friesen 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, t
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 switch
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
> pa
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 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
_
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 add
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
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.
First,
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.
Consider this change a fix: it used to show
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 :
Resending due to lack of response to original post.
I was validating some code dealing with /proc//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 p
I was validating some code dealing with /proc//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 also
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
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 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 expirati
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 expir
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
___
Linuxppc-
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 dtbImage.
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 pa
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 t
#x27;ve used up our budget.
If I leave the label and jump and just add the "rx_pkt_limit > 0" test, it
seems to work.
Chris
From: Chris Friesen<[EMAIL PROTECTED]>
Subject: [PATCH] fix amd8111e rx return code
The amd8111e rx poll routine currently mishandles the case when
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 mul
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.
That
David Miller wrote:
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 17:39:00 -0600
So...it would appear that the NAPI code is somehow buggy, and
6ba33ac should probably be reverted until the problem is found and
fixed.
No I think the problem is simple eno
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 se
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 should
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
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
___
Linuxppc-de
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
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
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 enab
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 16:
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 ide
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 do
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 over/
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 ti
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 refe
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
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:
-Ther
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
/home/cfriesen/kernels/2.6.25/linux-2.6.25/ar
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/ppc6
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
/home/cfriesen/kernels/2.6.25/linux-2.6.25/arch/
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 che
Paul Mackerras wrote:
> Chris Friesen writes:
>>For some background, we're running an emulator that uses a null pointer
>>value of 0x and we want any accesses to that address to trap.
> Can you fix this in userspace instead by moving the stack down below
>
Anton Blanchard wrote:
> Hi,
>
>
>>I've got a ppc64 box running 2.6.14. 64-bit kernel, 32-bit userspace.
>>It has a ~86KB chunk of memory near the top of the process address
>>space, and I'm not sure who's setting it up and what the purpose is. In
>>/proc//maps it looks like this:
>>
>>fffea
Hi all,
I've got a ppc64 box running 2.6.14. 64-bit kernel, 32-bit userspace.
It has a ~86KB chunk of memory near the top of the process address
space, and I'm not sure who's setting it up and what the purpose is. In
/proc//maps it looks like this:
fffea000-f000 rw-p fffea000 00:00 0
C
Well, I've played around with the sections a bit more, and just can't
seem to get it to work. As soon as I apply the following, the kernel
refuses to boot. (And if I remove the changes to _GLOBAL, then it
refuses to boot if I enable CONFIG_KPROBES.)
Index: linux/include/asm-ppc/processor.h
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 a
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
modi
96 matches
Mail list logo
