* mpc5121 Power Managment errata.
From: Kenneth Johansson @ 2009-07-21 17:16 UTC (permalink / raw)
To: Linuxppc-dev Development
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
I have a bit of a problem with arch/powerpc/platforms/512x/mpc512x_pm.c
Since this one is not included in mainline (yet) I have attached it
Now I have a number of questions and one mystery.
1: why relocate the code ?? is there a reason why the code must be
located at address 0
http://www.bitshrine.org/gpp/linux-2.6.24.6-mpc5121-99-PM-alternate-external-int-vector.patch
say that this is due to a bug in the PMC module with status bits. Could
this not be worked around by avoiding modifying the exception handler
and just taken care of by C code in ipic.c
2: does it work ???
I ask since it do self modifying code but no invalidation of the
instruction cache.
Mystery: If I fix the cache issue with the code and force store of data
with dcbst and invalidate with icbi. I get a very unreliable resume
function that often end up in machine check all over the place
This machine check also happens on unmodified version but much much more
seldom. I'm just now running some test on a system that only patch this
in once and thus always run with this workaround without constantly
modifying the exception handler . but I wont know if it makes a
difference until tomorrow.
I have inserted this code in the end of both
mpc5121_copy_pmcclr
mpc5121_reinstall_handler
Is there some reason why this would not work ??
-----------------------------------------
/*
dcbst |update memory
sync |wait for update
icbi |remove (invalidate) copy in instruction cache
isync |remove copy in own instruction buffer
*/
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* flush and invalidate from 0 to 0x600 */
li r5, 0x0
li r4, 0x600/L1_CACHE_BYTES
mtctr r4
1:
dcbst r5,r3
sync
icbi r5,r3
isync
addi r5, r5, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync
isync
[-- Attachment #2: mpc512x.S --]
[-- Type: text/x-csrc, Size: 2854 bytes --]
#include <asm/reg.h>
#include <asm/ppc_asm.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/cache.h>
#define NUM_CACHE_LINES (128*8)
/* this variable added to reserve 0x20*4 bytes.
* This value has been derived by counting the
* number of lines of the function "code_atzero".
* In case if the size of this function increases
* the number of bytes have to increased accordi-
* ngly.
*/
.data
mpc5121_data_temp:
.space 0x20*4
.text
.globl mpc5121_copy_pmcclr
mpc5121_copy_pmcclr:
/* Coming here with interrupts disabled */
/* storing the content at 0x0 location
* to mpc512_data_temp space */
lis r6, CONFIG_KERNEL_START@h
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop:
lwz r5, 0(r4)
stw r5, 0(r3)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop
/* Copy code to Location 0x0 */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, code_atzero@h
ori r3, r3, code_atzero@l
1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz 1b
/* Copy the jump to 0x0 code at 0x500*/
lwz r5, 0x500(r6)
stw r5, 0(r6)
lwz r5, 8(r6)
stw r5, 0x500(r6)
/* Flush the cache */
lis r3, CONFIG_KERNEL_START@h
ori r3, r3, CONFIG_KERNEL_START@l
/* Let us load data starting from 0x600 loc */
addi r3, r3, 0x600
li r4, NUM_CACHE_LINES
mtctr r4
1:
lwz r4, 0(r3)
addi r3, r3, L1_CACHE_BYTES /* Next line, please */
bdnz 1b
sync; isync
blr
.globl mpc5121_reinstall_handler
mpc5121_reinstall_handler:
/* Rewrite original code at 0x500 */
lis r6, CONFIG_KERNEL_START@h
lwz r5, 0(r6)
stw r5, 0x500(r6)
/* restoring content at 0x0 location */
mr r4, r6
li r3, (code_atzero_end - code_atzero)/4
mtctr r3
lis r3, mpc5121_data_temp@h
ori r3, r3, mpc5121_data_temp@l
/* loops here till the counter is zero */
loop1:
lwz r5, 0(r3)
stw r5, 0(r4)
addi r3, r3, 4
addi r4, r4, 4
bdnz loop1
blr
code_atzero:
.long 0x0 /*Space reserved for copying first word of code from 0x500 */
ba 0x504
ba 0xc /* This code is not executed. This code is copied to 0x500 */
mtspr SPRN_SPRG0, r3
mtspr SPRN_SPRG1, r4
mfspr r3, 311
addi r3, r3, 0x1000 /* Assuming that MBAR is aligned to this size */
lwz r4, 0x4(r3)
stw r4, 0x4(r3)
/* clearing GPIO evnet registers */
mfspr r3, 311
/* getting offset of GPIO */
addi r3, r3,0x1100
lwz r4, 0xC(r3)
stw r4, 0xC(r3)
mfspr r3, SPRN_SPRG0
mfspr r4, SPRN_SPRG1
ba 0x0
code_atzero_end:
b code_atzero_end /* Should never reach here*/
^ permalink raw reply
* [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-21 22:24 UTC (permalink / raw)
To: Grant Likely, netdev, Linuxppc-dev Development
Changes to the fs_enet driver (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when using the mdio-ofgpio driver.
This patch replicates similar changes made to the fs_enet mii-bitbang drivers. It has been tested on a custom mpc8280 based board using an NFS
mounted root.
Signed-off-by: Mark Ware <mware@elphinstone.net>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
The only changes in v3 are to the commit message.
drivers/net/phy/mdio-gpio.c | 77 ++++++++++++++++++++-----------------------
1 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 33984b7..22cdd45 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -30,6 +30,7 @@
#ifdef CONFIG_OF_GPIO
#include <linux/of_gpio.h>
+#include <linux/of_mdio.h>
#include <linux/of_platform.h>
#endif
@@ -81,13 +82,12 @@ static struct mdiobb_ops mdio_gpio_ops = {
.get_mdio_data = mdio_get,
};
-static int __devinit mdio_gpio_bus_init(struct device *dev,
+static struct mii_bus * __devinit mdio_gpio_bus_init(struct device *dev,
struct mdio_gpio_platform_data *pdata,
int bus_id)
{
struct mii_bus *new_bus;
struct mdio_gpio_info *bitbang;
- int ret = -ENOMEM;
int i;
bitbang = kzalloc(sizeof(*bitbang), GFP_KERNEL);
@@ -104,8 +104,6 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
new_bus->name = "GPIO Bitbanged MDIO",
- ret = -ENODEV;
-
new_bus->phy_mask = pdata->phy_mask;
new_bus->irq = pdata->irqs;
new_bus->parent = dev;
@@ -129,15 +127,8 @@ static int __devinit mdio_gpio_bus_init(struct device *dev,
dev_set_drvdata(dev, new_bus);
- ret = mdiobus_register(new_bus);
- if (ret)
- goto out_free_all;
-
- return 0;
+ return new_bus;
-out_free_all:
- dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdio);
out_free_mdc:
gpio_free(bitbang->mdc);
out_free_bus:
@@ -145,30 +136,47 @@ out_free_bus:
out_free_bitbang:
kfree(bitbang);
out:
- return ret;
+ return NULL;
}
-static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+static void __devinit mdio_gpio_bus_deinit(struct device *dev)
{
struct mii_bus *bus = dev_get_drvdata(dev);
struct mdio_gpio_info *bitbang = bus->priv;
- mdiobus_unregister(bus);
- free_mdio_bitbang(bus);
dev_set_drvdata(dev, NULL);
- gpio_free(bitbang->mdc);
gpio_free(bitbang->mdio);
+ gpio_free(bitbang->mdc);
+ free_mdio_bitbang(bus);
kfree(bitbang);
}
+static void __devexit mdio_gpio_bus_destroy(struct device *dev)
+{
+ struct mii_bus *bus = dev_get_drvdata(dev);
+
+ mdiobus_unregister(bus);
+ mdio_gpio_bus_deinit(dev);
+}
+
static int __devinit mdio_gpio_probe(struct platform_device *pdev)
{
struct mdio_gpio_platform_data *pdata = pdev->dev.platform_data;
+ struct mii_bus *new_bus;
+ int ret;
if (!pdata)
return -ENODEV;
- return mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ new_bus = mdio_gpio_bus_init(&pdev->dev, pdata, pdev->id);
+ if (!new_bus)
+ return -ENODEV;
+
+ ret = mdiobus_register(new_bus);
+ if (ret)
+ mdio_gpio_bus_deinit(&pdev->dev);
+
+ return ret;
}
static int __devexit mdio_gpio_remove(struct platform_device *pdev)
@@ -179,29 +187,12 @@ static int __devexit mdio_gpio_remove(struct platform_device *pdev)
}
#ifdef CONFIG_OF_GPIO
-static void __devinit add_phy(struct mdio_gpio_platform_data *pdata,
- struct device_node *np)
-{
- const u32 *data;
- int len, id, irq;
-
- data = of_get_property(np, "reg", &len);
- if (!data || len != 4)
- return;
-
- id = *data;
- pdata->phy_mask &= ~(1 << id);
-
- irq = of_irq_to_resource(np, 0, NULL);
- if (irq)
- pdata->irqs[id] = irq;
-}
static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct mdio_gpio_platform_data *pdata;
+ struct mii_bus *new_bus;
int ret;
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
@@ -215,14 +206,18 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
ret = of_get_gpio(ofdev->node, 1);
if (ret < 0)
- goto out_free;
+ goto out_free;
pdata->mdio = ret;
- while ((np = of_get_next_child(ofdev->node, np)))
- if (!strcmp(np->type, "ethernet-phy"))
- add_phy(pdata, np);
+ new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ if (!new_bus)
+ return -ENODEV;
- return mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
+ ret = of_mdiobus_register(new_bus, ofdev->node);
+ if (ret)
+ mdio_gpio_bus_deinit(&ofdev->dev);
+
+ return ret;
out_free:
kfree(pdata);
--
1.5.6.5
^ permalink raw reply related
* [PATCH] powerpc/mm: Fix definitions of FORCE_MAX_ZONEORDER in Kconfig
From: Benjamin Herrenschmidt @ 2009-07-22 1:25 UTC (permalink / raw)
To: linuxppc-dev
The current definitions set ranges and defaults for 32 and 64-bit
only using "PPC_STD_MMU" which means hash based MMU. This uselessly
restrict the usefulness for the upcoming 64-bit BookE port, but more
than that, it's broken on 32-bit since the only 32-bit platform
supporting multiple page sizes currently is 44x which does -not-
have PPC_STD_MMU_32 set.
This fixes it by using PPC64 and PPC32 instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2009-07-22 11:22:16.000000000 +1000
+++ linux-work/arch/powerpc/Kconfig 2009-07-22 11:22:39.000000000 +1000
@@ -492,16 +492,16 @@ endchoice
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
- range 9 64 if PPC_STD_MMU_64 && PPC_64K_PAGES
- default "9" if PPC_STD_MMU_64 && PPC_64K_PAGES
- range 13 64 if PPC_STD_MMU_64 && !PPC_64K_PAGES
- default "13" if PPC_STD_MMU_64 && !PPC_64K_PAGES
- range 9 64 if PPC_STD_MMU_32 && PPC_16K_PAGES
- default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES
- range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES
- default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES
- range 5 64 if PPC_STD_MMU_32 && PPC_256K_PAGES
- default "5" if PPC_STD_MMU_32 && PPC_256K_PAGES
+ range 9 64 if PPC64 && PPC_64K_PAGES
+ default "9" if PPC64 && PPC_64K_PAGES
+ range 13 64 if PPC64 && !PPC_64K_PAGES
+ default "13" if PPC64 && !PPC_64K_PAGES
+ range 9 64 if PPC32 && PPC_16K_PAGES
+ default "9" if PPC32 && PPC_16K_PAGES
+ range 7 64 if PPC32 && PPC_64K_PAGES
+ default "7" if PPC32 && PPC_64K_PAGES
+ range 5 64 if PPC32 && PPC_256K_PAGES
+ default "5" if PPC32 && PPC_256K_PAGES
range 11 64
default "11"
help
^ permalink raw reply
* [PATCH 5/7] [powerpc] ARRAY_SIZE changes
From: Stoyan Gaydarov @ 2009-07-22 3:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Stoyan Gaydarov, paulus, linuxppc-dev
In-Reply-To: <1248231753-8344-5-git-send-email-sgayda2@uiuc.edu>
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
---
arch/powerpc/platforms/pasemi/idle.c | 2 +-
arch/powerpc/platforms/powermac/feature.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 43911d8..75b296b 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -90,7 +90,7 @@ machine_late_initcall(pasemi, pasemi_idle_init);
static int __init idle_param(char *p)
{
int i;
- for (i = 0; i < sizeof(modes)/sizeof(struct sleep_mode); i++) {
+ for (i = 0; i < ARRAY_SIZE(modes); i++) {
if (!strcmp(modes[i].name, p)) {
current_mode = i;
break;
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..095de32 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2419,13 +2419,13 @@ static int __init probe_motherboard(void)
dt = of_find_node_by_name(NULL, "device-tree");
if (dt != NULL)
model = of_get_property(dt, "model", NULL);
- for(i=0; model && i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; model && i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (strcmp(model, pmac_mb_defs[i].model_string) == 0) {
pmac_mb = pmac_mb_defs[i];
goto found;
}
}
- for(i=0; i<(sizeof(pmac_mb_defs)/sizeof(struct pmac_mb_def)); i++) {
+ for(i=0; i<ARRAY_SIZE(pmac_mb_defs); i++) {
if (machine_is_compatible(pmac_mb_defs[i].model_string)) {
pmac_mb = pmac_mb_defs[i];
goto found;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] powerpc/cell: replace strncpy by strlcpy
From: Ken Kawakami @ 2009-07-22 4:22 UTC (permalink / raw)
To: roel.kluin; +Cc: linuxppc-dev, akpm, cbe-oss-dev, arnd
In-Reply-To: <4A6595AD.9000209@gmail.com>
Arnd-san, Roel-san,
It works fine. Thanks.
---
Regards,
Ken Kawakami
> Replace strncpy() and explicit null-termination by strlcpy()
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Arnd-san, Ken-san,
>
> Thanks for reviewing,
>
> > We prefer to take the patch which is replacing the two lines with one.
>
> Doozo.
>
> diff --git a/arch/powerpc/platforms/cell/celleb_setup.c b/arch/powerpc/platforms/cell/celleb_setup.c
> index 07c234f..e538455 100644
> --- a/arch/powerpc/platforms/cell/celleb_setup.c
> +++ b/arch/powerpc/platforms/cell/celleb_setup.c
> @@ -80,8 +80,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> - celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> return 0;
> }
>
>
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:22 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907210233l17aa3e75pcb7c20e3faa24195@mail.gmail.com>
I'm not seeing any BUG* in traps.c @ line 904.
On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
patches on top of 2.6.29.6?
- k
^ permalink raw reply
* [PATCH] powerpc: update wrapper to point to the new location of dtc
From: Lucian Adrian Grijincu @ 2009-07-22 15:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
dtc was moved in 9fffb55f66127b52c937ede5196ebfa0c0d50bce from
arch/powerpc/boot/ to scripts/dtc/
This patch updates the wrapper script to point to the new location of dtc.
Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
---
arch/powerpc/boot/wrapper | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-powerpc-update-wrapper-to-point-to-the-new-location-.patch --]
[-- Type: text/x-patch, Size: 572 bytes --]
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index e964489..c907540 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -46,6 +46,7 @@ CROSS=
# directory for object and other files used by this script
object=arch/powerpc/boot
objbin=$object
+dtc=scripts/dtc/dtc
# directory for working files
tmpdir=.
@@ -124,7 +125,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- $object/dtc -O dtb -o "$dtb" -b 0 "$dts"
+ $dtc -O dtb -o "$dtb" -b 0 "$dts"
fi
if [ -z "$kernel" ]; then
^ permalink raw reply related
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <2A0DDADE-5C3C-43F2-9487-98A8A735DC8D@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
>> architecture (ppc440)
>>
>>
>> msgctl10 1 B------------[ cut here ]------------
>> kernel BUG at arch/powerpc/kernel/traps.c:904!
>> Oops: Exception in kernel mode, sig: 5 [#9]
>>
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
> patches on top of 2.6.29.6?
>
> - k
>
>
I have LTTng patches on top of linux-2.6.29.6.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 1257 bytes --]
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-22 15:44 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907220838h49e5c273qa543e538bb37923a@mail.gmail.com>
On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some
> other patches on top of 2.6.29.6?
>
> - k
>
>
> I have LTTng patches on top of linux-2.6.29.6.
Does it modify traps.c? Can you see what the code around line 904
looks like and post that.
- k
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: David Miller @ 2009-07-22 16:20 UTC (permalink / raw)
To: grant.likely; +Cc: leoli, netdev, afleming, linuxppc-dev
In-Reply-To: <fa686aa40907181137v4a0ed1ednfed3194d1308296a@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Sat, 18 Jul 2009 12:37:34 -0600
> Awesome. Dave, can you please pick up this series?
Sure thing.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Linus Torvalds @ 2009-07-22 16:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, 20 Jul 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go in early during
> > > the merge window. We can sort out separately how to carry the patch
> > > around in -next until then since the powerpc tree will have a dependency
> > > on it.
> >
> > Can't see any problem with that.
>
> CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> far nobody objected to the patch itself)
Maybe you can put it as a separate branch in -next, and have it merged
before the stuff that depends on it, and then just sending it to me (as a
git branch or patch or whatever) in the first day of the merge window?
Linus
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: srikanth krishnakar @ 2009-07-22 16:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <578FBC09-589D-4691-82FF-985FCFE8ADC9@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Wed, Jul 22, 2009 at 9:14 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
>
> On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
>>
>> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>> I'm not seeing any BUG* in traps.c @ line 904.
>>
>>
>> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>>
>> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
>> architecture (ppc440)
>>
>>
>> msgctl10 1 B------------[ cut here ]------------
>> kernel BUG at arch/powerpc/kernel/traps.c:904!
>> Oops: Exception in kernel mode, sig: 5 [#9]
>>
>> I'm not seeing any BUG* in traps.c @ line 904. Do you have some other
>> patches on top of 2.6.29.6?
>>
>> - k
>>
>>
>> I have LTTng patches on top of linux-2.6.29.6.
>>
>
> Does it modify traps.c? Can you see what the code around line 904 looks
> like and post that.
>
> - k
>
896
897 #if defined(CONFIG_XILINX_VIRTEX_5_FXT) && defined(CONFIG_PPC_FPU)
898 if (reason & REASON_ILLEGAL) {
899 if (excep_state < 1) {
900 excep_state++;
901 return;
902 }
903 /* should never get here */
904 BUG();
905 }
906 #endif
907
908 /* Try to emulate it if we should. */
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 2104 bytes --]
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-22 16:40 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <4A66400F.3090309@elphinstone.net>
From: Mark Ware <mware@elphinstone.net>
Date: Wed, 22 Jul 2009 08:24:15 +1000
> Changes to the fs_enet driver
> (aa73832c5a80d6c52c69b18af858d88fa595dd3c) cause kernel crashes when
> using the mdio-ofgpio driver.
>
> This patch replicates similar changes made to the fs_enet mii-bitbang
> drivers. It has been tested on a custom mpc8280 based board using an
> NFS mounted root.
>
> Signed-off-by: Mark Ware <mware@elphinstone.net>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Your email client has massively corrupted this patch, I even tried
to fix it up but it's so bad that I just gave up half-way through.
Please use an attachment or whatever is necessary to get this
patch submitted cleanly and without it getting damaged. Read:
linux/Documentation/email-clients.txt
for tips.
Thanks.
^ permalink raw reply
* Re: Best hardware platform for native compiling...
From: Olof Johansson @ 2009-07-22 20:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Jander
In-Reply-To: <1248180459.31121.9.camel@pasglop>
On Tue, Jul 21, 2009 at 10:47:39PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-21 at 14:00 +0200, Gabriel Paubert wrote:
> > Well, I got one recently here in Spain. Shipping charges are fairly
> > large (it's not exactly a light and compact machine). But the current
> > dollar exchange rate helps ;-)
> >
> > Now I have not yet found the way to install Debian on it
> > (it refuses to boot Debian's CDROM), but I have not had
> > time to investigate either.
>
> It uses SLOF which should be capable of decent netbooting, so it should
> be possible to either netboot yaboot and have it load the kernel and
> initramfs, or maybe make a zImage with both included and netboot that.
Placing the debian (netinst) installer ramdisk and kernel on the /boot
partition and booting it from there should work too (after adding it to
the yaboot config).
-Olof
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Mike Mason @ 2009-07-22 23:41 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <1247790973.16836.11.camel@concordia>
Michael Ellerman wrote:
> On Thu, 2009-07-16 at 09:33 -0700, Mike Mason wrote:
>> Michael Ellerman wrote:
>>> On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
>>>> This patch increments the device_node reference counter when an EEH
>>>> error occurs and decrements the counter when the event has been
>>>> handled. This is to prevent the device_node from being released until
>>>> eeh_event_handler() has had a chance to deal with the event. We've
>>>> seen cases where the device_node is released too soon when an EEH
>>>> event occurs during a dlpar remove, causing the event handler to
>>>> attempt to access bad memory locations.
>>>>
>>>> Please review and let me know of any concerns.
>>> Taking a reference sounds sane, but ...
>>>
>>>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>>>>
>>>> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09 15:13:53.000000000 -0700
>>>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14 14:14:00.000000000 -0700
>>>> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
>>>> if (event == NULL)
>>>> return 0;
>>>>
>>>> + /* EEH holds a reference to the device_node, so if it
>>>> + * equals 1 it's no longer valid and the event should
>>>> + * be ignored */
>>>> + if (atomic_read(&event->dn->kref.refcount) == 1) {
>>>> + of_node_put(event->dn);
>>>> + return 0;
>>>> + }
>>> That's really gross :)
>> Agreed. I'll look for another way to determine if device is gone and
>> the event should be ignored. Suggestions are welcome :-)
Actually, it turns out the atomic_read() isn't necessary. I just need to take the reference to the device_node when the EEH error is detected and let EEH try to handle the error. EEH detects the fact that the device is no longer valid, aborts the recovery attempt, then gives the device_node reference back. Works as expected.
I'll resubmit the patch without the atomic_read().
>
> Benh and I had a quick chat about it, and were wondering whether what
> you really should be doing is taking a reference to the pci device
> (perhaps as well as the device node).
EEH already does that 3 lines before the of_node_get (see below).
>
> @@ -140,7 +149,7 @@ int eeh_send_failure_event (struct devic
> if (dev)
> pci_dev_get(dev);
>
> - event->dn = dn;
> + event->dn = of_node_get(dn);
> event->dev = dev;
>
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdioinfrastructure
From: Mark Ware @ 2009-07-23 0:02 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxppc-dev
On Thu 23/07/09 2:10 AM , David Miller davem@davemloft.net sent:
> Your email client has massively corrupted this patch, I even tried
> to fix it up but it's so bad that I just gave up half-way through.
>=20
> Please use an attachment or whatever is necessary to get this
> patch submitted cleanly and without it getting damaged. Read:
>=20
> linux/Documentation/email-clients.txt for tips.
>=20
> Thanks.
Sorry for the waste of time. I've obviously somehow broken my thunderbird =
config.
Patch is attached, hopefully with correct MIME type - this webmail client i=
s worse than Outlook.
(Incidently, I was able to apply the corrupted patch after the following tw=
o substitutions: s/^ / / and s/^$/ /)
Regards,
Mark
^ permalink raw reply
* Re: Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: Mark Ware @ 2009-07-23 0:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linuxppc-dev
On Thu 23/07/09 2:10 AM , David Miller davem@davemloft.net sent:
> Your email client has massively corrupted this patch, I even tried
> to fix it up but it's so bad that I just gave up half-way through.
>=20
> Please use an attachment or whatever is necessary to get this
> patch submitted cleanly and without it getting damaged. Read:
>=20
> linux/Documentation/email-clients.txt
>=20
> for tips.
>=20
> Thanks.
Dave,
The patch is actually attached this time. (I hope - did I mention my disli=
ke for this webmail interface?)
Sorry for the further noise.
Regards,
Mark
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdioinfrastructure
From: David Miller @ 2009-07-23 0:10 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <16811.1248307327@internode.on.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 23 Jul 2009 09:02:07 +0900
> Patch is attached, hopefully with correct MIME type - this webmail
> client is worse than Outlook.
Where is it attached? :-/
^ permalink raw reply
* Re: [PATCH v3] net: Rework mdio-ofgpio driver to use of_mdio infrastructure
From: David Miller @ 2009-07-23 0:11 UTC (permalink / raw)
To: mware; +Cc: netdev, linuxppc-dev
In-Reply-To: <16861.1248307810@internode.on.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 23 Jul 2009 09:40:10 +0930
>
> The patch is actually attached this time. (I hope - did I mention my dislike for this webmail interface?)
No it isn't!
And anyways you have to properly provide the full commit message
and signoffs when you resubmit patches. You can't just resubmit
the patch because all of the context is lost in patchwork.
Grrr...
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-23 0:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <alpine.LFD.2.01.0907220930320.19335@localhost.localdomain>
On Wed, 2009-07-22 at 09:31 -0700, Linus Torvalds wrote:
> > CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> > far nobody objected to the patch itself)
>
> Maybe you can put it as a separate branch in -next, and have it merged
> before the stuff that depends on it, and then just sending it to me (as a
> git branch or patch or whatever) in the first day of the merge window?
Hrm... my powerpc-next branch will contain stuff that depend on it, so
I'll probably have to pull it in though, unless I tell all my
sub-maintainers to also pull from that other branch first :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
From: Kumar Gala @ 2009-07-23 0:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, Linux Memory Management, Hugh Dickins,
linux-kernel, linuxppc-dev, Linus Torvalds
In-Reply-To: <1248310415.3367.22.camel@pasglop>
On Jul 22, 2009, at 7:53 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-07-22 at 09:31 -0700, Linus Torvalds wrote:
>>> CC'ing Linus here. How do you want to proceed with that merge ?
>>> (IE. so
>>> far nobody objected to the patch itself)
>>
>> Maybe you can put it as a separate branch in -next, and have it
>> merged
>> before the stuff that depends on it, and then just sending it to me
>> (as a
>> git branch or patch or whatever) in the first day of the merge
>> window?
>
> Hrm... my powerpc-next branch will contain stuff that depend on it, so
> I'll probably have to pull it in though, unless I tell all my
> sub-maintainers to also pull from that other branch first :-)
Can you not cherry pick it into powerpc-next to 'pull it through'?
- k
^ permalink raw reply
* Re: [LTP] msgctl10 fails on Powerpc Linux-2.6.29.6
From: Kumar Gala @ 2009-07-23 1:03 UTC (permalink / raw)
To: srikanth krishnakar; +Cc: Linuxppc-dev, Ltp-list
In-Reply-To: <6213bc560907220932u3b771af2q743ae55dda5a2198@mail.gmail.com>
On Jul 22, 2009, at 11:32 AM, srikanth krishnakar wrote:
>
>
> On Wed, Jul 22, 2009 at 9:14 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>
> On Jul 22, 2009, at 10:38 AM, srikanth krishnakar wrote:
>
>
>
> On Wed, Jul 22, 2009 at 8:52 PM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
> I'm not seeing any BUG* in traps.c @ line 904.
>
>
> On Jul 21, 2009, at 4:33 AM, srikanth krishnakar wrote:
>
> The LTP test case msgctl10.c fails on linux-2.6.29.6 for PowerPC
> architecture (ppc440)
>
>
> msgctl10 1 B------------[ cut here ]------------
> kernel BUG at arch/powerpc/kernel/traps.c:904!
> Oops: Exception in kernel mode, sig: 5 [#9]
>
> I'm not seeing any BUG* in traps.c @ line 904. Do you have some
> other patches on top of 2.6.29.6?
>
> - k
>
>
> I have LTTng patches on top of linux-2.6.29.6.
>
> Does it modify traps.c? Can you see what the code around line 904
> looks like and post that.
>
> - k
> 896
> 897 #if defined(CONFIG_XILINX_VIRTEX_5_FXT) &&
> defined(CONFIG_PPC_FPU)
> 898 if (reason & REASON_ILLEGAL) {
> 899 if (excep_state < 1) {
> 900 excep_state++;
> 901 return;
> 902 }
> 903 /* should never get here */
> 904 BUG();
> 905 }
> 906 #endif
> 907
> 908 /* Try to emulate it if we should. */
>
Are you sure this is coming from the LTTng patches? Which actual
patch makes this change?
- k
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Michael Ellerman @ 2009-07-23 1:21 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <4A67A3A2.4050508@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
On Wed, 2009-07-22 at 16:41 -0700, Mike Mason wrote:
> Michael Ellerman wrote:
> > On Thu, 2009-07-16 at 09:33 -0700, Mike Mason wrote:
> >> Michael Ellerman wrote:
> >>> On Wed, 2009-07-15 at 14:43 -0700, Mike Mason wrote:
> >>>> This patch increments the device_node reference counter when an EEH
> >>>> error occurs and decrements the counter when the event has been
> >>>> handled. This is to prevent the device_node from being released until
> >>>> eeh_event_handler() has had a chance to deal with the event. We've
> >>>> seen cases where the device_node is released too soon when an EEH
> >>>> event occurs during a dlpar remove, causing the event handler to
> >>>> attempt to access bad memory locations.
> >>>>
> >>>> Please review and let me know of any concerns.
> >>> Taking a reference sounds sane, but ...
> >>>
> >>>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
> >>>>
> >>>> --- a/arch/powerpc/platforms/pseries/eeh_event.c 2008-10-09 15:13:53.000000000 -0700
> >>>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c 2009-07-14 14:14:00.000000000 -0700
> >>>> @@ -75,6 +75,14 @@ static int eeh_event_handler(void * dumm
> >>>> if (event == NULL)
> >>>> return 0;
> >>>>
> >>>> + /* EEH holds a reference to the device_node, so if it
> >>>> + * equals 1 it's no longer valid and the event should
> >>>> + * be ignored */
> >>>> + if (atomic_read(&event->dn->kref.refcount) == 1) {
> >>>> + of_node_put(event->dn);
> >>>> + return 0;
> >>>> + }
> >>> That's really gross :)
> >> Agreed. I'll look for another way to determine if device is gone and
> >> the event should be ignored. Suggestions are welcome :-)
>
> Actually, it turns out the atomic_read() isn't necessary. I just need
> to take the reference to the device_node when the EEH error is
> detected and let EEH try to handle the error. EEH detects the fact
> that the device is no longer valid, aborts the recovery attempt, then
> gives the device_node reference back. Works as expected.
How does it detect that the device is no longer valid?
> I'll resubmit the patch without the atomic_read().
>
> >
> > Benh and I had a quick chat about it, and were wondering whether what
> > you really should be doing is taking a reference to the pci device
> > (perhaps as well as the device node).
>
> EEH already does that 3 lines before the of_node_get (see below).
Ah right, while you're touching the code, mind changing it to the
simpler and more obvious:
> event->dev = pci_dev_get(dev);
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/20] powerpc/mm: Fix misplaced #endif in pgtable-ppc64-64k.h
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
A misplaced #endif causes more definitions than intended to be
protected by #ifndef __ASSEMBLY__. This breaks upcoming 64-bit
BookE support patch when using 64k pages.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pgtable-ppc64-64k.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64-64k.h 2009-07-22 11:45:34.000000000 +1000
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64-64k.h 2009-07-22 11:45:47.000000000 +1000
@@ -10,10 +10,10 @@
#define PGD_INDEX_SIZE 4
#ifndef __ASSEMBLY__
-
#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
+#endif /* __ASSEMBLY__ */
#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
@@ -32,8 +32,6 @@
#define PGDIR_SIZE (1UL << PGDIR_SHIFT)
#define PGDIR_MASK (~(PGDIR_SIZE-1))
-#endif /* __ASSEMBLY__ */
-
/* Bits to mask out from a PMD to get to the PTE page */
#define PMD_MASKED_BITS 0x1ff
/* Bits to mask out from a PGD/PUD to get to the PMD page */
^ permalink raw reply
* [PATCH 2/20] powerpc/of: Remove useless register save/restore when calling OF back
From: Benjamin Herrenschmidt @ 2009-07-23 5:59 UTC (permalink / raw)
To: linuxppc-dev
enter_prom() used to save and restore registers such as CTR, XER etc..
which are volatile, or SRR0,1... which we don't care about. This
removes a bunch of useless code and while at it turns an mtmsrd into
an MTMSRD macro which will be useful to Book3E.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/entry_64.S | 38 ++++++--------------------------------
1 file changed, 6 insertions(+), 32 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/entry_64.S 2009-07-22 15:20:26.000000000 +1000
+++ linux-work/arch/powerpc/kernel/entry_64.S 2009-07-22 15:22:44.000000000 +1000
@@ -823,30 +823,17 @@ _GLOBAL(enter_prom)
* of all registers that it saves. We therefore save those registers
* PROM might touch to the stack. (r0, r3-r13 are caller saved)
*/
- SAVE_8GPRS(2, r1)
+ SAVE_GPR(2, r1)
SAVE_GPR(13, r1)
SAVE_8GPRS(14, r1)
SAVE_10GPRS(22, r1)
- mfcr r4
- std r4,_CCR(r1)
- mfctr r5
- std r5,_CTR(r1)
- mfspr r6,SPRN_XER
- std r6,_XER(r1)
- mfdar r7
- std r7,_DAR(r1)
- mfdsisr r8
- std r8,_DSISR(r1)
- mfsrr0 r9
- std r9,_SRR0(r1)
- mfsrr1 r10
- std r10,_SRR1(r1)
+ mfcr r10
mfmsr r11
+ std r10,_CCR(r1)
std r11,_MSR(r1)
/* Get the PROM entrypoint */
- ld r0,GPR4(r1)
- mtlr r0
+ mtlr r4
/* Switch MSR to 32 bits mode
*/
@@ -860,8 +847,7 @@ _GLOBAL(enter_prom)
mtmsrd r11
isync
- /* Restore arguments & enter PROM here... */
- ld r3,GPR3(r1)
+ /* Enter PROM here... */
blrl
/* Just make sure that r1 top 32 bits didn't get
@@ -871,7 +857,7 @@ _GLOBAL(enter_prom)
/* Restore the MSR (back to 64 bits) */
ld r0,_MSR(r1)
- mtmsrd r0
+ MTMSRD(r0)
isync
/* Restore other registers */
@@ -881,18 +867,6 @@ _GLOBAL(enter_prom)
REST_10GPRS(22, r1)
ld r4,_CCR(r1)
mtcr r4
- ld r5,_CTR(r1)
- mtctr r5
- ld r6,_XER(r1)
- mtspr SPRN_XER,r6
- ld r7,_DAR(r1)
- mtdar r7
- ld r8,_DSISR(r1)
- mtdsisr r8
- ld r9,_SRR0(r1)
- mtsrr0 r9
- ld r10,_SRR1(r1)
- mtsrr1 r10
addi r1,r1,PROM_FRAME_SIZE
ld r0,16(r1)
^ 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