* Re: [PATCH v2] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
From: Kumar Gala @ 2008-01-18 6:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <12004125733910-git-send-email-timur@freescale.com>
On Tue, 15 Jan 2008, Timur Tabi wrote:
> Add file ucc_uart.c, a serial device driver for the Freescale QUICCEngine.
> Update the Kconfig and Makefile accordingly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Updated to reflect comments from Kumar.
>
> drivers/serial/Kconfig | 10 +
> drivers/serial/Makefile | 1 +
> drivers/serial/ucc_uart.c | 1514 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1525 insertions(+), 0 deletions(-)
> create mode 100644 drivers/serial/ucc_uart.c
>
applied.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] qe: add support for Freescale QUICCEngine UART
From: Kumar Gala @ 2008-01-18 6:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <11999217072674-git-send-email-timur@freescale.com>
On Wed, 9 Jan 2008, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICCEngine. Update
> booting-without-of.txt to define new properties for a QE UART node. Update
> the MPC8323E-MDS device tree to add UCC5 as a UART. Update the QE library
> to support slow UCC devices and modules.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 9 ++++-
> arch/powerpc/boot/dts/mpc832x_mds.dts | 50 ++++++++++++++++++++++++++
> arch/powerpc/sysdev/qe_lib/Kconfig | 2 +-
> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 10 +++++-
> 4 files changed, 68 insertions(+), 3 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] Update MPC8610 HPCD to support audio drivers
From: Kumar Gala @ 2008-01-18 6:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: alsa-devel, linuxppc-dev, olof, david
In-Reply-To: <12000050664035-git-send-email-timur@freescale.com>
On Thu, 10 Jan 2008, Timur Tabi wrote:
> Update the MPC8610 HPCD files to support the audio driver. Update
> booting-without-of.txt with information on the SSI device.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
Can you respin this. It doesn't apply cleanly to my tree.
- k
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 1/8] Add IPIC config option
From: Kumar Gala @ 2008-01-18 6:50 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1200614738-25654-2-git-send-email-jrigby@freescale.com>
On Thu, 17 Jan 2008, John Rigby wrote:
> IPIC is not just for 83xx anymore so make it a separate
> config option.
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
> ---
> arch/powerpc/platforms/Kconfig | 5 +++++
> arch/powerpc/sysdev/Makefile | 2 +-
> 2 files changed, 6 insertions(+), 1 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [Add mpc5121 support PATCH v3 2/8] Add mpc512x ipic support
From: Kumar Gala @ 2008-01-18 6:51 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1200614738-25654-3-git-send-email-jrigby@freescale.com>
On Thu, 17 Jan 2008, John Rigby wrote:
> Added ipic_info entries for vectors used by 512x that
> were previously unused by 83xx.
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
> ---
> arch/powerpc/sysdev/ipic.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH] Fix carry bug in 128-bit unsigned integer adding
From: Kumar Gala @ 2008-01-18 6:51 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev
In-Reply-To: <12006264992105-git-send-email-Yu.Liu@freescale.com>
On Fri, 18 Jan 2008, Liu Yu wrote:
> Synchronize it to the definition in include/math-emu/op-4.h for short term.
>
> Signed-off-by: Liu Yu <Yu.Liu@freescale.com>
> ---
> arch/powerpc/math-emu/op-4.h | 40 ++++++++++++++++++++++++++++++----------
> 1 files changed, 30 insertions(+), 10 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] mpc85xx_ads: add in missing of_node_put()
From: Kumar Gala @ 2008-01-18 6:52 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080102175001.GA18205@windriver.com>
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Fri, 21 Dec 2007 10:12:38 -0500
> Subject: [PATCH] mpc85xx_ads: add in missing of_node_put()
>
> Add in missing of_node_put() after cpm2_pic_init(). This and other coding
> style cleanups as suggested by Stephen Rothwell.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
applied.
- k
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-18 6:56 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel, Linux MM
In-Reply-To: <20080117211511.GA25320@aepfle.de>
On Thu, Jan 17, Olaf Hering wrote:
> On Thu, Jan 17, Christoph Lameter wrote:
>
> > On Thu, 17 Jan 2008, Olaf Hering wrote:
> >
> > > The patch does not help.
> >
> > Duh. We need to know more about the problem.
>
> cache_grow is called from 3 places. The third call has cleared l3 for
> some reason.
Typo in debug patch.
calls cache_grow with nodeid 0
> [c00000000075bbd0] [c0000000000f82d0] .cache_alloc_refill+0x234/0x2c0
calls cache_grow with nodeid 0
> [c00000000075bbe0] [c0000000000f7f38] .____cache_alloc_node+0x17c/0x1e8
calls cache_grow with nodeid 1
> [c00000000075bbe0] [c0000000000f7d68] .fallback_alloc+0x1a0/0x1f4
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 build failure on headers_check
From: Kamalesh Babulal @ 2008-01-18 7:09 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kbuild, linux-kernel, linuxppc-dev, Sam Ravnborg,
Balbir Singh
In-Reply-To: <20080117023514.9df393cf.akpm@linux-foundation.org>
Hi Andrew,
The kernel build fails during the headers_check on power box
CHECK include/asm/nvram.h
/usr/local/autobench/autotest/tmp/build/linux/usr/include/asm/nvram.h requires linux/list.h, which does not exist in exported headers
make[3]: *** [/usr/local/autobench/autotest/tmp/build/linux/usr/include/asm/.check.nvram.h] Error 1
make[2]: *** [asm-powerpc] Error 2
make[1]: *** [headers_check] Error 2
make: *** [vmlinux] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 build failure on headers_check
From: Andrew Morton @ 2008-01-18 7:38 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-kbuild, linux-kernel, linuxppc-dev, Sam Ravnborg,
Balbir Singh
In-Reply-To: <479050BF.1090107@linux.vnet.ibm.com>
On Fri, 18 Jan 2008 12:39:51 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The kernel build fails during the headers_check on power box
>
> CHECK include/asm/nvram.h
> /usr/local/autobench/autotest/tmp/build/linux/usr/include/asm/nvram.h requires linux/list.h, which does not exist in exported headers
> make[3]: *** [/usr/local/autobench/autotest/tmp/build/linux/usr/include/asm/.check.nvram.h] Error 1
doh.
--- a/include/asm-powerpc/nvram.h~include-asm-powerpc-nvramh-needs-listh-fix
+++ a/include/asm-powerpc/nvram.h
@@ -11,7 +11,6 @@
#define _ASM_POWERPC_NVRAM_H
#include <linux/errno.h>
-#include <linux/list.h>
#define NVRW_CNT 0x20
#define NVRAM_HEADER_LEN 16 /* sizeof(struct nvram_header) */
@@ -59,6 +58,9 @@ struct nvram_header {
};
#ifdef __KERNEL__
+
+#include <linux/list.h>
+
struct nvram_partition {
struct list_head partition;
struct nvram_header header;
_
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Kamalesh Babulal @ 2008-01-18 8:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <20080117023514.9df393cf.akpm@linux-foundation.org>
Hi Andrew,
Following oops was seen while running kernbench on one of test machine
(power4+ box). I tried reproducing the oops but was unsuccessful.
I will try to reproduce the oops with debug info compiled.
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
DAR: c00000077b6bfce0, DSISR: 000000000a000000
TASK = c000000773164c40[19588] 'as' THREAD: c00000077b6bc000 CPU: 1
GPR00: 0000000000004000 c00000077b6bfb40 0000000000007346 000000000000d032
GPR04: 000000000000043a 0000000000000000 000000000000000c 0000000000000004
GPR08: 000000000fd278c8 0000000048022424 c00000077b6bfe30 0000998be2321500
GPR12: 8000000000001030 c0000000005f6280 0000000010030000 0000000010030000
GPR16: 0000000010030000 0000000010050000 000000001006aac0 0000000010053cd0
GPR20: 0000000000000000 0000000000000fe0 0000000010050000 0000000010050000
GPR24: 0000000000000ff8 0000000000000fe8 0000000000000062 000000000fd27490
GPR28: 000000000fd274c8 0000000010099420 000000000fd25ff4 000000001009a400
NIP [0000000000004570] 0x4570
LR [000000000fc42dc0] 0xfc42dc0
Call Trace:
[c00000077b6bfb40] [c00000077b292000] 0xc00000077b292000 (unreliable)
Instruction dump:
48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: array type has incomplete element type
From: Joachim Meyer @ 2008-01-18 8:38 UTC (permalink / raw)
To: r_wehbi; +Cc: linuxppc-embedded
Hi
I managed to set up linux for the ml310 (Virtex 2 pro) these days.
I don't know how similar it is, but here is what worked for me:
I used the kernel (newest 2.6.24-rc3) from the secret lab tree:
------------------------------------------------------------------
http://wiki.secretlab.ca/index.php/Linux=5Fon=5FXilinx=5FVirtex
--> look at vendow trees.
-------------------------------------------------------------------
I also used crosstool but with
gcc-3.4.5-glibc-2.3.6
maybe you give it a try
good Luck
Joachim
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Andrew Morton @ 2008-01-18 8:44 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <479064F0.7040305@linux.vnet.ibm.com>
On Fri, 18 Jan 2008 14:06:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> Following oops was seen while running kernbench on one of test machine
> (power4+ box). I tried reproducing the oops but was unsuccessful.
> I will try to reproduce the oops with debug info compiled.
>
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in:
> NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
> REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
> DAR: c00000077b6bfce0, DSISR: 000000000a000000
> TASK = c000000773164c40[19588] 'as' THREAD: c00000077b6bc000 CPU: 1
> GPR00: 0000000000004000 c00000077b6bfb40 0000000000007346 000000000000d032
> GPR04: 000000000000043a 0000000000000000 000000000000000c 0000000000000004
> GPR08: 000000000fd278c8 0000000048022424 c00000077b6bfe30 0000998be2321500
> GPR12: 8000000000001030 c0000000005f6280 0000000010030000 0000000010030000
> GPR16: 0000000010030000 0000000010050000 000000001006aac0 0000000010053cd0
> GPR20: 0000000000000000 0000000000000fe0 0000000010050000 0000000010050000
> GPR24: 0000000000000ff8 0000000000000fe8 0000000000000062 000000000fd27490
> GPR28: 000000000fd274c8 0000000010099420 000000000fd25ff4 000000001009a400
> NIP [0000000000004570] 0x4570
> LR [000000000fc42dc0] 0xfc42dc0
> Call Trace:
> [c00000077b6bfb40] [c00000077b292000] 0xc00000077b292000 (unreliable)
> Instruction dump:
> 48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
> 48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
>
odd. Where did the stack trace go?
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Paul Mackerras @ 2008-01-18 9:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel, Kamalesh Babulal
In-Reply-To: <20080118004416.6a757169.akpm@linux-foundation.org>
Andrew Morton writes:
> On Fri, 18 Jan 2008 14:06:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> > Hi Andrew,
> >
> > Following oops was seen while running kernbench on one of test machine
> > (power4+ box). I tried reproducing the oops but was unsuccessful.
> > I will try to reproduce the oops with debug info compiled.
> >
> >
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > SMP NR_CPUS=32 NUMA pSeries
> > Modules linked in:
> > NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
> > REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> > MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
> > DAR: c00000077b6bfce0, DSISR: 000000000a000000
> > TASK = c000000773164c40[19588] 'as' THREAD: c00000077b6bc000 CPU: 1
> > GPR00: 0000000000004000 c00000077b6bfb40 0000000000007346 000000000000d032
> > GPR04: 000000000000043a 0000000000000000 000000000000000c 0000000000000004
> > GPR08: 000000000fd278c8 0000000048022424 c00000077b6bfe30 0000998be2321500
> > GPR12: 8000000000001030 c0000000005f6280 0000000010030000 0000000010030000
> > GPR16: 0000000010030000 0000000010050000 000000001006aac0 0000000010053cd0
> > GPR20: 0000000000000000 0000000000000fe0 0000000010050000 0000000010050000
> > GPR24: 0000000000000ff8 0000000000000fe8 0000000000000062 000000000fd27490
> > GPR28: 000000000fd274c8 0000000010099420 000000000fd25ff4 000000001009a400
> > NIP [0000000000004570] 0x4570
> > LR [000000000fc42dc0] 0xfc42dc0
> > Call Trace:
> > [c00000077b6bfb40] [c00000077b292000] 0xc00000077b292000 (unreliable)
> > Instruction dump:
> > 48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
> > 48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
> >
>
> odd. Where did the stack trace go?
It's there, it's just really really short (one line). The link
register is in userspace and the stack pointer looks to be right at
the top of a kernel stack area.
The trap was a data access exception which is very odd given that the
machine is in real mode (MMU off) with the pc at 0x4570. Actually it
looks like the machine probably got a data access exception somewhere
(probably in userspace, probably a page fault or similar) and then got
another exception before it had finished saving the state from the
first exception.
Kamalesh, do you still have the vmlinux? If so could you disassemble
the area from say 0x4500 to 0x4600, and find out what is the closest
symbol before 0xc000000000004570 from System.map, and show us those?
Paul.
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Kamalesh Babulal @ 2008-01-18 9:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton, Balbir Singh, linux-kernel
In-Reply-To: <18320.27372.202771.764301@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Andrew Morton writes:
>
>> On Fri, 18 Jan 2008 14:06:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> Following oops was seen while running kernbench on one of test machine
>>> (power4+ box). I tried reproducing the oops but was unsuccessful.
>>> I will try to reproduce the oops with debug info compiled.
>>>
>>>
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in:
>>> NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
>>> REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
>>> MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
>>> DAR: c00000077b6bfce0, DSISR: 000000000a000000
>>> TASK = c000000773164c40[19588] 'as' THREAD: c00000077b6bc000 CPU: 1
>>> GPR00: 0000000000004000 c00000077b6bfb40 0000000000007346 000000000000d032
>>> GPR04: 000000000000043a 0000000000000000 000000000000000c 0000000000000004
>>> GPR08: 000000000fd278c8 0000000048022424 c00000077b6bfe30 0000998be2321500
>>> GPR12: 8000000000001030 c0000000005f6280 0000000010030000 0000000010030000
>>> GPR16: 0000000010030000 0000000010050000 000000001006aac0 0000000010053cd0
>>> GPR20: 0000000000000000 0000000000000fe0 0000000010050000 0000000010050000
>>> GPR24: 0000000000000ff8 0000000000000fe8 0000000000000062 000000000fd27490
>>> GPR28: 000000000fd274c8 0000000010099420 000000000fd25ff4 000000001009a400
>>> NIP [0000000000004570] 0x4570
>>> LR [000000000fc42dc0] 0xfc42dc0
>>> Call Trace:
>>> [c00000077b6bfb40] [c00000077b292000] 0xc00000077b292000 (unreliable)
>>> Instruction dump:
>>> 48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
>>> 48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
>>>
>> odd. Where did the stack trace go?
Only this much was captured in the serial console.
>
> It's there, it's just really really short (one line). The link
> register is in userspace and the stack pointer looks to be right at
> the top of a kernel stack area.
>
> The trap was a data access exception which is very odd given that the
> machine is in real mode (MMU off) with the pc at 0x4570. Actually it
> looks like the machine probably got a data access exception somewhere
> (probably in userspace, probably a page fault or similar) and then got
> another exception before it had finished saving the state from the
> first exception.
>
> Kamalesh, do you still have the vmlinux? If so could you disassemble
> the area from say 0x4500 to 0x4600, and find out what is the closest
> symbol before 0xc000000000004570 from System.map, and show us those?
>
> Paul.
> --
I tried reproducing the problem and was successful with following trace
in which the pc is at 0x4570 as the above one
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP: 0000000000004570 LR: 000000000ff0288c CTR: 000000000ff013e0
REGS: c00000077e61f8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
MSR: 8000000000001000 <ME> CR: 28000422 XER: 00000000
DAR: c00000077e61fce0, DSISR: 000000000a000000
TASK = c00000077207f880[23480] 'cc1' THREAD: c00000077e61c000 CPU: 3
GPR00: 0000000000004000 c00000077e61fb40 0000000000000088 000000000000d032
GPR04: 0000000000000088 000000000000030c 00000000fefefeff 000000007f7f7f7f
GPR08: 0000000000008000 0000000044000428 c00000077e61fe30 0000998be2321500
GPR12: 8000000000001030 c0000000005f6680 0000000010030000 0000000010030000
GPR16: 00000000105b0000 00000000105b0000 0000000010440000 00000000105b0000
GPR20: 00000000105b0000 00000000105b0000 00000000105b0000 00000000105b0000
GPR24: 00000000105b0000 00000000105b0000 00000000105b0000 00000000ffa11b24
GPR28: 0000000000000000 00000000ffffffff 000000000ffebff4 000000000ffec408
NIP [0000000000004570] 0x4570
LR [000000000ff0288c] 0xff0288c
Call Trace:
[c00000077e61fb40] [c00000077e61fcf0] 0xc00000077e61fcf0 (unreliable)
[c00000077e61fbd0] [0000000010440000] 0x10440000
Instruction dump:
48000000 XXXXXXXX XXXXXXXX XXXXXXXX 41820008 XXXXXXXX XXXXXXXX XXXXXXXX
48000010 XXXXXXXX XXXXXXXX XXXXXXXX f92101a0 XXXXXXXX XXXXXXXX XXXXXXXX
The disassembled vmlinux from 0x4500 to 0x4600
c000000000004500: f9 4d 01 68 std r10,360(r13)
c000000000004504: 48 02 89 f9 bl c00000000002cefc <.slb_allocate_realmode>
c000000000004508: e9 4d 01 68 ld r10,360(r13)
c00000000000450c: e8 6d 01 60 ld r3,352(r13)
c000000000004510: 81 2d 01 5c lwz r9,348(r13)
c000000000004514: 7d 48 03 a6 mtlr r10
c000000000004518: 71 8a 00 02 andi. r10,r12,2
c00000000000451c: 41 82 00 28 beq- c000000000004544 <unrecov_slb>
c000000000004520: 7d 38 01 20 mtocrf 128,r9
c000000000004524: 7d 30 11 20 mtocrf 1,r9
c000000000004528: e9 2d 01 20 ld r9,288(r13)
c00000000000452c: e9 4d 01 28 ld r10,296(r13)
c000000000004530: e9 6d 01 30 ld r11,304(r13)
c000000000004534: e9 8d 01 38 ld r12,312(r13)
c000000000004538: e9 ad 01 40 ld r13,320(r13)
c00000000000453c: 4c 00 00 24 rfid
c000000000004540: 48 00 00 00 b c000000000004540 <.slb_miss_realmode+0x48>
c000000000004544 <unrecov_slb>:
c000000000004544: 71 8a 40 00 andi. r10,r12,16384
c000000000004548: 7c 2a 0b 78 mr r10,r1
c00000000000454c: 38 21 fd 10 addi r1,r1,-752
c000000000004550: 41 82 00 08 beq- c000000000004558 <unrecov_slb+0x14>
c000000000004554: e8 2d 01 a8 ld r1,424(r13)
c000000000004558: 2c a1 00 00 cmpdi cr1,r1,0
c00000000000455c: 40 84 00 08 bge- cr1,c000000000004564 <unrecov_slb+0x20>
c000000000004560: 48 00 00 10 b c000000000004570 <unrecov_slb+0x2c>
c000000000004564: 38 20 41 00 li r1,16640
c000000000004568: b0 2d 01 c8 sth r1,456(r13)
c00000000000456c: 4b ff fb 18 b c000000000004084 <bad_stack>
c000000000004570: f9 21 01 a0 std r9,416(r1)
c000000000004574: f9 61 01 70 std r11,368(r1)
c000000000004578: f9 81 01 78 std r12,376(r1)
c00000000000457c: f9 41 00 00 std r10,0(r1)
c000000000004580: f8 01 00 70 std r0,112(r1)
c000000000004584: f9 41 00 78 std r10,120(r1)
c000000000004588: 41 82 00 24 beq- c0000000000045ac <unrecov_slb+0x68>
c00000000000458c: 7d 35 4a a6 mfspr r9,309
c000000000004590: 7d 2c 42 e6 mftb r9
c000000000004594: e9 4d 01 e0 ld r10,480(r13)
c000000000004598: f9 2d 01 e0 std r9,480(r13)
c00000000000459c: 7d 4a 48 50 subf r10,r10,r9
c0000000000045a0: e9 2d 01 d0 ld r9,464(r13)
c0000000000045a4: 7d 29 52 14 add r9,r9,r10
c0000000000045a8: f9 2d 01 d0 std r9,464(r13)
c0000000000045ac: f8 41 00 80 std r2,128(r1)
c0000000000045b0: f8 61 00 88 std r3,136(r1)
c0000000000045b4: f8 81 00 90 std r4,144(r1)
c0000000000045b8: f8 a1 00 98 std r5,152(r1)
c0000000000045bc: f8 c1 00 a0 std r6,160(r1)
c0000000000045c0: f8 e1 00 a8 std r7,168(r1)
c0000000000045c4: f9 01 00 b0 std r8,176(r1)
c0000000000045c8: e9 2d 01 20 ld r9,288(r13)
c0000000000045cc: e9 4d 01 28 ld r10,296(r13)
c0000000000045d0: f9 21 00 b8 std r9,184(r1)
c0000000000045d4: f9 41 00 c0 std r10,192(r1)
c0000000000045d8: e9 2d 01 30 ld r9,304(r13)
c0000000000045dc: e9 4d 01 38 ld r10,312(r13)
c0000000000045e0: e9 6d 01 40 ld r11,320(r13)
c0000000000045e4: f9 21 00 c8 std r9,200(r1)
c0000000000045e8: f9 41 00 d0 std r10,208(r1)
c0000000000045ec: f9 61 00 d8 std r11,216(r1)
c0000000000045f0: e8 4d 00 10 ld r2,16(r13)
c0000000000045f4: 7d 28 02 a6 mflr r9
c0000000000045f8: f9 21 01 90 std r9,400(r1)
c0000000000045fc: 7d 49 02 a6 mfctr r10
c000000000004600: f9 41 01 88 std r10,392(r1)
The closet symbol form the system.map file
c000000000004280 T data_access_common
c000000000004400 T instruction_access_common
c0000000000044f8 T .slb_miss_realmode
c000000000004544 t unrecov_slb
c000000000004680 T hardware_interrupt_common
Let me know if you need more information.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] add modalias info to mv643xx_eth.ko
From: Olaf Hering @ 2008-01-18 9:38 UTC (permalink / raw)
To: linuxppc-dev, netdev
mv643xx_eth has an platform modalias file in sysfs.
But the module itself has no alias: line. Autoloading fails
without the alias info in the module.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/net/mv643xx_eth.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2099,6 +2099,7 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR( "Rabeeh Khoury, Assaf Hoffman, Matthew Dharm, Manish Lachwani"
" and Dale Farnsworth");
MODULE_DESCRIPTION("Ethernet driver for Marvell MV643XX");
+MODULE_ALIAS("platform:mv643xx_eth");
/*
* The second part is the low level driver of the gigE ethernet ports.
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Paul Mackerras @ 2008-01-18 10:19 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, Balbir Singh, linux-kernel
In-Reply-To: <479072BC.3080908@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> I tried reproducing the problem and was successful with following trace
> in which the pc is at 0x4570 as the above one
What did you do to trigger it?
> c000000000004544 <unrecov_slb>:
> c000000000004544: 71 8a 40 00 andi. r10,r12,16384
> c000000000004548: 7c 2a 0b 78 mr r10,r1
> c00000000000454c: 38 21 fd 10 addi r1,r1,-752
> c000000000004550: 41 82 00 08 beq- c000000000004558 <unrecov_slb+0x14>
> c000000000004554: e8 2d 01 a8 ld r1,424(r13)
> c000000000004558: 2c a1 00 00 cmpdi cr1,r1,0
> c00000000000455c: 40 84 00 08 bge- cr1,c000000000004564 <unrecov_slb+0x20>
> c000000000004560: 48 00 00 10 b c000000000004570 <unrecov_slb+0x2c>
> c000000000004564: 38 20 41 00 li r1,16640
> c000000000004568: b0 2d 01 c8 sth r1,456(r13)
> c00000000000456c: 4b ff fb 18 b c000000000004084 <bad_stack>
> c000000000004570: f9 21 01 a0 std r9,416(r1)
So it's in the code that gets called on an unrecoverable SLB fault.
That's bad, we should never get those. Does this happen with mainline
too, or only with -rc8-mm1? I don't understand why we should start
seeing this problem unless something has changed in
arch/powerpc/kernel or arch/powerpc/mm (well I suppose a bug somewhere
else could cause memory corruption which might be able to lead to
this).
Does it still happen if you take git-powerpc.patch out of the series?
Paul.
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Paul Mackerras @ 2008-01-18 10:26 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, Balbir Singh, linux-kernel
In-Reply-To: <479072BC.3080908@linux.vnet.ibm.com>
Kamalesh Babulal writes:
> >>> NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
> >>> REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> >>> MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
> >>> DAR: c00000077b6bfce0, DSISR: 000000000a000000
Actually, how much RAM does this machine have? If it has less than
32GB, then the problem is that the kernel stack pointer is bogus.
(How it got to be bogus is the interesting question, of course. :)
Paul.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-18 5:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, LKML
In-Reply-To: <1200634493.7806.0.camel@concordia.ozlabs.ibm.com>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-18 16:34:53]:
> On Sat, 2007-12-08 at 04:07 +0530, Balbir Singh wrote:
> > Changelog
> >
> > 1. Get rid of the constant 5 (based on comments from
> > Geert.Uytterhoeven@sonycom.com)
> > 2. Implement suggestions from Olof Johannson
> > 3. Check if cmdline is NULL in fake_numa_create_new_node()
> >
> > Tested with additional parameters from Olof
> >
> > numa=debug,fake=
> > numa=foo,fake=bar
>
>
> I'm not sure why yet, but git bisect tells me it's this patch that's
> causing the for-2.6.25 tree to explode on boot on cell machines.
>
Hi,
Do you boot with numa=<options> on your machine? Could I have your
machine configuration? Any OOPS/log would be helpful.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-18 6:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1200635703.18783.5.camel@concordia.ozlabs.ibm.com>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-18 16:55:03]:
> On Sat, 2007-12-08 at 04:07 +0530, Balbir Singh wrote:
> > Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
> > NUMA nodes can be specified using the following command line option
> >
>
> >
> > Comments are as always welcome!
>
> Here's some :)
>
Thanks!
> > diff -puN arch/powerpc/mm/numa.c~ppc-fake-numa-easy arch/powerpc/mm/numa.c
> > --- linux-2.6.24-rc4-mm1/arch/powerpc/mm/numa.c~ppc-fake-numa-easy 2007-12-07 21:25:55.000000000 +0530
> > +++ linux-2.6.24-rc4-mm1-balbir/arch/powerpc/mm/numa.c 2007-12-08 03:19:46.000000000 +0530
> > @@ -24,6 +24,8 @@
> >
> > static int numa_enabled = 1;
> >
> > +static char *cmdline __initdata;
>
> Can you call this fake_numa_args or something, cmdline is a bit generic.
>
I could if it makes code easier to understand. Will put it in my TODO
list.
>
> > @@ -39,6 +41,43 @@ static bootmem_data_t __initdata plat_no
> > static int min_common_depth;
> > static int n_mem_addr_cells, n_mem_size_cells;
> >
> > +static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> > + unsigned int *nid)
> > +{
> > + unsigned long long mem;
> > + char *p = cmdline;
> > + static unsigned int fake_nid = 0;
> > + static unsigned long long curr_boundary = 0;
> > +
> > + *nid = fake_nid;
>
> As I mentioned in my other email I think this is broken, you
> unconditionally overwrite *nid, even if no fake numa was specified?
>
Aah.. OK.. looks like a BUG. I'll also respond to your other email.
> > + if (!p)
> > + return 0;
> > +
> > + mem = memparse(p, &p);
> > + if (!mem)
> > + return 0;
> > +
> > + if (mem < curr_boundary)
> > + return 0;
> > +
> > + curr_boundary = mem;
> > +
> > + if ((end_pfn << PAGE_SHIFT) > mem) {
> > + /*
> > + * Skip commas and spaces
> > + */
> > + while (*p == ',' || *p == ' ' || *p == '\t')
> > + p++;
> > +
> > + cmdline = p;
> > + fake_nid++;
> > + *nid = fake_nid;
> > + dbg("created new fake_node with id %d\n", fake_nid);
> > + return 1;
> > + }
> > + return 0;
> > +}
> > +
> > static void __cpuinit map_cpu_to_node(int cpu, int node)
> > {
> > numa_cpu_lookup_table[cpu] = node;
> > @@ -344,12 +383,14 @@ static void __init parse_drconf_memory(s
> > if (nid == 0xffff || nid >= MAX_NUMNODES)
> > nid = default_nid;
> > }
> > - node_set_online(nid);
> >
> > size = numa_enforce_memory_limit(start, lmb_size);
> > if (!size)
> > continue;
> >
> > + fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
> > + node_set_online(nid);
>
> I can't convince myself that this is 100% ok, the moving of
> node_set_online(). At the very least it's a change in behaviour,
> previously we would online the node regardless of the memory limit.
>
Hmm.. this can be reverted, but do we gain anything by enabling nodes,
even though we are over the memory limit?
> > add_active_range(nid, start >> PAGE_SHIFT,
> > (start >> PAGE_SHIFT) + (size >> PAGE_SHIFT));
> > }
> > @@ -429,7 +470,6 @@ new_range:
> > nid = of_node_to_nid_single(memory);
> > if (nid < 0)
> > nid = default_nid;
> > - node_set_online(nid);
> >
> > if (!(size = numa_enforce_memory_limit(start, size))) {
> > if (--ranges)
> > @@ -438,6 +478,9 @@ new_range:
> > continue;
> > }
> >
> > + fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
> > + node_set_online(nid);
>
> Ditto previous comment.
>
Yes, point noted.
Thanks for your review and problem report.
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-18 7:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1200635099.7806.3.camel@concordia.ozlabs.ibm.com>
* Michael Ellerman <michael@ellerman.id.au> [2008-01-18 16:44:58]:
> On Fri, 2008-01-18 at 16:34 +1100, Michael Ellerman wrote:
> > On Sat, 2007-12-08 at 04:07 +0530, Balbir Singh wrote:
> > > Changelog
> > >
> > > 1. Get rid of the constant 5 (based on comments from
> > > Geert.Uytterhoeven@sonycom.com)
> > > 2. Implement suggestions from Olof Johannson
> > > 3. Check if cmdline is NULL in fake_numa_create_new_node()
> > >
> > > Tested with additional parameters from Olof
> > >
> > > numa=debug,fake=
> > > numa=foo,fake=bar
> >
> >
> > I'm not sure why yet, but git bisect tells me it's this patch that's
> > causing the for-2.6.25 tree to explode on boot on cell machines.
>
> This fixes it, although I'm a little worried about some of the
> removals/movings of node_set_online() in the patch.
>
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 1666e7d..dcedc26 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -49,7 +49,6 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> static unsigned int fake_nid = 0;
> static unsigned long long curr_boundary = 0;
>
> - *nid = fake_nid;
> if (!p)
> return 0;
>
> @@ -60,6 +59,7 @@ static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> if (mem < curr_boundary)
> return 0;
>
> + *nid = fake_nid;
> curr_boundary = mem;
>
> if ((end_pfn << PAGE_SHIFT) > mem) {
>
This patch makes sense, ideally fake_numa_create_new_node() should
just be a no-op in the case of machines with real NUMA nodes.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Kamalesh Babulal @ 2008-01-18 10:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton, Balbir Singh, linux-kernel
In-Reply-To: <18320.32464.634534.415458@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>>>>> NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
>>>>> REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
>>>>> MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
>>>>> DAR: c00000077b6bfce0, DSISR: 000000000a000000
>
> Actually, how much RAM does this machine have? If it has less than
> 32GB, then the problem is that the kernel stack pointer is bogus.
> (How it got to be bogus is the interesting question, of course. :)
>
> Paul.
>
Hi Paul,
The machine has around 30GB of RAM, do you want me to try, by taking
the git-powerpc.patch out of the series and try reproducing the oops.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Adding new driver in Linux 2.6 - read fails with -1
From: Ramkumar J @ 2008-01-18 10:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]
Hi All,
I m using the Linux 2.6(2.6.23-rc2) from Grants for ML-403 and I tried to
add a new driver for a hardware based stream. When I created the device node
and executed the application, I could see that the printk's in the driver
are getting executed for open, release and ioctl. For read, the function
doesnt seem calling the drivers read routine and exits with -1. However the
same is called when I do a cat < /dev/devnode. Am I missing something ?
--------------------------------------------------------------------------------------------------------------
<Code Snip - Driver>
static struct file_operations co_stream_fops = {
.owner = THIS_MODULE,
.open = co_stream_open,
.read = co_stream_read,
.write = co_stream_write,
// .ioctl = co_stream_ioctl,
.release = co_stream_release
};
static int __init co_stream_init(void)
{
unsigned int *tmp;
int i=0;
dbprintk("Welcome !!!\n");
if (!request_mem_region(STREAM_PHY_ADDR, STREAM_PHY_SIZE, DRIVER_NAME) )
{
printk("Failed to lock the memory...\n");
goto out;
}
if (!(remapped_address = ioremap(STREAM_PHY_ADDR, STREAM_PHY_SIZE)) )
{
printk("Failed to remap...\n");
goto out;
}
printk("Address remapped to 0x%08X.\n", remapped_address);
Major = register_chrdev( 0, DEVICE_NAME, &co_stream_fops); <=========
Registered fops
if (Major < 0)
{
printk("Registration of the device failed.\n\n");
goto out;
}
}
static ssize_t co_stream_read(struct file *filp, char __user *buf, size_t
size, loff_t *l)
{
printk("\n co_stream_read() is called.\n");
int data,status;
/* Wait while empty. */
while (((status=readl( ((volatile unsigned char*) remapped_address)
+ 8)&3))==0)
...
--------------------------------------------------------------------------------------------------------------
<Code Snip - Application>
printf("CPU listening for hello...\n\r");
for ( i = 0; i < 10; i++ ) {
cstream_read(hello_in, &hi, sizeof(int));
printf("FPGA hardware says: %d\n\r", hi);
}
int cstream_read(cstream stream, void *buffer, int size)
{
int nbytes;
/* TO ADD : Error handing calls here */
printf("Value of stream = 0x%08X, stream->fd = %d. \n",
stream, stream->fd);
printf("Value of buffer = 0x%08X, size = %d. \n", buffer, size );
if (stream) {
nbytes = read(stream->fd, buffer, size);
printf("read bytes from hardware = %d.\n", nbytes);
}
else
printf("stream is NULL here.\n");
return(0);
}
--------------------------------------------------------------------------------------------------------------
<From System.map>
c00de4d0 t sysrq_handle_reboot
c00de4fc T handle_sysrq
c00de524 t co_stream_write
c00de550 t co_stream_release
c00de598 t co_stream_open
c00de624 t co_stream_read
c00de760 t __uart_start
----------------------------------------
<From console output fops dump>
[ 0.383898] Welcome !!!
[ 0.384445] Address remapped to 0xC5000000.
[ 0.384628]
[ 0.384653]
[ 0.384675] Impulse Costream assigned with Major = 254.
[ 0.384743] Memory dump of fops structure.
[ 0.384803] Address : 0xC01CA350, 0x00000000.
[ 0.384867] Address : 0xC01CA354, 0x00000000.
[ 0.384932] Address : 0xC01CA358, 0xC00DE624.
[ 0.384996] Address : 0xC01CA35C, 0xC00DE524.
[ 0.385060] Address : 0xC01CA360, 0x00000000.
[ 0.385122] Address : 0xC01CA364, 0x00000000.
[ 0.385185] Address : 0xC01CA368, 0x00000000.
[ 0.385248] Address : 0xC01CA36C, 0x00000000.
[ 0.385311] Address : 0xC01CA370, 0x00000000.
[ 0.385374] Address : 0xC01CA374, 0x00000000.
[ 0.385437] Address : 0xC01CA378, 0x00000000.
[ 0.385499] Address : 0xC01CA37C, 0x00000000.
[ 0.385565] Address : 0xC01CA380, 0xC00DE598.
[ 0.385627] Address : 0xC01CA384, 0x00000000.
[ 0.385693] Address : 0xC01CA388, 0xC00DE550.
[ 0.385756] Address : 0xC01CA38C, 0x00000000.
[ 0.385818] Address : 0xC01CA390, 0x00000000.
[ 0.385881] Address : 0xC01CA394, 0x00000000.
[ 0.385944] Address : 0xC01CA398, 0x00000000.
[ 0.386007] Address : 0xC01CA39C, 0x00000000.
[ 0.386070] Address : 0xC01CA3A0, 0x00000000.
[ 0.386133] Address : 0xC01CA3A4, 0x00000000.
[ 0.386196] Address : 0xC01CA3A8, 0x00000000.
[ 0.386259] Address : 0xC01CA3AC, 0x00000000.
Any help or pointers would be helpful.
Thanks and Regards,
Ramkumar.
[-- Attachment #2: Type: text/html, Size: 6784 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc8-mm1 Kernel oops will running kernbench
From: Balbir Singh @ 2008-01-18 10:54 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, Andrew Morton, Paul Mackerras, linux-kernel
In-Reply-To: <479082F0.2040109@linux.vnet.ibm.com>
* Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> [2008-01-18 16:14:00]:
> Paul Mackerras wrote:
> > Kamalesh Babulal writes:
> >
> >>>>> NIP: 0000000000004570 LR: 000000000fc42dc0 CTR: 0000000000000000
> >>>>> REGS: c00000077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> >>>>> MSR: 8000000000001000 <ME> CR: 28022422 XER: 00000000
> >>>>> DAR: c00000077b6bfce0, DSISR: 000000000a000000
> >
> > Actually, how much RAM does this machine have? If it has less than
> > 32GB, then the problem is that the kernel stack pointer is bogus.
> > (How it got to be bogus is the interesting question, of course. :)
> >
> > Paul.
> >
> Hi Paul,
>
> The machine has around 30GB of RAM, do you want me to try, by taking
> the git-powerpc.patch out of the series and try reproducing the oops.
>
Kamalesh, I thought I saw Paul's request for trying without
git-powerpc.patch (it's in a separate email).
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH 2/2] mpc82xx: Embedded Planet EP8248E support
From: Sergej Stepanov @ 2008-01-18 11:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080117223205.GB17300@loki.buserror.net>
> + /* "Serial" port/SCC1 */
> + scc1: serial@11a00 {
> + device_type =3D "serial";
> + compatible =3D "fsl,mpc8248-scc-uart",
> + "fsl,cpm2-scc-uart";
> + reg =3D <0x11a00 0x20 0x8000 0x100>;
> + interrupts =3D <40 8>;
are you sure with 40 as interrupt? has not it be "28"(hex) here?
> + interrupt-parent =3D <&PIC>;
> + fsl,cpm-brg =3D <1>;
> + fsl,cpm-command =3D <0x00800000>;
> + linux,planetcore-label =3D "SCC1";
> + };
--=20
Dipl.-Ing. Sergej Stepanov=20
Software-Entwicklung
IDS GmbH=20
E-PA (Entwicklung - Prozess Automatisierung)
Nobelstr. 18,=20
D-76275 Ettlingen=20
T. (0) 72 43/2 18-615=20
F. (0) 72 43/2 18-100=20
E. Sergej.Stepanov@ids.de
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503=20
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox