* Re: SCHED_FIFO & System()
From: Matias Sundman @ 2008-01-18 6:38 UTC (permalink / raw)
To: Scott Wood, Arnon Kaufman(Work); +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <478FD3B7.2030105@freescale.com>
Hello,
/>>Are you running a preemptible kernel? [Scott]/
Yes the Kernel is configured as - Preemptible Kernel (Low-Latency Desktop)
/>>//what you actually need is a better kernel preemption such as using
Ingo Molnar 's PREEMPT_RT patch. (it may reduce performance a little)
[Arnon]
/
Ok - we can try to enable the PREEMPT_RT patches.
-------------------------------
I also tried with a sched_yield() before the call to system() in order
to see if the behavior changed somewhat but it didn't.
Cheers // Matias :-)
Scott Wood skrev:
> Matias Sundman wrote:
>
>> Hello,
>> I have some strange behavior in one of my systems.
>>
>> I have a real-time thread under SCHED_FIFO which is running every 10ms.
>> It is blocking on a semaphore and released by a timer interrupt every 10ms.
>> Generally this works really well.
>>
>> However, there is a module in the system that makes a / system() / call
>> from c-code ;
>>
>> system("run_my_script");
>>
>> By calling and running a bash script. Independent of how the actual
>> script looks like the real time thread does not get scheduled under 80ms
>> -- the time it takes
>> for the system() call to finish.
>>
>
> Are you running a preemptible kernel?
>
> -Scott
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[From : Arnon Kaufman(Work) <arnon.work@gmail.com>]
I've seen this kind of behavior. i may guess that you configure the
kernel with PREEMPT, assuming it will solve the problem for you.
I'll split the problem into two:
1. program loading stage is finished (+ reschedule)
2. thread execution time (delay)
when executing a new application it's involved with plenty of kernel
activity such as fetching the application from storage, loader
relocation,allocating and remapping pages, resolving dynamic linking
etc..., all the activity occurs under the hood of the kernel, suspending
most of the kernel activities, due to many spin locks on the way. that
delays other kernel threads as well, and even workqueues.
trying to bypass the symptom - re-running the exact external
application , should not be involved with a second delay, as it was
cached. so may be running the external application in advance may be
good enough for you.
what you actually need is a better kernel preemption such as using Ingo
Molnar 's PREEMPT_RT patch. (it may reduce performance a little).
the second part is that the scheduler delays the thread execution as it
think other kernel's entities has a higher priority such as softirqs,
workqueue, etc...
the PREEMPT_RT may solve this problem as well as it bring a better
priority control, with the addition of priority inheritance.
^ permalink raw reply
* Re: [PATCH] Convert MPC837x device trees to dts-v1
From: Kumar Gala @ 2008-01-18 6:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <5863BE5F-95D7-499C-AFC4-C7ECE62847D4@kernel.crashing.org>
On Jan 18, 2008, at 12:31 AM, Kumar Gala wrote:
>
> On Jan 8, 2008, at 5:32 AM, Li Yang wrote:
>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/boot/dts/mpc8377_mds.dts | 148 +++++++++++++++
>> +---------------
>> arch/powerpc/boot/dts/mpc8378_mds.dts | 140 ++++++++++++++
>> +---------------
>> arch/powerpc/boot/dts/mpc8379_mds.dts | 156 ++++++++++++++++
>> +----------------
>> 3 files changed, 225 insertions(+), 219 deletions(-)
>
> applied.
I dropped the "fsl,pq2pro-sata" compat prop. We need to come up with
something a bit more generic.
- k
^ permalink raw reply
* Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
From: Kumar Gala @ 2008-01-18 6:45 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <20071206225121.31080.86606.stgit@localhost.localdomain>
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> With that patch fixed.c now fully emulates MDIO bus, thus no need
> to duplicate PHY layer functionality. That, in turn, drastically
> simplifies the code, and drops down line count.
>
> As an additional bonus, now there is no need to register MDIO bus
> for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
> There is also no more need to pre-allocate PHYs via .config option,
> this is all now handled dynamically.
>
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Acked-by: Jeff Garzik <jeff@garzik.org>
>
> ---
>
> drivers/net/phy/Kconfig | 32 +--
> drivers/net/phy/fixed.c | 445 +++++++++++++++++----------------------------
> include/linux/phy_fixed.h | 51 ++---
> 3 files changed, 195 insertions(+), 333 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: Vitesse 7385 PHY is not connected to the MDIO bus
From: Kumar Gala @ 2008-01-18 6:46 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <20071206225139.31080.18384.stgit@localhost.localdomain>
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> ...thus use fixed-link to register proper "Fixed PHY"
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Kumar Gala @ 2008-01-18 6:46 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, Paul Mackerras, linuxppc-dev
In-Reply-To: <20071206225131.31080.7872.stgit@localhost.localdomain>
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> not connected to the real MDIO bus.
>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> ---
>
> Documentation/powerpc/booting-without-of.txt | 4 +
> arch/powerpc/sysdev/fsl_soc.c | 79 ++++++++++++++++++++------
> 2 files changed, 66 insertions(+), 17 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH v7] qe: add ability to upload QE firmware
From: Kumar Gala @ 2008-01-18 6:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, sfr
In-Reply-To: <11998098582795-git-send-email-timur@freescale.com>
On Tue, 8 Jan 2008, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and instructions
> on how to upload it. Add function qe_upload_firmware() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include the actual RISC Special Registers. Added description of a new
> QE firmware node to booting-without-of.txt.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> Updated w.r.t. comments from Stephen R.
>
> This patch is for Kumar's for-2.6.25 branch. This code is necessary for
> my QE UART driver.
>
> Documentation/powerpc/00-INDEX | 3 +
> Documentation/powerpc/booting-without-of.txt | 33 +++-
> Documentation/powerpc/qe_firmware.txt | 295 ++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig | 1 +
> arch/powerpc/sysdev/qe_lib/qe.c | 247 +++++++++++++++++++++
> include/asm-powerpc/immap_qe.h | 34 +++-
> include/asm-powerpc/qe.h | 61 ++++++
> 7 files changed, 670 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/powerpc/qe_firmware.txt
>
applied.
- k
^ permalink raw reply
* 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
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