* Re: [PATCH] libfdt: Improve documentation in libfdt.h
From: David Gibson @ 2008-07-10 1:38 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20080709092243.10615.84477.stgit@leda.ptxnet.pengutronix.de>
On Wed, Jul 09, 2008 at 11:22:44AM +0200, Wolfram Sang wrote:
> Fix a few typos and mistakes.
Oops, some of those are rather embarrassing.
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC][WIP][PATCH] powerpc: Refactor device bindings
From: David Gibson @ 2008-07-10 1:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807080818440.5899@blarg.am.freescale.net>
On Tue, Jul 08, 2008 at 08:20:56AM -0500, Kumar Gala wrote:
> Moved Freescale SoC related bindings out of booting-without-of.txt and into
> their own files.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Of course, what I'd *really* like to do is to get a website / wiki set
up somewhere to be the definitive home of all bindings, but I don't
think it's going to happen any time real soon.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 1/2] Fix copper/fiber auto-selection for 88e1111
From: Wang Jian @ 2008-07-10 2:14 UTC (permalink / raw)
To: linuxppc-dev
The 27.15 bit (MII_M1111_HWCFG_FIBER_COPPER_AUTO) is disable bit. When
set to 1, copper/fiber auto selection is disabled. The current code
to enable but actually disable auto selection.
Signed-off-by: Wang Jian <lark@linux.net.cn>
---
drivers/net/phy/marvell.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 32a8503..737512c 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -162,7 +162,7 @@ static int m88e1111_config_init(struct phy_device
*phydev)
/* Enable Fiber/Copper auto selection */
temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
- temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ temp &= ~MII_M1111_HWCFG_FIBER_COPPER_AUTO;
phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
temp = phy_read(phydev, MII_BMCR);
--
1.5.5.4
^ permalink raw reply related
* [PATCH 0/2] Fix register misuse in drivers/net/phy/marvel.c
From: Wang Jian @ 2008-07-10 2:14 UTC (permalink / raw)
To: linuxppc-dev
These 2 patches fixed misuse of register for 88e1111.
Notice: These two patches didn't fix some auto selection problem yet. I
will discuss the problem in seperate email.
^ permalink raw reply
* [PATCH 2/2] Fix 88e1111 copper/fiber selection in RGMII mode
From: Wang Jian @ 2008-07-10 2:14 UTC (permalink / raw)
To: linuxppc-dev
MII_M1111_HWCFG_FIBER_COPPER_RES is a bit of MII_M1111_PHY_EXT_SR, not
MII_M1111_PHY_EXT_CR.
Signed-off-by: Wang Jian <lark@linux.net.cn>
---
drivers/net/phy/marvell.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 737512c..4aa5479 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -158,7 +158,6 @@ static int m88e1111_config_init(struct phy_device
*phydev)
{
int err;
int temp;
- int mode;
/* Enable Fiber/Copper auto selection */
temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
@@ -198,9 +197,7 @@ static int m88e1111_config_init(struct phy_device
*phydev)
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
- mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
-
- if (mode & MII_M1111_HWCFG_FIBER_COPPER_RES)
+ if (temp & MII_M1111_HWCFG_FIBER_COPPER_RES)
temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
else
temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
--
1.5.5.4
^ permalink raw reply related
* Re: [PATCH 0/2] Fix register misuse in drivers/net/phy/marvel.c
From: Wang Jian @ 2008-07-10 2:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4875707D.8060808@linux.net.cn>
It may not be appropriate to post here instead of netdev, but I am using
powerpc dev board and I think there will be someone here who has board
to test.
Wang Jian 写道:
> These 2 patches fixed misuse of register for 88e1111.
>
> Notice: These two patches didn't fix some auto selection problem yet. I
> will discuss the problem in seperate email.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* linux/powerpc memory management
From: sumedh tirodkar @ 2008-07-10 4:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
Can anyone give pointers as to how memory management(detailed) is done in
linux on powerpc.
Regards,
Sumedh
[-- Attachment #2: Type: text/html, Size: 122 bytes --]
^ permalink raw reply
* linux-next: manual merge of the galak tree
From: Stephen Rothwell @ 2008-07-10 4:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev, linux-next
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi Kumar,
Today's linux-next merge of the galak tree got a conflict in
Documentation/powerpc/booting-without-of.txt between commit
a5edeccb1a8432ae5d9fb9bccea5a4b64c565017 ("net: OpenFirmware GPIO based
MDIO bitbang driver") from the net tree and commit
a5b420dc2ff8423b30506e805584f30875b5fb57 ("powerpc/fsl: Refactor device
bindings") from the galak tree.
I left the "MDIO on GPIOs" section there and relabeled it as 'g'.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: neeraj garg @ 2008-07-10 7:25 UTC (permalink / raw)
To: Grant Likely, John.Linn, marco.stornelli; +Cc: linuxppc-embedded
In-Reply-To: <20080709143318.GB26524@secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
Hi,
Yes I am using ARCH=ppc (actual line is $make ARCH=ppc
CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I have
placed ramdisk.image.gz in arch/ppc/boot/images. In case of ARCH=powerpc
I cannot find processor type 405 , in make menuconfig. Thats why i am
using ARCH=ppc.
And when I give kernel command string as init=/bin/sh , it says :
>Failed to execute /bin/sh. Attempting defaults...
[ 3.744035] Kernel panic - not syncing: No init found. Try passing
init= option to kernel.
[ 3.768073] Rebooting in 30 seconds..
--init is present in sbin/init which is a soft link to ../bin/busybox
--I used powepc-405-gnu-readelf -h bin/sh to verify that it is compiled
for powerpc itself.
Any other suggestions ?
-----------------------------------------------------
Neeraj Garg
Grant Likely wrote:
> On Wed, Jul 09, 2008 at 10:24:13AM +0530, neeraj garg wrote:
>
>> Hi,
>>
>> I am trying to boot ML405 with Linux source code downloaded from
>> http://www.git.xilinx.com . My cross compiler tool chain version is
>> gcc-3.4.1, glibc-2.3.2 and binutils-2.15. I have also downloaded RAMDISK
>> from same url (http://www.git.xilinx.com). When I download
>> zImage.initrd.elf using XMD everything goes fine, untill RAMDISK is
>> uncompressed, I get following messages :
>>
>>
> <snip>
>
>> [ 3.736691] Failed to
>> execute /sbin/init. Attempting defaults...
>> [ 3.748073] Kernel panic - not syncing: No init found. Try passing
>> init= option to kernel.
>> [ 3.772040] Rebooting in 180 seconds..[ 183.487314] Signal: 8
>>
>>
>
> Try changing the kernel parameters line to specify init=/bin/sh and see
> what happens.
>
> g.
>
[-- Attachment #2: Type: text/html, Size: 2500 bytes --]
^ permalink raw reply
* [PATCH] MPC52xx PCI write combine timer
From: Andre Schwarz @ 2008-07-10 9:53 UTC (permalink / raw)
To: linux-ppc list
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
On MPC52xx the PCI target control register (PCITCR) @ MBAR + 0xD6C is initialized with
only bit 7 (Latrule disable) set. The 8-Bit write combine timer (Bits 24..31) should be
also set to a reasonable value _greater zero_ (0x08 = default) since setting it to 0x00
leads to _very poor_ performance as a PCI target since external burst won't be possible
at all.
Setting the WCT to 0x08 (cache-line size) leads to good overall perfomance.
Signed-off-by: Andre Schwarz <andre.schwarz@matrix-vision.de>
---
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: patch_mpc5200b_wct --]
[-- Type: text/plain, Size: 867 bytes --]
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index e3428dd..5a382bb 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -63,6 +63,7 @@
#define MPC52xx_PCI_TCR_P 0x01000000
#define MPC52xx_PCI_TCR_LD 0x00010000
+#define MPC52xx_PCI_TCR_WCT8 0x00000008
#define MPC52xx_PCI_TBATR_DISABLE 0x0
#define MPC52xx_PCI_TBATR_ENABLE 0x1
@@ -313,7 +314,7 @@ mpc52xx_pci_setup(struct pci_controller *hose,
out_be32(&pci_regs->tbatr1,
MPC52xx_PCI_TBATR_ENABLE | MPC52xx_PCI_TARGET_MEM );
- out_be32(&pci_regs->tcr, MPC52xx_PCI_TCR_LD);
+ out_be32(&pci_regs->tcr, MPC52xx_PCI_TCR_LD | MPC52xx_PCI_TCR_WCT8);
tmp = in_be32(&pci_regs->gscr);
#if 0
^ permalink raw reply related
* Re: [PATCH] powerpc: i2c-ibm_iic register child nodes
From: Jean Delvare @ 2008-07-10 11:49 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Linux I2C, Ben Dooks
In-Reply-To: <20080708144609.14bae1de@lappy.seanm.ca>
Hi Sean,
On Tue, 8 Jul 2008 14:46:09 -0400, Sean MacLennan wrote:
> This patch completes the conversion of the IBM IIC driver to an
> of-platform driver.
>
> It removes the index from the IBM IIC driver and makes it an unnumbered
> driver. It then calls of_register_i2c_devices to properly register all
> the child nodes in the DTS.
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
>
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
> index 070f078..651f2f1 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -43,6 +43,7 @@
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> #include <linux/of_platform.h>
> +#include <linux/of_i2c.h>
>
> #include "i2c-ibm_iic.h"
>
> @@ -696,7 +697,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
> struct device_node *np = ofdev->node;
> struct ibm_iic_private *dev;
> struct i2c_adapter *adap;
> - const u32 *indexp, *freq;
> + const u32 *freq;
> int ret;
>
> dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> @@ -707,14 +708,6 @@ static int __devinit iic_probe(struct of_device *ofdev,
>
> dev_set_drvdata(&ofdev->dev, dev);
>
> - indexp = of_get_property(np, "index", NULL);
> - if (!indexp) {
> - dev_err(&ofdev->dev, "no index specified\n");
> - ret = -EINVAL;
> - goto error_cleanup;
> - }
> - dev->idx = *indexp;
> -
> dev->vaddr = of_iomap(np, 0);
> if (dev->vaddr == NULL) {
> dev_err(&ofdev->dev, "failed to iomap device\n");
> @@ -757,14 +750,16 @@ static int __devinit iic_probe(struct of_device *ofdev,
> adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> adap->algo = &iic_algo;
> adap->timeout = 1;
> - adap->nr = dev->idx;
>
> - ret = i2c_add_numbered_adapter(adap);
> + ret = i2c_add_adapter(adap);
> if (ret < 0) {
> dev_err(&ofdev->dev, "failed to register i2c adapter\n");
> goto error_cleanup;
> }
>
> + /* Now register all the child nodes */
> + of_register_i2c_devices(adap, np);
> +
> dev_info(&ofdev->dev, "using %s mode\n",
> dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
>
Looks OK. As I already have patches touching
drivers/i2c/busses/i2c-ibm_iic.c in my tree, I'm taking this patch
also. I will push it upstream during the 2.6.27 merge window.
Thanks,
--
Jean Delvare
^ permalink raw reply
* [BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
From: Wolfram Sang @ 2008-07-10 12:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: domen.puncer
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Hello,
today, I was debugging a kernel crash on a board with a MPC5200B using
2.6.26-rc9. I found the following code in drivers/net/fec_mpc52xx.c:
static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
{
[...]
/* on fifo error, soft-reset fec */
if (ievent & (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
if (net_ratelimit() && (ievent & FEC_IEVENT_RFIFO_ERROR))
dev_warn(&dev->dev, "FEC_IEVENT_RFIFO_ERROR\n");
if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
mpc52xx_fec_reset(dev);
netif_wake_queue(dev);
return IRQ_HANDLED;
}
[...]
}
Calling mpc52xx_fec_reset() from interrupt context is bad, at least
because
a) it calls phy_write, which contains BUG_ON(in_interrupt())
b) it calls mpc52xx_fec_hw_init, which has a delay-loop to check
if the reset was successful (1..50 us)
I assume the proper thing to do is to set a flag in the ISR and handle
the soft reset later in some other context. Having never dealt with the
network core and its drivers so far, I am not sure which place would be
the right one to perform the soft reset. To not make things worse, I
hope people with more insight to network stuff can deliver a suitable
solution to this problem.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][WIP][PATCH] powerpc: Refactor device bindings
From: Kumar Gala @ 2008-07-10 13:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080710015212.GD26724@yookeroo.seuss>
On Jul 9, 2008, at 8:52 PM, David Gibson wrote:
> On Tue, Jul 08, 2008 at 08:20:56AM -0500, Kumar Gala wrote:
>> Moved Freescale SoC related bindings out of booting-without-of.txt
>> and into
>> their own files.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
> Of course, what I'd *really* like to do is to get a website / wiki set
> up somewhere to be the definitive home of all bindings, but I don't
> think it's going to happen any time real soon.
agreed, I know there has been some talk of power.org trying to do
this, but not sure what happened there.
- k
^ permalink raw reply
* Related to ftp
From: Misbah khan @ 2008-07-10 13:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
If we do ftp to the board where actually all the messages (ftp related log
message)
are logged.
If any of you could at least tell me the directory path.
Thank you
--
View this message in context: http://www.nabble.com/Related-to-ftp-tp18382890p18382890.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-07-10 13:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20080710031305.0ccede72.sfr@canb.auug.org.au>
On Jul 9, 2008, at 12:13 PM, Stephen Rothwell wrote:
> Hi Kumar,
>
> On Wed, 9 Jul 2008 08:13:03 -0500 (CDT) Kumar Gala <galak@kernel.crashing.org
> > wrote:
>>
>> Please pull from 'powerpc-next' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/dts.git powerpc-
>> next
>
> $ git ls-remote ssh://master.kernel.org/pub/scm/linux/kernel/git/galak/dts.git
> fatal: '/pub/scm/linux/kernel/git/galak/dts.git': unable to chdir or
> not a git archive
> fatal: The remote end hung up unexpectedly
>
> Did you mean ".../powerpc.git"?
yes. the script I use was run from the wrong dir.
> Also, the master branch of that tree has the same problem I came up
> against in linux-next today: include/asm-powerpc/pgtable-ppc64.h
> mismerges between Linus' tree and the Paul's tree so you end up with
> two
> copies of huge_ptep_set_wrprotect. So you should amend the merge to
> remove one.
Thanks, will fix up by hand.
- k
^ permalink raw reply
* Re: [PATCH 15/16 v3] [v2] ibmvscsi: driver enablement for CMO
From: Brian King @ 2008-07-10 13:43 UTC (permalink / raw)
To: Robert Jennings; +Cc: linux-scsi, linuxppc-dev, David Darrington, paulus
In-Reply-To: <20080708203553.GA20206@linux.vnet.ibm.com>
Acked by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: latencytop support for powerpc?
From: Arnd Bergmann @ 2008-07-10 13:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <48755237.9070701@nortel.com>
On Thursday 10 July 2008, Chris Friesen wrote:
> Just wondering if anyone has looked at what it would take to support
> latency top on powerpc?
Just guessing something like the patch below, not more that that, but
without the bugs ;-). Haven't tested at all, so it will probably
fall apart, but give it a try if you like.
Subject: powerpc: support for latencytop
Implement save_stack_trace_tsk on powerpc, so that we can run with
latencytop.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ff5217a..b1fd369 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -53,6 +53,9 @@ config STACKTRACE_SUPPORT
bool
default y
+config HAVE_LATENCYTOP_SUPPORT
+ def_bool y
+
config TRACE_IRQFLAGS_SUPPORT
bool
depends on PPC64
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index 9861f17..2b8c14d 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -10,19 +10,18 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/module.h>
#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <asm/ptrace.h>
+#include <asm/processor.h>
/*
* Save stack-backtrace addresses into a stack_trace buffer.
*/
-void save_stack_trace(struct stack_trace *trace)
+static void save_context_stack(struct stack_trace *trace, unsigned long sp,
+ struct task_struct *tsk, int savesched)
{
- unsigned long sp;
-
- asm("mr %0,1" : "=r" (sp));
-
for (;;) {
unsigned long *stack = (unsigned long *) sp;
unsigned long newsp, ip;
@@ -33,10 +32,12 @@ void save_stack_trace(struct stack_trace *trace)
newsp = stack[0];
ip = stack[STACK_FRAME_LR_SAVE];
- if (!trace->skip)
- trace->entries[trace->nr_entries++] = ip;
- else
- trace->skip--;
+ if (savesched || !in_sched_functions(ip)) {
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+ }
if (trace->nr_entries >= trace->max_entries)
return;
@@ -44,4 +45,19 @@ void save_stack_trace(struct stack_trace *trace)
sp = newsp;
}
}
+
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ save_context_stack(trace, sp, current, 1);
+}
EXPORT_SYMBOL_GPL(save_stack_trace);
+
+void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+{
+ save_context_stack(trace, tsk->thread.regs->gpr[1], tsk, 0);
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
^ permalink raw reply related
* [PATCH] powerpc: support for latencytop
From: Arnd Bergmann @ 2008-07-10 14:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200807101557.22354.arnd@arndb.de>
Implement save_stack_trace_tsk on powerpc, so that we can run with
latencytop.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
On Thursday 10 July 2008, Arnd Bergmann wrote:
> Just guessing something like the patch below, not more that that, but
> without the bugs ;-).
Obvious bug #1: needs to use the task we want to dump, not 'current'.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ff5217a..b1fd369 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -53,6 +53,9 @@ config STACKTRACE_SUPPORT
bool
default y
+config HAVE_LATENCYTOP_SUPPORT
+ def_bool y
+
config TRACE_IRQFLAGS_SUPPORT
bool
depends on PPC64
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index 9861f17..6a4fb00 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -10,33 +10,34 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/module.h>
#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <asm/ptrace.h>
+#include <asm/processor.h>
/*
* Save stack-backtrace addresses into a stack_trace buffer.
*/
-void save_stack_trace(struct stack_trace *trace)
+static void save_context_stack(struct stack_trace *trace, unsigned long sp,
+ struct task_struct *tsk, int savesched)
{
- unsigned long sp;
-
- asm("mr %0,1" : "=r" (sp));
-
for (;;) {
unsigned long *stack = (unsigned long *) sp;
unsigned long newsp, ip;
- if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD))
+ if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
newsp = stack[0];
ip = stack[STACK_FRAME_LR_SAVE];
- if (!trace->skip)
- trace->entries[trace->nr_entries++] = ip;
- else
- trace->skip--;
+ if (savesched || !in_sched_functions(ip)) {
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+ }
if (trace->nr_entries >= trace->max_entries)
return;
@@ -44,4 +45,19 @@ void save_stack_trace(struct stack_trace *trace)
sp = newsp;
}
}
+
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ save_context_stack(trace, sp, current, 1);
+}
EXPORT_SYMBOL_GPL(save_stack_trace);
+
+void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
+{
+ save_context_stack(trace, tsk->thread.regs->gpr[1], tsk, 0);
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
^ permalink raw reply related
* RE: Booting ML405 (Kernel panic - not syncing: No init found)
From: John Linn @ 2008-07-10 14:21 UTC (permalink / raw)
To: neeraj garg, grant.likely, marco.stornelli; +Cc: lorenzo, linuxppc-embedded
In-Reply-To: <4875B95C.8020809@cdac.in>
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
With regards to arch/ppc:
I just built and tested it from the Xilinx Git tree (with ELDK 4.1) and
don't see the problem you see. You shouldn't need anything on the
command line for the init, but I tried it matching yours without any
issue.
I noticed that you are using a UART Lite and I test with 16550. We have
a reference design available for the 405 also to help you get a baseline
before you make changes, you can see where to get it at
http://git.xilinx.com <http://git.xilinx.com/> also. Getting a good
solid baseline before you make changes can make life easier, and maybe
you already did this and I don't realize it ;).
I can't tell how your kernel is configured, so I would use the Xilinx
provided default kernel configuration, then make changes from there
(like from 8250 UART and console to UART Lite).
>make ARCH=ppc ml405_defconfig
>make ARCH=ppc zImage.initrd
Since you pulled from the Xilinx Git tree, you should be able to get the
ML405 running easily (assuming I have done my job right).
You should be able to use arch/powerpc and it would be best to do that
as arch/ppc is not well supported now. If you use the Xilinx default
kernel configuration you shouldn't need to do anything (such as finding
405 in the menuconfig) if you use our reference design for the board
(bit stream).
I just tested from the Xilinx Git tree on the ML405 with arch/powerpc
and it looked good (using ELDK 4.1 tools). The following commands
should build a kernel that runs on it. You might want to update if you
haven't pulled from the Xilinx Git tree in a while (git pull, or clone
the tree again in a new directory).
>make ARCH=powerpc mrproper
>make ARCH=powerpc ml405_defconfig
>make ARCH=powerpc zImage.initrd
With regards to the fact that you're restricting the memory to 32 Meg,
you might get try not doing this to get the kernel running properly,
then make that change.
Hope that helps,
John
________________________________
From: neeraj garg [mailto:neerajg@cdac.in]
Sent: Thursday, July 10, 2008 1:25 AM
To: grant.likely@secretlab.ca; John Linn; marco.stornelli@coritel.it
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Booting ML405 (Kernel panic - not syncing: No init found)
Hi,
Yes I am using ARCH=ppc (actual line is $make ARCH=ppc
CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I have
placed ramdisk.image.gz in arch/ppc/boot/images. In case of ARCH=powerpc
I cannot find processor type 405 , in make menuconfig. Thats why i am
using ARCH=ppc.
And when I give kernel command string as init=/bin/sh , it says :
>Failed to execute /bin/sh. Attempting defaults...
[ 3.744035] Kernel panic - not syncing: No init found. Try passing
init= option to kernel.
[ 3.768073] Rebooting in 30 seconds..
--init is present in sbin/init which is a soft link to ../bin/busybox
--I used powepc-405-gnu-readelf -h bin/sh to verify that it is compiled
for powerpc itself.
Any other suggestions ?
-----------------------------------------------------
Neeraj Garg
Grant Likely wrote:
On Wed, Jul 09, 2008 at 10:24:13AM +0530, neeraj garg wrote:
Hi,
I am trying to boot ML405 with Linux source code downloaded from
http://www.git.xilinx.com . My cross compiler tool chain version
is
gcc-3.4.1, glibc-2.3.2 and binutils-2.15. I have also downloaded
RAMDISK
from same url (http://www.git.xilinx.com). When I download
zImage.initrd.elf using XMD everything goes fine, untill RAMDISK
is
uncompressed, I get following messages :
<snip>
[ 3.736691] Failed
to
execute /sbin/init. Attempting defaults...
[ 3.748073] Kernel panic - not syncing: No init found. Try
passing
init= option to kernel.
[ 3.772040] Rebooting in 180 seconds..[ 183.487314]
Signal: 8
Try changing the kernel parameters line to specify init=/bin/sh and see
what happens.
g.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 21633 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Fix register misuse in drivers/net/phy/marvel.c
From: Wang Jian @ 2008-07-10 14:32 UTC (permalink / raw)
To: Welch, Martyn (GE EntSol, Intelligent Platforms); +Cc: linuxppc-dev
In-Reply-To: <1CADFA951940554D86FBD8B24BBFF3A0019BEA37@LONMLVEM08.e2k.ad.ge.com>
Welch, Martyn (GE EntSol, Intelligent Platforms) 写道:
> Wang Jian wrote:
>> It may not be appropriate to post here instead of netdev, but I am
>> using
>> powerpc dev board and I think there will be someone here who has board
>> to test.
>>
>> Wang Jian 写道:
>>> These 2 patches fixed misuse of register for 88e1111.
>>>
>>> Notice: These two patches didn't fix some auto selection problem
>>> yet. I will discuss the problem in seperate email.
>>>
>
> Hi,
>
> I have a board here with a pair of 88e1111's, though I'm not sure how to go about testing these patches. It's not the applying or compiling that the problem, but how to test it...
>
> Do you have any test case in mind?
>
Hi,
The problem I want to fix is:
1. Plug the fiber and start the board in u-boot, the fiber link is
established, you can transfer data using fiber link;
2. boot the kernel (not fixed one), when you "ifconfig ethX up" (ethX
uses 88e1111), the fiber link light goes off, the fiber link is lost;
After apply the patch #1, for the step 2, you can "ifconfig ethX
w.x.y.z" and fiber link is ok. You can use the fiber link to transfer data.
I my case, the chip is in GMII mode. The patch #2 is obvious but I can't
test it myself.
BTW, the two patches doesn't fix the problem when you unplug the fiber
then plug back. That is another problem I have _partially_ fixed by
patch marvell_read_status().
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 02/02] powerpc/cell: add support for power button of future IBM cell blades
From: Arnd Bergmann @ 2008-07-10 14:34 UTC (permalink / raw)
To: linuxppc-dev, benh; +Cc: Christian Krafft, cbe-oss-dev, Christian Krafft
In-Reply-To: <1215636330.8970.387.camel@pasglop>
On Wednesday 09 July 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-09 at 15:15 +0200, Arnd Bergmann wrote:
> > Ugly, but doable, yes. I wonder if there is a way that we can trigger some
> > interrupt from system_reset_exception context in order to get around the
> > polling though. tasklets and workqueues unfortunately won't do us any good
> > here because they also depend on disabling interrupts.
>
> You can trigger a DEC interrupt at any time but you don't have
> a nice hook to catch it. You can probably trigger an IPI to yourself
> using a special call to the iic, do we have any available number ?
Yes, we are only using 4 out of 15 possible IPIs. Probably worth a try,
but it might not be cleaner than your suggested solution.
Arnd <><
^ permalink raw reply
* XSysAce: Queue is plugged
From: Joachim Meyer @ 2008-07-10 14:49 UTC (permalink / raw)
To: linuxppc-embedded
Hi
XSysAce: Queue is plugged
Can someone say me what this means and how to get rid of it=3F
I use a 2.6.23 xilinx Kernel on a XUPv2p. In the Kernel config-menu are 2 =
sysace drivers:
< > Xilinx SystemACE support
and=20
< > Xilinx SystemACE support (old driver)
I'm using the old driver because if I try to compile with the other it end=
s in this:
--------------------------------------------------------------------------=
--------------------------------
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC drivers/block/xsysace.o
drivers/block/xsysace.c:461: warning: `request=5Fqueue=5Ft' is deprecated (dec=
lared at include/linux/blkdev.h:40)
drivers/block/xsysace.c: In function `ace=5Ffsm=5Fdostate':
drivers/block/xsysace.c:627: warning: long unsigned int format, different =
type arg (arg 3)
drivers/block/xsysace.c: At top level:
drivers/block/xsysace.c:828: warning: `request=5Fqueue=5Ft' is deprecated (dec=
lared at include/linux/blkdev.h:40)
drivers/block/xsysace.c: In function `ace=5Fexit':
drivers/block/xsysace.c:1152: error: void value not ignored as it ought to=
be
make[2]: *** [drivers/block/xsysace.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
--------------------------------------------------------------------------=
--------------------------------------------------------
The message "XSysAce: Queue is plugged" appears the most when I start the =
system:
--------------------------------------------------------------------------=
-----------------------------------------------------------
Linux version 2.6.23xlnx (meyer@tiv007) (gcc version 3.4.5) #5 Wed Jul 2 1=
2:02:19 CEST 2008
Xilinx Generic PowerPC board support package (Xilinx XUPV2P) (Virtex-II Pr=
o)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early=5Fnode=5Fmap[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order. Total pages: 65024
Kernel command line: console=3DttyUL0 root=3D/dev/xsa2 rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
PID hash table entries: 1024 (order: 10, 4096 bytes)
I-pipe 1.6-03: pipeline enabled.
Console: colour dummy device 80x25
Console: Xilinx UART Lite
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257280k available (1816k kernel code, 640k data, 96k init, 0k high=
mem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Registering device uartlite:0
Registering device xsysace:0
Fixup MAC address for xilinx=5Femac:0
Registering device xilinx=5Femac:0
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
I-pipe: Domain Xenomai registered.
Xenomai: hal/powerpc started.
Xenomai: real-time nucleus v2.4.2 (One Big Rush) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
Xenomai: starting RTAI emulator.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
uartlite.0: ttyUL0 at MMIO 0x40600003 (irq =3D 5) is a uartlite
console [ttyUL0] enabled
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
System ACE at 0x41800000 mapped to 0xD1020000, irq=3D3, 500472KB
xsa: xsa1 xsa2
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
xilinx=5Femac xilinx=5Femac.0: MAC address is now 0: a:35: 0: 2:29
XEmac: using fifo mode.
XEmac: Detected PHY at address 0, ManufID 0x0013, Rev. 0x78e2.
eth0: Dropping NETIF=5FF=5FSG since no checksum feature.
eth0: Xilinx 10/100 EMAC at 0x80400000 mapped to 0xD1040000, irq=3D4
eth0: XEmac id 1.1a, block id 32, type 1
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommende=
d
EXT3 FS on xsa2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 96k init
INIT: version 2.85 booting
Welcome to DENX Embedded Linux Environment
Press 'I' to enter interactive startup.
Building the cache [ OK ]
storage network audio done[ OK ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access meth=
od.
Setting clock : Thu Jan 1 00:00:25 UTC 1970 [ OK ]
Setting hostname localhost: [ OK ]
Checking filesystems
Checking all file systems.
[ OK ]
Mounting local filesystems: [ OK ]
Enabling swap space: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Bringing up loopback interface: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
Starting portmap: XSysAce: Queue is plugged
XSysAce: Queue is plugged
[ OK ]
Mounting NFS filesystems: [ OK ]
XSysAce: Queue is plugged
XSysAce: Queue is plugged
Mounting other filesystems: [ OK ]
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
DENX ELDK version 4.1 build 2007-01-19
Linux 2.6.23xlnx on a ppc
localhost login: root
XSysAce: Queue is plugged
Last login: Thu Jan 1 00:00:43 on console
bash: dircolors: command not found
bash-3.00#
--------------------------------------------------------------------------=
-------------------------------------
Greez & Thx
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: linux-next: kbuild tree build failure
From: Roman Zippel @ 2008-07-10 14:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20080708211930.GA16897@uranus.ravnborg.org>
Hi,
On Tue, 8 Jul 2008, Sam Ravnborg wrote:
> We use Kconfig for a mixture of user editable values and fixed
> configuration values.
> And I agree that asking the user to input a 64 bit number is not usefull.
>
> But keeping support for 64 bit values is what I would consider
> expected functionality.
Isn't that a bit of a stretch? That's a rather generic argument, do we
really have to keep everything, because someone _might_ want to use it?
I'd rather look at how useful it really is to keep that functionality and
so far we exactly one user, which doesn't strictly require it.
So far it's more a convenience feature rather than a required feature. We
don't lose any functionality, it's just shifted from kconfig to the header
file.
> > This would also ease on any portability issues
> > (kconfig is compiled with the host compiler not the target compiler).
>
> We use strtol() in a few places in symbol.c already where we do an
> implicit conversion to int. Why did this not cause us problems before?
>
> Is it because these code paths are only triggered when we deal with ranges?
> If so we could 'fix' strdup_type() to not use strto{,u}l() so it
> is 64 bit clean and we are back to old behaviour.
Ranges are the primary reason I made it consistent with this.
If we really wanted to support 64bit numbers, it would create only more
problems. First you have to make sure that on every build host (i.e also
non-Linux) strtoll() is available. Then how it should these numbers be
represented? On 32bit these may need a 'll' postfix, but the powerpc
example already shows, that there are different requirements, so they use
ASM_CONST for that. How should this postprecessing be integrated into
kconfig?
I would seriously prefer to keep things as simple as possible, unless
there is a real requirement for it, but so far there isn't any.
If we really needed something like this, I'd rather introduce a new
expression type, which works more like an unquoted string (e.g. you
could define something like (1l<<$PAGE_SHIFT)), where things like ranges
wouldn't work, but it also wouldn't have any content restrictions.
bye, Roman
^ permalink raw reply
* Re: [PATCH] MPC52xx PCI write combine timer
From: Grant Likely @ 2008-07-10 14:58 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <4875DC0C.2060609@matrix-vision.de>
On Thu, Jul 10, 2008 at 11:53:16AM +0200, Andre Schwarz wrote:
> On MPC52xx the PCI target control register (PCITCR) @ MBAR + 0xD6C is initialized with
> only bit 7 (Latrule disable) set. The 8-Bit write combine timer (Bits 24..31) should be
> also set to a reasonable value _greater zero_ (0x08 = default) since setting it to 0x00
> leads to _very poor_ performance as a PCI target since external burst won't be possible
> at all.
>
> Setting the WCT to 0x08 (cache-line size) leads to good overall perfomance.
Looks good to me. I'll test it here and pick it up if all looks good.
Cheers,
g.
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Roman Zippel @ 2008-07-10 14:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg,
linuxppc-dev
In-Reply-To: <1215651082.13950.7.camel@localhost>
Hi,
On Thu, 10 Jul 2008, Michael Ellerman wrote:
> Well yes :) But I think that's because you're thinking of
> "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> Kconfig and I do expect myself to be able to type a 64-bit address.
That doesn't really answer my question, why you need this.
> > > --- .config.orig 2008-07-08 09:30:00.000000000 +1000
> > > +++ .config 2008-07-08 09:30:43.000000000 +1000
> > > @@ -370,9 +370,8 @@
> > > CONFIG_HOTPLUG_PCI_RPA=m
> > > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > > # CONFIG_HAS_RAPIDIO is not set
> > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > -CONFIG_KERNEL_START=0xc000000002000000
> > > -CONFIG_PHYSICAL_START=0x02000000
> > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > +CONFIG_PHYSICAL_START=0x2000000
> >
> > Why is this worse? These are constants, you're not supposed to change them
> > anyway.
> > The remaining values are generated in page.h and should be the same as
> > before. If that isn't the case and this patch produces a nonworking
> > kernel, I'd like to hear about it.
>
> You're right the built kernel is fine. So it's not a bug,
Good, could someone please ack whether the powerpc changes are acceptable?
> but I think it is nicer to have the real values in the .config.
Why?
bye, Roman
^ 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