Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
in order to support break points.
This adds MSR_DE for kernel space only.
---
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects, therfore
this RFC.
Hi Joakim.
On May 30, 2012, at 12:43 AM, Joakim Tjernlund wrote:
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set
I'm not sure whether it makes sense to add this dependency to avoid
CONFI_NUMA !CONFIG_SMP.
I want to do this because I saw some build errors on next-tree when
compiling with CONFIG_SMP disabled, and it seems they are caused by some
codes under the CONFIG_NUMA #ifdefs.
Signed-off-by: Li
We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).
I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
On Wed, May 30, 2012 at 6:57 AM, Scott Wood scottw...@freescale.com wrote:
On 05/29/2012 05:07 PM, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
only that the kernel supports those boards. It should be a
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have
On 05/30/2012 03:43 AM, Joakim Tjernlund wrote:
Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
in order to support break points.
This adds MSR_DE for kernel space only.
---
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are
Hello,
I'm working on a P1021MDS based board and I have a strange behaviour
regarding the TX packets from the gianfar driver (linux 3.0.4-rc5).
Rx is working correctly but Tx is not... in particular I noticed that
the buffer descriptors are correctly filled but the packets simply do
NOT exit
Hi,
We have seen the following kernel panic, happened during loading a kernel
module:
[ 536.107430] Unable to handle kernel paging request for data at address
0xd76a907c
[ 536.114922] Faulting instruction address: 0xc770
[ 536.119891] Oops: Kernel access of bad area, sig:
(I apologise for this not having much to do with linux...)
We have a system with an MPC8315 ppc running linux 2.6.32
that uses the PCI express interface in RC mode to interface
to an Altera FPGA.
This uses both PIO and the PEX DMA interfaces (locally
written dma driver).
Under normal
Li Yang le...@freescale.com writes:
The original code was there before I touched the driver. So
unfortunately I also don't know the history of the problem.
Alas.
Judging from the comment in code and current test result I guess it
is a board related issue.
I wonder if anyone on the 8315_DS
Scott Wood scottw...@freescale.com writes:
Board information is available from the device tree, and from
platform code that was selected based on the device tree.
You're right, of course; I was focusing on discovery/probing, and
completely forgot about provided information.
However, as I just
On 05/30/2012 03:14 PM, Anthony Foiani wrote:
Scott Wood scottw...@freescale.com writes:
Board information is available from the device tree, and from
platform code that was selected based on the device tree.
You're right, of course; I was focusing on discovery/probing, and
completely
Scott Wood scottw...@freescale.com writes:
We currently support building one kernel that supports a bunch of
different boards. The hardcoding of this workaround was harmless so
far because it was conditional on a symbol that was never defined,
but now you'll be enabling this workaround on
On Wed, 2012-05-30 at 16:33 +0200, Steffen Rumler wrote:
Hi,
The system crashes inside the return of the init entry point of the kernel
module.
I've found the following root cause:
(6) Unfortunately, the trampoline code (do_plt_call()) is using register
r11 to setup the jump.
The form affinity for NUMA is set to 1 if the firmware supports
OPAL. Otherwise, we have to retrieve that from OF node /chosen.
For the latter case, OF node /chosen was referred without
dereferencing.
The patch dereference OF node /chosen if necessary.
Signed-off-by: Gavin Shan
16 matches
Mail list logo
