* [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-15 15:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Wolfgang Denk
In-Reply-To: <1247578966-9847-1-git-send-email-wd@denx.de>
This patch adds error checking and prevents clobbering unrelated bits
(reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
register on MPC52xx systems.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: <netdev@vger.kernel.org>
---
drivers/net/fec_mpc52xx.c | 2 +-
drivers/net/fec_mpc52xx_phy.c | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..b69d440 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev)
/* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
- out_be32(&fec->mii_speed, priv->mdio_speed);
+ clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
}
/**
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..f733d43 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -105,8 +105,10 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
dev_set_drvdata(dev, bus);
/* set MII speed */
- out_be32(&priv->regs->mii_speed,
- ((mpc5xxx_get_bus_frequency(of->node) >> 20) / 5) << 1);
+ i = mpc5xxx_get_mii_speed(of);
+ if (i<0)
+ goto out_unmap;
+ clrsetbits_be32(&priv->regs->mii_speed, 0x7E, i);
err = of_mdiobus_register(bus, np);
if (err)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 1/2 v3] fs_enet/mii-fec.c: fix MII speed calculation
From: Grant Likely @ 2009-07-15 17:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247671133-12148-1-git-send-email-wd@denx.de>
On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> The MII speed calculation was based on the CPU clock (ppc_proc_freq),
> but for MPC512x we must use the bus clock instead.
>
> This patch makes it use the correct clock and makes sure we don't
> clobber reserved bits in the MII_SPEED register.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
> ---
> Please ignore patch v2, it's crap.
> Hope this is a bit better.
>
> =A0arch/powerpc/include/asm/mpc5xxx.h =A0 | =A0 10 +++++++++
> =A0arch/powerpc/sysdev/mpc5xxx_clocks.c | =A0 37 ++++++++++++++++++++++++=
++++++++++
Drop the common code bit. The 5200 and 5121 are different devices and
it is a tiny bit of code. I don't think there is any benefit to
having it as a common function. Just roll the get_mii_speed function
in the mii-fec driver itself.
Also, this patch can be quite a bit simpler if you use the .data
pointer in the drivers match table to specify the function used to
return the bus clock speed. Something like this:
static struct of_device_id fs_enet_mdio_fec_match[] =3D {
{
.compatible =3D "fsl,pq1-fec-mdio",
},
#if defined(CONFIG_PPC_MPC512x)
{
.compatible =3D "fsl,mpc5121-fec-mdio",
.data =3D mpc5xxx_get_bus_frequency,
},
#endif
{},
};
and
int *get_bus_freq(of_node *) =3D data;
if (get_bus_freq)
bus_freq =3D get_bus_freq(np);
else
bus_freq =3D ppc_proc_freq / 2;
... then do the regular calculation here and add in the additional
robustification you did in this patch.
Heck, you could even eliminate the if/else above if the normal case
you have a get_bus_speed function for the original ppc_proc_freq case,
but I'm not sure if it is worth it.
> =A0drivers/net/fs_enet/mii-fec.c =A0 =A0 =A0 =A0| =A0 13 +++++++++--
> =A03 files changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc5xxx.h b/arch/powerpc/include/as=
m/mpc5xxx.h
> index 5ce9c5f..86ab29f 100644
> --- a/arch/powerpc/include/asm/mpc5xxx.h
> +++ b/arch/powerpc/include/asm/mpc5xxx.h
> @@ -15,8 +15,18 @@
>
> =A0#ifndef __ASM_POWERPC_MPC5xxx_H__
> =A0#define __ASM_POWERPC_MPC5xxx_H__
> +#include <linux/of_platform.h>
>
> =A0extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *nod=
e);
>
> +#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
> +extern int mpc5xxx_get_mii_speed(struct of_device *ofdev);
> +#else
> +static inline int mpc5xxx_get_mii_speed(struct of_device *ofdev)
> +{
> + =A0 =A0 =A0 return -1;
> +}
> +#endif
> +
> =A0#endif /* __ASM_POWERPC_MPC5xxx_H__ */
>
> diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c b/arch/powerpc/sysdev/m=
pc5xxx_clocks.c
> index 34e12f9..e26d12b 100644
> --- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
> +++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
> @@ -31,3 +31,40 @@ mpc5xxx_get_bus_frequency(struct device_node *node)
> =A0 =A0 =A0 =A0return p_bus_freq ? *p_bus_freq : 0;
> =A0}
> =A0EXPORT_SYMBOL(mpc5xxx_get_bus_frequency);
> +
> +/**
> + * =A0 =A0 mpc5xxx_get_mii_speed - Get the MII_SPEED value
> + * =A0 =A0 @node: =A0device node
> + *
> + * =A0 =A0 Returns the MII_SPEED value for MPC512x and MPC52xx systems.
> + * =A0 =A0 The value gets computed such that the resulting MDC frequency
> + * =A0 =A0 is 2.5 MHz or lower.
> + */
> +
> +int
> +mpc5xxx_get_mii_speed(struct of_device *ofdev)
> +{
> + =A0 =A0 =A0 unsigned int clock, speed;
> +
> + =A0 =A0 =A0 clock =3D mpc5xxx_get_bus_frequency(ofdev->node);
> +
> + =A0 =A0 =A0 if (!clock) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&ofdev->dev, "could not determine I=
PS/IPB clock\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* scale for a MII clock <=3D 2.5 MHz */
> + =A0 =A0 =A0 speed =3D (clock + 2499999) / 2500000;
> +
> + =A0 =A0 =A0 /* only 6 bits available for MII speed */
> + =A0 =A0 =A0 if (speed > 0x3F) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 speed =3D 0x3F;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&ofdev->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "MII clock (%d MHz) exceeds=
max (2.5 MHz)\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock / speed);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* Field is in bits 25:30 of MII_SPEED register */
> + =A0 =A0 =A0 return speed << 1;
> +}
> +EXPORT_SYMBOL(mpc5xxx_get_mii_speed);
> diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.=
c
> index 75a0999..a28d39f 100644
> --- a/drivers/net/fs_enet/mii-fec.c
> +++ b/drivers/net/fs_enet/mii-fec.c
> @@ -36,6 +36,7 @@
> =A0#include <asm/pgtable.h>
> =A0#include <asm/irq.h>
> =A0#include <asm/uaccess.h>
> +#include <asm/mpc5xxx.h>
>
> =A0#include "fs_enet.h"
> =A0#include "fec.h"
> @@ -103,7 +104,6 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
> =A0static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 const struct of_device_id *match)
> =A0{
> - =A0 =A0 =A0 struct device_node *np =3D NULL;
> =A0 =A0 =A0 =A0struct resource res;
> =A0 =A0 =A0 =A0struct mii_bus *new_bus;
> =A0 =A0 =A0 =A0struct fec_info *fec;
> @@ -133,13 +133,20 @@ static int __devinit fs_enet_mdio_probe(struct of_d=
evice *ofdev,
> =A0 =A0 =A0 =A0if (!fec->fecp)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_fec;
>
> - =A0 =A0 =A0 fec->mii_speed =3D ((ppc_proc_freq + 4999999) / 5000000) <<=
1;
> + =A0 =A0 =A0 if (of_device_is_compatible(ofdev->node, "fsl,mpc5121-fec-m=
dio")) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 i =3D mpc5xxx_get_mii_speed(ofdev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (i < 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unmap_regs;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fec->mii_speed =3D i;
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fec->mii_speed =3D ((ppc_proc_freq + 499999=
9) / 5000000) << 1;
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
> =A0 =A0 =A0 =A0setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0FEC_ECNTRL_ETHER_EN);
> =A0 =A0 =A0 =A0out_be32(&fec->fecp->fec_ievent, FEC_ENET_MII);
> - =A0 =A0 =A0 out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
> + =A0 =A0 =A0 clrsetbits_be32(&fec->fecp->fec_mii_speed, 0x7E, fec->mii_s=
peed);
>
> =A0 =A0 =A0 =A0new_bus->phy_mask =3D ~0;
> =A0 =A0 =A0 =A0new_bus->irq =3D kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_K=
ERNEL);
> --
> 1.6.0.6
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-15 17:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <1247671133-12148-2-git-send-email-wd@denx.de>
On Wed, Jul 15, 2009 at 9:18 AM, Wolfgang Denk<wd@denx.de> wrote:
> This patch adds error checking and prevents clobbering unrelated bits
> (reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
> register on MPC52xx systems.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: <netdev@vger.kernel.org>
As I mentioned in the other patch, I don't want the 5121 and 5200 FEC
devices using common code for this. It is a tiny block of code and
they are different devices. Just open code the needed calculation
into this driver.
g.
> ---
> =A0drivers/net/fec_mpc52xx.c =A0 =A0 | =A0 =A02 +-
> =A0drivers/net/fec_mpc52xx_phy.c | =A0 =A06 ++++--
> =A02 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index cc78633..b69d440 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *de=
v)
> =A0 =A0 =A0 =A0/* set phy speed.
> =A0 =A0 =A0 =A0 * this can't be done in phy driver, since it needs to be =
called
> =A0 =A0 =A0 =A0 * before fec stuff (even on resume) */
> - =A0 =A0 =A0 out_be32(&fec->mii_speed, priv->mdio_speed);
> + =A0 =A0 =A0 clrsetbits_be32(&fec->mii_speed, 0x7E, priv->mdio_speed);
> =A0}
>
> =A0/**
> diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.=
c
> index 31e6d62..f733d43 100644
> --- a/drivers/net/fec_mpc52xx_phy.c
> +++ b/drivers/net/fec_mpc52xx_phy.c
> @@ -105,8 +105,10 @@ static int mpc52xx_fec_mdio_probe(struct of_device *=
of,
> =A0 =A0 =A0 =A0dev_set_drvdata(dev, bus);
>
> =A0 =A0 =A0 =A0/* set MII speed */
> - =A0 =A0 =A0 out_be32(&priv->regs->mii_speed,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((mpc5xxx_get_bus_frequency(of->node) >> 20=
) / 5) << 1);
> + =A0 =A0 =A0 i =3D mpc5xxx_get_mii_speed(of);
> + =A0 =A0 =A0 if (i<0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unmap;
> + =A0 =A0 =A0 clrsetbits_be32(&priv->regs->mii_speed, 0x7E, i);
>
> =A0 =A0 =A0 =A0err =3D of_mdiobus_register(bus, np);
> =A0 =A0 =A0 =A0if (err)
> --
> 1.6.0.6
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Support for PCI Express reset type in EEH
From: Mike Mason @ 2009-07-15 18:32 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, Paul Mackerras, benh, linasvepstas; +Cc: Richard Lary
In-Reply-To: <4A5CCFDF.7000901@us.ibm.com>
This patch was simultaneously submitted to Red Hat for review. As a result of that review, I'm withdrawing this patch and will submit a new version shortly.
Mike
Mike Mason wrote:
> By default, EEH does what's known as a "hot reset" during error recovery
> of a PCI Express device. We've found a case where the device needs a
> "fundamental reset" to recover properly. The current PCI error recovery
> and EEH frameworks do not support this distinction.
>
> The attached patch (courtesy of Richard Lary) implements a reset type
> callback that can be used to determine what type of reset a device
> requires. It is backwards compatible with all other drivers that
> implement PCI error recovery callbacks. Only drivers that require a
> fundamental reset need to be changed. So far we're only aware of one
> driver that has the requirement (qla2xxx). The patch touches mostly EEH
> and pseries code, but does require a couple of minor additions to the
> overall PCI error recovery framework.
>
> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>
> --- a/arch/powerpc/include/asm/ppc-pci.h 2009-06-09
> 20:05:27.000000000 -0700
> +++ b/arch/powerpc/include/asm/ppc-pci.h 2009-07-13
> 16:12:31.000000000 -0700
> @@ -90,7 +90,9 @@ int rtas_pci_enable(struct pci_dn *pdn,
> *
> * Returns a non-zero value if the reset failed.
> */
> -int rtas_set_slot_reset (struct pci_dn *);
> +#define HOT_RESET 1
> +#define FUNDAMENTAL_RESET 3
> +int rtas_set_slot_reset (struct pci_dn *, int reset_type);
> int eeh_wait_for_slot_status(struct pci_dn *pdn, int max_wait_msecs);
>
> /** --- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09
> 20:05:27.000000000 -0700
> +++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-13
> 16:27:27.000000000 -0700
> @@ -666,7 +666,7 @@ rtas_pci_enable(struct pci_dn *pdn, int
> /**
> * rtas_pci_slot_reset - raises/lowers the pci #RST line
> * @pdn pci device node
> - * @state: 1/0 to raise/lower the #RST
> + * @state: 1/3/0 to raise hot-reset/fundamental-reset/lower the #RST
> *
> * Clear the EEH-frozen condition on a slot. This routine
> * asserts the PCI #RST line if the 'state' argument is '1',
> @@ -742,9 +742,9 @@ int pcibios_set_pcie_reset_state(struct
> * Return 0 if success, else a non-zero value.
> */
>
> -static void __rtas_set_slot_reset(struct pci_dn *pdn)
> +static void __rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
> {
> - rtas_pci_slot_reset (pdn, 1);
> + rtas_pci_slot_reset (pdn, reset_type);
>
> /* The PCI bus requires that the reset be held high for at least
> * a 100 milliseconds. We wait a bit longer 'just in case'. */
> @@ -766,13 +766,13 @@ static void __rtas_set_slot_reset(struct
> msleep (PCI_BUS_SETTLE_TIME_MSEC);
> }
>
> -int rtas_set_slot_reset(struct pci_dn *pdn)
> +int rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
> {
> int i, rc;
>
> /* Take three shots at resetting the bus */
> for (i=0; i<3; i++) {
> - __rtas_set_slot_reset(pdn);
> + __rtas_set_slot_reset(pdn, reset_type);
>
> rc = eeh_wait_for_slot_status(pdn, PCI_BUS_RESET_WAIT_MSEC);
> if (rc == 0)
> --- a/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
> 14:25:24.000000000 -0700
> +++ b/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
> 16:39:16.000000000 -0700
> @@ -115,6 +115,34 @@ static void eeh_enable_irq(struct pci_de
>
> /* ------------------------------------------------------- */
> /**
> + * eeh_query_reset_type - query each device driver for reset type
> + *
> + * Query each device driver for special reset type if required
> + * merge the device driver responses. Cumulative response
> + * passed back in "userdata".
> + */
> +
> +static int eeh_query_reset_type(struct pci_dev *dev, void *userdata)
> +{
> + enum pci_ers_result rc, *res = userdata;
> + struct pci_driver *driver = dev->driver;
> +
> + if (!driver)
> + return 0;
> +
> + if (!driver->err_handler ||
> + !driver->err_handler->reset_type)
> + return 0;
> +
> + rc = driver->err_handler->reset_type (dev);
> +
> + /* A driver that needs a special reset trumps all others */
> + if (rc == PCI_ERS_RESULT_FUNDAMENTAL_RESET ) *res = rc;
> +
> + return 0;
> +}
> +
> +/**
> * eeh_report_error - report pci error to each device driver
> * * Report an EEH error to each device driver, collect up and @@ -282,9
> +310,12 @@ static int eeh_report_failure(struct pci
> * @pe_dn: pointer to a "Partionable Endpoint" device node.
> * This is the top-level structure on which pci
> * bus resets can be performed.
> + *
> + * reset_type: some devices may require type other than default hot reset.
> */
>
> -static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus)
> +static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus,
> + int reset_type)
> {
> struct device_node *dn;
> int cnt, rc;
> @@ -298,7 +329,7 @@ static int eeh_reset_device (struct pci_
> /* Reset the pci controller. (Asserts RST#; resets config space).
> * Reconfigure bridges and devices. Don't try to bring the system
> * up if the reset failed for some reason. */
> - rc = rtas_set_slot_reset(pe_dn);
> + rc = rtas_set_slot_reset(pe_dn, reset_type);
> if (rc)
> return rc;
>
> @@ -343,6 +374,7 @@ struct pci_dn * handle_eeh_events (struc
> struct pci_dn *frozen_pdn;
> struct pci_bus *frozen_bus;
> int rc = 0;
> + int reset_type = HOT_RESET;
> enum pci_ers_result result = PCI_ERS_RESULT_NONE;
> const char *location, *pci_str, *drv_str;
>
> @@ -400,10 +432,16 @@ struct pci_dn * handle_eeh_events (struc
>
> /* Walk the various device drivers attached to this slot through
> * a reset sequence, giving each an opportunity to do what it needs
> - * to accomplish the reset. Each child gets a report of the
> - * status ... if any child can't handle the reset, then the entire
> - * slot is dlpar removed and added.
> + * to accomplish the reset. Query device driver for special reset
> + * requiements. Report eeh error to each child with cumulative
> + * result status... if any child can't handle the reset,
> + * then the entire slot is dlpar removed and added.
> */
> + pci_walk_bus(frozen_bus, eeh_query_reset_type, &result);
> + if ( result == PCI_ERS_RESULT_FUNDAMENTAL_RESET )
> + reset_type = FUNDAMENTAL_RESET;
> +
> + result = PCI_ERS_RESULT_NONE;
> pci_walk_bus(frozen_bus, eeh_report_error, &result);
>
> /* Get the current PCI slot state. This can take a long time,
> @@ -425,7 +463,8 @@ struct pci_dn * handle_eeh_events (struc
> * go down willingly, without panicing the system.
> */
> if (result == PCI_ERS_RESULT_NONE) {
> - rc = eeh_reset_device(frozen_pdn, frozen_bus);
> + rc = eeh_reset_device(frozen_pdn, frozen_bus, reset_type);
> +
> if (rc) {
> printk(KERN_WARNING "EEH: Unable to reset, rc=%d\n", rc);
> goto hard_fail;
> @@ -466,7 +505,7 @@ struct pci_dn * handle_eeh_events (struc
>
> /* If any device called out for a reset, then reset the slot */
> if (result == PCI_ERS_RESULT_NEED_RESET) {
> - rc = eeh_reset_device(frozen_pdn, NULL);
> + rc = eeh_reset_device(frozen_pdn, NULL, reset_type);
> if (rc) {
> printk(KERN_WARNING "EEH: Cannot reset, rc=%d\n", rc);
> goto hard_fail;
> --- a/include/linux/pci.h 2009-07-13 14:25:37.000000000 -0700
> +++ b/include/linux/pci.h 2009-07-13 16:12:31.000000000 -0700
> @@ -446,6 +446,9 @@ enum pci_ers_result {
>
> /* Device driver is fully recovered and operational */
> PCI_ERS_RESULT_RECOVERED = (__force pci_ers_result_t) 5,
> +
> + /* Device driver requires fundamental reset to recover */
> + PCI_ERS_RESULT_FUNDAMENTAL_RESET = (__force pci_ers_result_t) 6,
> };
>
> /* PCI bus error event callbacks */
> @@ -465,6 +468,9 @@ struct pci_error_handlers {
>
> /* Device driver may resume normal operations */
> void (*resume)(struct pci_dev *dev);
> +
> + /* PCI slot requires special reset type for recovery */
> + pci_ers_result_t (*reset_type)(struct pci_dev *dev);
> };
>
> /* ---------------------------------------------------------------- */
> --- a/arch/powerpc/include/asm/ppc-pci.h 2009-06-09
> 20:05:27.000000000 -0700
> +++ b/arch/powerpc/include/asm/ppc-pci.h 2009-07-13
> 16:12:31.000000000 -0700
> @@ -90,7 +90,9 @@ int rtas_pci_enable(struct pci_dn *pdn,
> *
> * Returns a non-zero value if the reset failed.
> */
> -int rtas_set_slot_reset (struct pci_dn *);
> +#define HOT_RESET 1
> +#define FUNDAMENTAL_RESET 3
> +int rtas_set_slot_reset (struct pci_dn *, int reset_type);
> int eeh_wait_for_slot_status(struct pci_dn *pdn, int max_wait_msecs);
>
> /** --- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09
> 20:05:27.000000000 -0700
> +++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-13
> 16:27:27.000000000 -0700
> @@ -666,7 +666,7 @@ rtas_pci_enable(struct pci_dn *pdn, int
> /**
> * rtas_pci_slot_reset - raises/lowers the pci #RST line
> * @pdn pci device node
> - * @state: 1/0 to raise/lower the #RST
> + * @state: 1/3/0 to raise hot-reset/fundamental-reset/lower the #RST
> *
> * Clear the EEH-frozen condition on a slot. This routine
> * asserts the PCI #RST line if the 'state' argument is '1',
> @@ -742,9 +742,9 @@ int pcibios_set_pcie_reset_state(struct
> * Return 0 if success, else a non-zero value.
> */
>
> -static void __rtas_set_slot_reset(struct pci_dn *pdn)
> +static void __rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
> {
> - rtas_pci_slot_reset (pdn, 1);
> + rtas_pci_slot_reset (pdn, reset_type);
>
> /* The PCI bus requires that the reset be held high for at least
> * a 100 milliseconds. We wait a bit longer 'just in case'. */
> @@ -766,13 +766,13 @@ static void __rtas_set_slot_reset(struct
> msleep (PCI_BUS_SETTLE_TIME_MSEC);
> }
>
> -int rtas_set_slot_reset(struct pci_dn *pdn)
> +int rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
> {
> int i, rc;
>
> /* Take three shots at resetting the bus */
> for (i=0; i<3; i++) {
> - __rtas_set_slot_reset(pdn);
> + __rtas_set_slot_reset(pdn, reset_type);
>
> rc = eeh_wait_for_slot_status(pdn, PCI_BUS_RESET_WAIT_MSEC);
> if (rc == 0)
> --- a/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
> 14:25:24.000000000 -0700
> +++ b/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
> 16:39:16.000000000 -0700
> @@ -115,6 +115,34 @@ static void eeh_enable_irq(struct pci_de
>
> /* ------------------------------------------------------- */
> /**
> + * eeh_query_reset_type - query each device driver for reset type
> + *
> + * Query each device driver for special reset type if required
> + * merge the device driver responses. Cumulative response
> + * passed back in "userdata".
> + */
> +
> +static int eeh_query_reset_type(struct pci_dev *dev, void *userdata)
> +{
> + enum pci_ers_result rc, *res = userdata;
> + struct pci_driver *driver = dev->driver;
> +
> + if (!driver)
> + return 0;
> +
> + if (!driver->err_handler ||
> + !driver->err_handler->reset_type)
> + return 0;
> +
> + rc = driver->err_handler->reset_type (dev);
> +
> + /* A driver that needs a special reset trumps all others */
> + if (rc == PCI_ERS_RESULT_FUNDAMENTAL_RESET ) *res = rc;
> +
> + return 0;
> +}
> +
> +/**
> * eeh_report_error - report pci error to each device driver
> * * Report an EEH error to each device driver, collect up and @@ -282,9
> +310,12 @@ static int eeh_report_failure(struct pci
> * @pe_dn: pointer to a "Partionable Endpoint" device node.
> * This is the top-level structure on which pci
> * bus resets can be performed.
> + *
> + * reset_type: some devices may require type other than default hot reset.
> */
>
> -static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus)
> +static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus,
> + int reset_type)
> {
> struct device_node *dn;
> int cnt, rc;
> @@ -298,7 +329,7 @@ static int eeh_reset_device (struct pci_
> /* Reset the pci controller. (Asserts RST#; resets config space).
> * Reconfigure bridges and devices. Don't try to bring the system
> * up if the reset failed for some reason. */
> - rc = rtas_set_slot_reset(pe_dn);
> + rc = rtas_set_slot_reset(pe_dn, reset_type);
> if (rc)
> return rc;
>
> @@ -343,6 +374,7 @@ struct pci_dn * handle_eeh_events (struc
> struct pci_dn *frozen_pdn;
> struct pci_bus *frozen_bus;
> int rc = 0;
> + int reset_type = HOT_RESET;
> enum pci_ers_result result = PCI_ERS_RESULT_NONE;
> const char *location, *pci_str, *drv_str;
>
> @@ -400,10 +432,16 @@ struct pci_dn * handle_eeh_events (struc
>
> /* Walk the various device drivers attached to this slot through
> * a reset sequence, giving each an opportunity to do what it needs
> - * to accomplish the reset. Each child gets a report of the
> - * status ... if any child can't handle the reset, then the entire
> - * slot is dlpar removed and added.
> + * to accomplish the reset. Query device driver for special reset
> + * requiements. Report eeh error to each child with cumulative
> + * result status... if any child can't handle the reset,
> + * then the entire slot is dlpar removed and added.
> */
> + pci_walk_bus(frozen_bus, eeh_query_reset_type, &result);
> + if ( result == PCI_ERS_RESULT_FUNDAMENTAL_RESET )
> + reset_type = FUNDAMENTAL_RESET;
> +
> + result = PCI_ERS_RESULT_NONE;
> pci_walk_bus(frozen_bus, eeh_report_error, &result);
>
> /* Get the current PCI slot state. This can take a long time,
> @@ -425,7 +463,8 @@ struct pci_dn * handle_eeh_events (struc
> * go down willingly, without panicing the system.
> */
> if (result == PCI_ERS_RESULT_NONE) {
> - rc = eeh_reset_device(frozen_pdn, frozen_bus);
> + rc = eeh_reset_device(frozen_pdn, frozen_bus, reset_type);
> +
> if (rc) {
> printk(KERN_WARNING "EEH: Unable to reset, rc=%d\n", rc);
> goto hard_fail;
> @@ -466,7 +505,7 @@ struct pci_dn * handle_eeh_events (struc
>
> /* If any device called out for a reset, then reset the slot */
> if (result == PCI_ERS_RESULT_NEED_RESET) {
> - rc = eeh_reset_device(frozen_pdn, NULL);
> + rc = eeh_reset_device(frozen_pdn, NULL, reset_type);
> if (rc) {
> printk(KERN_WARNING "EEH: Cannot reset, rc=%d\n", rc);
> goto hard_fail;
> --- a/include/linux/pci.h 2009-07-13 14:25:37.000000000 -0700
> +++ b/include/linux/pci.h 2009-07-13 16:12:31.000000000 -0700
> @@ -446,6 +446,9 @@ enum pci_ers_result {
>
> /* Device driver is fully recovered and operational */
> PCI_ERS_RESULT_RECOVERED = (__force pci_ers_result_t) 5,
> +
> + /* Device driver requires fundamental reset to recover */
> + PCI_ERS_RESULT_FUNDAMENTAL_RESET = (__force pci_ers_result_t) 6,
> };
>
> /* PCI bus error event callbacks */
> @@ -465,6 +468,9 @@ struct pci_error_handlers {
>
> /* Device driver may resume normal operations */
> void (*resume)(struct pci_dev *dev);
> +
> + /* PCI slot requires special reset type for recovery */
> + pci_ers_result_t (*reset_type)(struct pci_dev *dev);
> };
>
> /* ---------------------------------------------------------------- */
>
>
^ permalink raw reply
* [PATCH] Support for PCI Express reset type in EEH
From: Mike Mason @ 2009-07-15 18:45 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, Paul Mackerras, benh, linasvepstas; +Cc: Richard Lary
In-Reply-To: <4A5CCFDF.7000901@us.ibm.com>
By default, EEH does what's known as a "hot reset" during error recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during error recovery. This bit can be checked by EEH to determine which reset type is required.
This patch supersedes the previously submitted patch that implemented a reset type callback.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
diff -uNrp a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
--- a/arch/powerpc/kernel/pci_64.c 2009-07-13 14:25:24.000000000 -0700
+++ b/arch/powerpc/kernel/pci_64.c 2009-07-15 10:26:26.000000000 -0700
@@ -143,6 +143,7 @@ struct pci_dev *of_create_pci_dev(struct
dev->dev.bus = &pci_bus_type;
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
+ dev->fndmntl_rst_rqd = 0; /* pcie fundamental reset required */
dev->vendor = get_int_prop(node, "vendor-id", 0xffff);
dev->device = get_int_prop(node, "device-id", 0xffff);
diff -uNrp a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.000000000 -0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-15 10:29:04.000000000 -0700
@@ -744,7 +744,15 @@ int pcibios_set_pcie_reset_state(struct
static void __rtas_set_slot_reset(struct pci_dn *pdn)
{
- rtas_pci_slot_reset (pdn, 1);
+ struct pci_dev *dev = pdn->pcidev;
+
+ /* Determine type of EEH reset required by device,
+ * default hot reset or fundamental reset
+ */
+ if (dev->fndmntl_rst_rqd)
+ rtas_pci_slot_reset(pdn, 3);
+ else
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2009-07-13 14:25:37.000000000 -0700
+++ b/include/linux/pci.h 2009-07-15 10:25:37.000000000 -0700
@@ -273,6 +273,7 @@ struct pci_dev {
unsigned int ari_enabled:1; /* ARI forwarding */
unsigned int is_managed:1;
unsigned int is_pcie:1;
+ unsigned int fndmntl_rst_rqd:1; /* Dev requires fundamental reset */
unsigned int state_saved:1;
unsigned int is_physfn:1;
unsigned int is_virtfn:1;
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Becky Bruce @ 2009-07-15 20:24 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeremy Fitzhardinge, tony.luck, linux-ia64, Ian Campbell,
Joerg Roedel, x86, linux-kernel@vger.kernel.org Mailing List,
FUJITA Tomonori, linuxppc-dev@ozlabs.org list
In-Reply-To: <68EFFAF6-EF5B-4148-BC54-70BF2AF2456E@kernel.crashing.org>
On Jul 13, 2009, at 10:13 PM, Becky Bruce wrote:
>
> On Jul 10, 2009, at 12:12 AM, Ingo Molnar wrote:
>
>>
>> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>>
>>> - removes unused (and unnecessary) hooks in swiotlb.
>>>
>>> - adds dma_capable() and converts swiotlb to use it. It can be
>>> used to
>>> know if a memory area is dma capable or not. I added
>>> is_buffer_dma_capable() for the same purpose long ago but it turned
>>> out that the function doesn't work on POWERPC.
>>>
>>> This can be applied cleanly to linux-next, -mm, and mainline. This
>>> patchset touches multiple architectures (ia64, powerpc, x86) so I
>>> guess that -mm is appropriate for this patchset (I don't care much
>>> what tree would merge this though).
>>>
>>> This is tested on x86 but only compile tested on POWERPC and IA64.
>>>
>>> Thanks,
>>>
>>> =
>>> arch/ia64/include/asm/dma-mapping.h | 18 ++++++
>>> arch/powerpc/include/asm/dma-mapping.h | 23 +++++++
>>> arch/powerpc/kernel/dma-swiotlb.c | 48 +---------------
>>> arch/x86/include/asm/dma-mapping.h | 18 ++++++
>>> arch/x86/kernel/pci-dma.c | 2 +-
>>> arch/x86/kernel/pci-gart_64.c | 5 +-
>>> arch/x86/kernel/pci-nommu.c | 2 +-
>>> arch/x86/kernel/pci-swiotlb.c | 25 --------
>>> include/linux/dma-mapping.h | 5 --
>>> include/linux/swiotlb.h | 11 ----
>>> lib/swiotlb.c | 102 ++++++++
>>> +-----------------------
>>> 11 files changed, 92 insertions(+), 167 deletions(-)
>>
>> Hm, the functions and facilities you remove here were added as part
>> of preparatory patches for Xen guest support. You were aware of
>> them, you were involved in discussions about those aspects with Ian
>> and Jeremy but still you chose not to Cc: either of them and you
>> failed to address that aspect in the changelogs.
>>
>> I'd like the Xen code to become cleaner more than anyone else here i
>> guess, but patch submission methods like this are not really
>> helpful. A far better method is to be open about such disagreements,
>> to declare them, to Cc: everyone who disagrees, and to line out the
>> arguments in the changelogs as well - instead of just curtly
>> declaring those APIs 'unused' and failing to Cc: involved parties.
>>
>> Alas, on the technical level the cleanups themselves look mostly
>> fine to me. Ian, Jeremy, the changes will alter Xen's use of
>> swiotlb, but can the Xen side still live with these new methods - in
>> particular is dma_capable() sufficient as a mechanism and can the
>> Xen side filter out DMA allocations to make them physically
>> continuous?
>>
>> Ben, Tony, Becky, any objections wrt. the PowerPC / IA64 impact? If
>> everyone agrees i can apply them to the IOMMU tree, test it and push
>> it out to -next, etc.
>>
>
> Ingo,
>
> With the exception of the patch I commented on, I think these look
> OK from the powerpc point of view. I've successfully booted one of
> my test platforms with the entire series applied and will run some
> more extensive (i.e. not "Whee! A prompt!") tests tomorrow.
Well, I am still testing. I've observed one unexpected LTP testcase
failure with these patches applied, but so far have been unable to
reproduce it. So these patches are probably OK, but I will look into
this some more next week.
-Becky
>
>
> -Becky
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] Hold reference to device_node during EEH event handling
From: Mike Mason @ 2009-07-15 21:43 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, benh, linasvepstas
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.
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;
+ }
+
/* Serialize processing of EEH events */
mutex_lock(&eeh_event_mutex);
eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
@@ -86,6 +94,7 @@ static int eeh_event_handler(void * dumm
eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
pci_dev_put(event->dev);
+ of_node_put(event->dn);
kfree(event);
mutex_unlock(&eeh_event_mutex);
@@ -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;
/* We may or may not be called in an interrupt context */
^ permalink raw reply
* Re: having access to interrupt specifier in map() function
From: Benjamin Herrenschmidt @ 2009-07-15 22:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <761CE7B3-A7FD-41FD-A828-B9F17F73DF32@kernel.crashing.org>
On Wed, 2009-07-15 at 09:11 -0500, Kumar Gala wrote:
> Ben,
>
> Do you have any ideas on keeping access to the interrupt specifier
> around so when we call map() we have access to it. Our HV guys are
> looking at using additional bits in the interrupt specifier to encode
> information beyond just level/sense of the IRQ and want to make
> decisions based on it during map().
>
> Maybe we can keep it around in irq_map[].
Or we could translate those additional info into flags in the IRQ desc ?
Might be possible to request some arch specific flags in there.
Cheers,
Ben.
^ permalink raw reply
* Re: removing addr_needs_map in struct dma_mapping_ops
From: Becky Bruce @ 2009-07-15 23:59 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090714094919V.fujita.tomonori@lab.ntt.co.jp>
On Jul 13, 2009, at 7:49 PM, FUJITA Tomonori wrote:
> On Mon, 13 Jul 2009 16:50:43 -0500
> Becky Bruce <beckyb@kernel.crashing.org> wrote:
>
>>> talked about defining something like struct dma_data. Then we could
>>>
>>> struct dev_archdata {
>>> ...
>>>
>>> struct dma_data *ddata;
>>> };
>>>
>>> or
>>>
>>> struct dev_archdata {
>>> ...
>>>
>>> struct dma_data ddata;
>>> };
>>>
>>>
>>> struct dma_data needs dma_direct_offset, iommu_table, dma_base, and
>>> dma_window_size, anything else?
>>
>> IIRC, what we had talked about was simpler - we talked about changing
>> the current dev_archdata from this:
>>
>> struct dev_archdata {
>> struct device_node *of_node;
>> struct dma_mapping_ops *dma_ops;
>> void *dma_data;
>> };
>>
>> to this:
>>
>> struct dev_archdata {
>> struct device_node *of_node;
>> struct dma_mapping_ops *dma_ops;
>> unsigned long long dma_data;
>> #ifdef CONFIG_SWIOTLB
>> dma_addr_t max_direct_dma_addr;
>> #endif
>> };
>>
>> Where max_direct_dma_addr is the address beyond which a specific
>> device must use swiotlb, and dma_data is the offset like it is now
>> (but wider on 32-bit systems than void *). I believe Ben had
>> mentioned
>> wanting to make the max_direct_dma_addr part conditional so we don't
>> bloat archdata on platforms that don't ever bounce.
>
> Only maximum address is enough? The minimum (dma_window_base_cur in
> swiotlb_pci_addr_needs_map) is not necessary?
>
>
>> The change to the type of dma_data is actually in preparation for an
>> optimization I have planned for 64-bit PCI devices (and which
>> probably
>> requires more discussion), so that doesn't need to happen now - just
>> leave it as a void *, and I can post a followup patch.
>>
>> Let me know if I can help or do any testing - I've been meaning to
>> look into switching to dma_map_ops for a while now but it hasn't
>> managed to pop off my todo stack.
>
> Ok, how about this? I'm not familiar with POWERPC so I might
> misunderstand something.
This is close, but it misses the setup for non-pci devices. We have a
bus notifier that we use to set up archdata for those devices -
ppc_swiotlb_bus_notify() in arch/powerpc/kernel/dma-swiotlb.c. It
won't cause breakage to not have this set up, because those will fall
through to the dma_capable(), but I think we should initialize it
anyway (who knows what it will end up used for later....).
>
>
>
> diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/
> include/asm/device.h
> index 7d2277c..0086f8d 100644
> --- a/arch/powerpc/include/asm/device.h
> +++ b/arch/powerpc/include/asm/device.h
> @@ -16,6 +16,9 @@ struct dev_archdata {
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> void *dma_data;
> +#ifdef CONFIG_SWIOTLB
> + dma_addr_t max_direct_dma_addr;
> +#endif
> };
>
> static inline void dev_archdata_set_node(struct dev_archdata *ad,
> diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/
> include/asm/swiotlb.h
> index 30891d6..b23a4f1 100644
> --- a/arch/powerpc/include/asm/swiotlb.h
> +++ b/arch/powerpc/include/asm/swiotlb.h
> @@ -24,4 +24,6 @@ static inline void dma_mark_clean(void *addr,
> size_t size) {}
> extern unsigned int ppc_swiotlb_enable;
> int __init swiotlb_setup_bus_notifier(void);
>
> +extern void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev);
> +
> #endif /* __ASM_SWIOTLB_H */
> diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/
> dma-swiotlb.c
> index 68ccf11..e21359e 100644
> --- a/arch/powerpc/kernel/dma-swiotlb.c
> +++ b/arch/powerpc/kernel/dma-swiotlb.c
> @@ -56,39 +56,16 @@ swiotlb_arch_address_needs_mapping(struct device
> *hwdev, dma_addr_t addr,
> size_t size)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
> + struct dev_archdata *sd = &hwdev->archdata;
>
> BUG_ON(!dma_ops);
> - return dma_ops->addr_needs_map(hwdev, addr, size);
> -}
You can get rid of the dma_ops stuff here.... it's no longer needed.
>
>
> -/*
> - * Determine if an address is reachable by a pci device, or if we
> must bounce.
> - */
> -static int
> -swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr,
> size_t size)
> -{
> - u64 mask = dma_get_mask(hwdev);
> - dma_addr_t max;
> - struct pci_controller *hose;
> - struct pci_dev *pdev = to_pci_dev(hwdev);
> -
> - hose = pci_bus_to_host(pdev->bus);
> - max = hose->dma_window_base_cur + hose->dma_window_size;
> -
> - /* check that we're within mapped pci window space */
> - if ((addr + size > max) | (addr < hose->dma_window_base_cur))
> + if (sd->max_direct_dma_addr && addr + size > sd-
> >max_direct_dma_addr)
> return 1;
>
> - return !is_buffer_dma_capable(mask, addr, size);
> -}
> -
> -static int
> -swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr,
> size_t size)
> -{
> return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
> }
>
> -
> /*
> * At the moment, all platforms that use this code only require
> * swiotlb to be used if we're operating on HIGHMEM. Since
> @@ -104,7 +81,6 @@ struct dma_mapping_ops swiotlb_dma_ops = {
> .dma_supported = swiotlb_dma_supported,
> .map_page = swiotlb_map_page,
> .unmap_page = swiotlb_unmap_page,
> - .addr_needs_map = swiotlb_addr_needs_map,
> .sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
> .sync_single_range_for_device = swiotlb_sync_single_range_for_device,
> .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
> @@ -119,13 +95,23 @@ struct dma_mapping_ops swiotlb_pci_dma_ops = {
> .dma_supported = swiotlb_dma_supported,
> .map_page = swiotlb_map_page,
> .unmap_page = swiotlb_unmap_page,
> - .addr_needs_map = swiotlb_pci_addr_needs_map,
> .sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
> .sync_single_range_for_device = swiotlb_sync_single_range_for_device,
> .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
> .sync_sg_for_device = swiotlb_sync_sg_for_device
> };
>
> +void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
> +{
> + struct pci_controller *hose;
> + struct dev_archdata *sd;
> +
> + hose = pci_bus_to_host(pdev->bus);
> + sd = &pdev->dev.archdata;
> + sd->max_direct_dma_addr =
> + hose->dma_window_base_cur + hose->dma_window_size;
> +}
> +
> static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> diff --git a/arch/powerpc/platforms/85xx/mpc8536_ds.c b/arch/powerpc/
> platforms/85xx/mpc8536_ds.c
> index 055ff41..401751b 100644
> --- a/arch/powerpc/platforms/85xx/mpc8536_ds.c
> +++ b/arch/powerpc/platforms/85xx/mpc8536_ds.c
> @@ -136,6 +136,7 @@ define_machine(mpc8536_ds) {
> .init_IRQ = mpc8536_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/
> platforms/85xx/mpc85xx_ds.c
> index 849c0ac..1ba8e38 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
> @@ -277,6 +277,7 @@ define_machine(mpc8544_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -291,6 +292,7 @@ define_machine(mpc8572_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> @@ -305,6 +307,7 @@ define_machine(p2020_ds) {
> .init_IRQ = mpc85xx_ds_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/
> powerpc/platforms/85xx/mpc85xx_mds.c
> index 60ed9c0..165a2de 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -356,6 +356,7 @@ define_machine(mpc8568_mds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> };
>
> @@ -377,5 +378,6 @@ define_machine(mpc8569_mds) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> };
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index 6632702..d1878f3 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -187,5 +187,6 @@ define_machine(mpc86xx_hpcn) {
> .progress = udbg_progress,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> + .pci_dma_dev_setup = pci_dma_dev_setup_swiotlb,
> #endif
> };
Instead of initializing this here (which has problems if !
CONFIG_SWIOTLB), place this in the xxxxx_xxxx_setup_arch function in
the same files, which already have an #ifdef CONFIG_SWIOTLB in which
this can be embedded.
I'm about to be off-list for a few days but will be happy to help when
I'm back next week.
Thanks!
Becky
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 2/4] edac: mpc85xx add mpc83xx support
From: Doug Thompson @ 2009-07-16 0:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Ira W. Snyder, linux-kernel, Dave Jiang, linuxppc-dev,
bluesmoke-devel
In-Reply-To: <20090715125249.e746496f.akpm@linux-foundation.org>
=0AIra or Kumar,=0A=0Acan you address Andrew's concerns below and what was =
posted in prior posts on this?=0A=0Athanks=0A=0Adoug t=0A=0A--- On Wed, 7/1=
5/09, Andrew Morton <akpm@linux-foundation.org> wrote:=0A=0A> From: Andrew =
Morton <akpm@linux-foundation.org>=0A> Subject: Re: [PATCH 2/4] edac: mpc85=
xx add mpc83xx support=0A> To: dougthompson@xmission.com=0A> Cc: bluesmoke-=
devel@lists.sourceforge.net, linux-kernel@vger.kernel.org=0A> Date: Wednesd=
ay, July 15, 2009, 1:52 PM=0A> On Wed, 15 Jul 2009 11:38:49 -0600=0A> dougt=
hompson@xmission.com=0A> wrote:=0A> =0A> > =0A> > Add support for the Frees=
cale MPC83xx memory=0A> controller to the existing=0A> > driver for the Fre=
escale MPC85xx memory controller.=0A> The only difference=0A> > between the=
two processors are in the CS_BNDS register=0A> parsing code, which=0A> > h=
as been changed so it will work on both processors.=0A> > =0A> > The L2 cac=
he controller does not exist on the MPC83xx,=0A> but the OF subsystem=0A> >=
will not use the driver if the device is not present=0A> in the OF device =
tree.=0A> > =0A> > =0A> > Kumar, I had to change the nr_pages calculation t=
o=0A> make the math work=0A> > out. I checked it on my board and did the ma=
th by hand=0A> for a 64GB 85xx=0A> > using 64K pages. In both cases, nr_pag=
es * PAGE_SIZE=0A> comes out to the=0A> > correct value. Thanks for the hel=
p.=0A> > =0A> > v1 -> v2:=0A> >=A0=A0=A0* Use PAGE_SHIFT to parse cs_bnds=
=0A> regardless of board type=0A> >=A0=A0=A0* Remove special-casing for the=
83xx=0A> processor=0A> > =0A> > ...=0A> >=0A> > @@ -789,19 +791,20 @@ stat=
ic void __devinit=0A> mpc85xx_init_csrow=0A> >=A0 =A0=A0=A0 =A0=A0=A0 csrow=
=3D=0A> &mci->csrows[index];=0A> >=A0 =A0=A0=A0 =A0=A0=A0 cs_bnds =3D=0A> =
in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +=0A> >=A0 =A0=A0=A0 =A0=A0=
=A0=0A> =A0=A0=A0 =A0=A0=A0 =A0 (index *=0A> MPC85XX_MC_CS_BNDS_OFS));=0A> =
> -=A0=A0=A0 =A0=A0=A0 start =3D=0A> (cs_bnds & 0xfff0000) << 4;=0A> > -=A0=
=A0=A0 =A0=A0=A0 end =3D ((cs_bnds=0A> & 0xfff) << 20);=0A> > -=A0=A0=A0 =
=A0=A0=A0 if (start)=0A> > -=A0=A0=A0 =A0=A0=A0=0A> =A0=A0=A0 start |=3D 0x=
fffff;=0A> > -=A0=A0=A0 =A0=A0=A0 if (end)=0A> > -=A0=A0=A0 =A0=A0=A0=0A> =
=A0=A0=A0 end |=3D 0xfffff;=0A> > +=0A> > +=A0=A0=A0 =A0=A0=A0 start =3D=0A=
> (cs_bnds & 0xffff0000) >> 16;=0A> > +=A0=A0=A0 =A0=A0=A0=0A> end=A0=A0=A0=
=3D (cs_bnds & 0x0000ffff);=0A> >=A0 =0A> >=A0 =A0=A0=A0 =A0=A0=A0 if (star=
t=0A> =3D=3D end)=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> =A0=A0=A0 continue;=A0=
=A0=A0 /* not=0A> populated */=0A> >=A0 =0A> > +=A0=A0=A0 =A0=A0=A0 start <=
<=3D=0A> (24 - PAGE_SHIFT);=0A> > +=A0=A0=A0 =A0=A0=A0=0A> end=A0=A0=A0<<=
=3D (24 - PAGE_SHIFT);=0A> > +=A0=A0=A0 =A0=A0=A0 end=A0=0A> =A0 |=3D (1 <<=
(24 - PAGE_SHIFT)) - 1;=0A> =0A> <stares for a while>=0A> =0A> That looks =
like the original code was really really wrong.=0A> =0A> The setting of all=
the lower bits in `end' is=0A> funny-looking.=A0 What's=0A> happening here=
?=A0 Should it be commented?=0A> =0A> =0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> csr=
ow->first_page =3D start >> PAGE_SHIFT;=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> cs=
row->last_page =3D end >> PAGE_SHIFT;=0A> > -=A0=A0=A0 =A0=A0=A0=0A> csrow-=
>nr_pages =3D csrow->last_page + 1 -=0A> csrow->first_page;=0A> > +=A0=A0=
=A0 =A0=A0=A0=0A> csrow->nr_pages =3D end + 1 - start;=0A> >=A0 =A0=A0=A0 =
=A0=A0=A0=0A> csrow->grain =3D 8;=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> csrow->m=
type =3D mtype;=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> csrow->dtype =3D DEV_UNKNO=
WN;=0A> > @@ -985,6 +988,7 @@ static struct of_device_id=0A> mpc85xx_mc_er=
=0A> >=A0 =A0=A0=A0 { .compatible =3D=0A> "fsl,mpc8560-memory-controller", =
},=0A> >=A0 =A0=A0=A0 { .compatible =3D=0A> "fsl,mpc8568-memory-controller"=
, },=0A> >=A0 =A0=A0=A0 { .compatible =3D=0A> "fsl,mpc8572-memory-controlle=
r", },=0A> > +=A0=A0=A0 { .compatible =3D=0A> "fsl,mpc8349-memory-controlle=
r", },=0A> >=A0 =A0=A0=A0 { .compatible =3D=0A> "fsl,p2020-memory-controlle=
r", },=0A> >=A0 =A0=A0=A0 {},=0A> >=A0 };=0A> > @@ -1001,13 +1005,13 @@ sta=
tic struct=0A> of_platform_driver mpc85xx=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> =
=A0=A0=A0},=0A> >=A0 };=0A> >=A0 =0A> > -=0A> > +#ifdef CONFIG_MPC85xx=0A> =
>=A0 static void __init mpc85xx_mc_clear_rfxe(void=0A> *data)=0A> >=A0 {=0A=
> >=A0 =A0=A0=A0 orig_hid1[smp_processor_id()]=0A> =3D mfspr(SPRN_HID1);=0A=
> >=A0 =A0=A0=A0 mtspr(SPRN_HID1,=0A> (orig_hid1[smp_processor_id()] & ~0x2=
0000));=0A> >=A0 }=0A> > -=0A> > +#endif=0A> >=A0 =0A> >=A0 static int __in=
it mpc85xx_mc_init(void)=0A> >=A0 {=0A> > @@ -1040,26 +1044,32 @@ static in=
t __init=0A> mpc85xx_mc_init(void)=0A> >=A0 =A0=A0=A0 =A0=A0=A0=0A> printk(=
KERN_WARNING EDAC_MOD_STR "PCI fails to=0A> register\n");=0A> >=A0 #endif=
=0A> >=A0 =0A> > +#ifdef CONFIG_MPC85xx=0A> >=A0 =A0=A0=A0 /*=0A> >=A0 =A0=
=A0=A0=A0=A0* need to clear=0A> HID1[RFXE] to disable machine check int=0A>=
>=A0 =A0=A0=A0=A0=A0* so we can catch=0A> it=0A> >=A0 =A0=A0=A0=A0=A0*/=0A=
> >=A0 =A0=A0=A0 if (edac_op_state =3D=3D=0A> EDAC_OPSTATE_INT)=0A> >=A0 =
=A0=A0=A0 =A0=A0=A0=0A> on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);=0A> > =
+#endif=0A> >=A0 =0A> >=A0 =A0=A0=A0 return 0;=0A> >=A0 }=0A> =0A> The patc=
h adds lots of ifdefs :(=0A> =0A> >=A0 module_init(mpc85xx_mc_init);=0A> >=
=A0 =0A> > +#ifdef CONFIG_MPC85xx=0A> >=A0 static void __exit mpc85xx_mc_re=
store_hid1(void=0A> *data)=0A> >=A0 {=0A> >=A0 =A0=A0=A0 mtspr(SPRN_HID1,=
=0A> orig_hid1[smp_processor_id()]);=0A> >=A0 }=0A> > +#endif=0A> =0A> afac=
it this will run smp_processor_id() from within=0A> preemptible code,=0A> w=
hich is often buggy on preemptible kernels and will cause=0A> runtime=0A> w=
arnings on at least some architectures.=0A> =0A> >=A0 static void __exit mp=
c85xx_mc_exit(void)=0A> >=A0 {=0A> > +#ifdef CONFIG_MPC85xx=0A> >=A0 =A0=A0=
=A0=0A> on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);=0A> > +#endif=0A> >=
=A0 #ifdef CONFIG_PCI=0A> >=A0 =A0=A0=A0=0A> of_unregister_platform_driver(=
&mpc85xx_pci_err_driver);=0A> >=A0 #endif=0A>
^ permalink raw reply
* [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Michael Ellerman @ 2009-07-16 1:25 UTC (permalink / raw)
To: catalin.marinas; +Cc: linuxppc-dev
Very lightly tested, doesn't crash the kernel.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
It doesn't look like we actually need to add any support in the
arch code - or is there something I'm missing?
lib/Kconfig.debug | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 12327b2..d5ca9a5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -338,7 +338,7 @@ config SLUB_STATS
config DEBUG_KMEMLEAK
bool "Kernel memory leak detector"
- depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM) && \
+ depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM || PPC) && \
!MEMORY_HOTPLUG
select DEBUG_FS if SYSFS
select STACKTRACE if STACKTRACE_SUPPORT
--
1.6.2.1
^ permalink raw reply related
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Michael Ellerman @ 2009-07-16 1:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, Nick Piggin, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <20090715074952.A36C7DDDB2@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Wed, 2009-07-15 at 17:49 +1000, Benjamin Herrenschmidt wrote:
> Upcoming paches to support the new 64-bit "BookE" powerpc architecture
> will need to have the virtual address corresponding to PTE page when
> freeing it, due to the way the HW table walker works.
> I haven't had a chance to test or even build on most architectures, the
> patch is reasonably trivial but I may have screwed up regardless, I
> appologize in advance, let me know if something is wrong.
Builds for the important architectures, powerpc, ia64, arm, sparc,
sparc64, oh and x86:
http://kisskb.ellerman.id.au/kisskb/head/1976/
(based on your test branch 34f25476)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Hold reference to device_node during EEH event handling
From: Michael Ellerman @ 2009-07-16 1:41 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, linasvepstas, Paul Mackerras
In-Reply-To: <4A5E4D68.6070909@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
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 :)
And what happens if the refcount goes to 1 just after the check? ie.
here.
> /* Serialize processing of EEH events */
> mutex_lock(&eeh_event_mutex);
> eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-16 1:54 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, Linux Memory Management, Hugh Dickins, linux-kernel,
linuxppc-dev
In-Reply-To: <20090715135620.GD7298@wotan.suse.de>
On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> On Wed, Jul 15, 2009 at 05:49:47PM +1000, Benjamin Herrenschmidt wrote:
> > Upcoming paches to support the new 64-bit "BookE" powerpc architecture
> > will need to have the virtual address corresponding to PTE page when
> > freeing it, due to the way the HW table walker works.
> >
> > Basically, the TLB can be loaded with "large" pages that cover the whole
> > virtual space (well, sort-of, half of it actually) represented by a PTE
> > page, and which contain an "indirect" bit indicating that this TLB entry
> > RPN points to an array of PTEs from which the TLB can then create direct
> > entries.
>
> RPN is PFN in ppc speak, right?
Ah right, real page number in ppc slang :-)
> > Thus, in order to invalidate those when PTE pages are deleted,
> > we need the virtual address to pass to tlbilx or tlbivax instructions.
>
> Interesting arrangement. So are these last level ptes modifieable
> from userspace or something? If not, I wonder if you could manage
> them as another level of pointers with the existing pagetable
> functions?
I don't understand what you mean. Basically, the TLB contains PMD's.
There's nothing to change to the existing page table layout :-) But
because they appear as large page TLB entries that cover the virtual
space covered by a PMD, they need to be invalidated using virtual
addresses when PMDs are removed.
> > The old trick of sticking it somewhere in the PTE page struct page sucks
> > too much, the address is almost readily available in all call sites and
> > almost everybody implemets these as macros, so we may as well add the
> > argument everywhere. I added it to the pmd and pud variants for consistency.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > 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.
Thanks, can I get an Ack then ? :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-16 1:56 UTC (permalink / raw)
To: michael
Cc: Linux-Arch, Nick Piggin, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management
In-Reply-To: <1247708177.9851.4.camel@concordia>
On Thu, 2009-07-16 at 11:36 +1000, Michael Ellerman wrote:
>
> Builds for the important architectures, powerpc, ia64, arm, sparc,
> sparc64, oh and x86:
>
> http://kisskb.ellerman.id.au/kisskb/head/1976/
>
> (based on your test branch 34f25476)
Note for all lurkers: the fails in there are unrelated to the patch
(mostly warnings triggering our new Werror and probably mostly fixed
upstream already).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/15] swiotlb: remove unnecessary swiotlb_bus_to_virt
From: Benjamin Herrenschmidt @ 2009-07-16 3:40 UTC (permalink / raw)
To: Becky Bruce
Cc: tony.luck, linux-ia64, x86, linux-kernel, FUJITA Tomonori,
linuxppc-dev
In-Reply-To: <5E909C02-3FA2-4BEB-8C73-F4E4A5A404BF@kernel.crashing.org>
On Mon, 2009-07-13 at 21:17 -0500, Becky Bruce wrote:
>
> phys_to_virt (also, virt_to_phys) is invalid for highmem addresses on
> ppc.
I would be surprised if x86 was any different here. Most of our highmem
implementation comes straight from x86 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ethernet driver - problem capturing own packet in promiscous mode
From: sudheer a @ 2009-07-16 4:07 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01D4FF0A202C@ATLMBX.verint.corp.verintsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On Wed, Jul 15, 2009 at 5:52 PM, Cote, Sylvain <Sylvain.Cote@verint.com>wrote:
> > Hi all
>
>
>
> > In ethernet driver i need to enable promiscous mode and have to capture
> the packet that is sent by the same ethernet.
>
>
>
> > The board is connected to a packet generator and could send/receive
> packets whenever i need .
>
>
>
> > In the board ethernet driver , I made sure that am sending only
> broadcast packets and promisc mode is enabled but the packets are not
> captured. If i am sending a packet to the board from packetgenerator it is
> receiving.
>
>
>
> > Could any one please suggest me any clues.
>
>
>
> > Having the promisc enabled:
>
> > Packet sent by packetgenerator is received by board.
>
> > Packet sent by board is received by packetgenerator, The same packet
> should be captured by board as promiscuous is enabled. but not happening.
>
>
>
>
>
> The Ethernet interface that sent the packet will never receive the packet
> it sent even if you are in promiscuous mode. To be able to do that you
> should put your interface in loopback mode.
>
> In promiscuous mode, you will be able to receive any packets sent by other
> interfaces (broadcast, multicast and also unicast that is not directed to
> you interface MAC address). But not
>
> from your interface.
>
Thanks for your inputs Sylvain.
I tried with loopback, it is working.
But during the time the hardware is in lopback mode, it may miss some rx
packets coming from outside or packet generator unfortunately and i dont
want it to happen.
Please let me know your views and suggestions.
Thanks
Sudheer
[-- Attachment #2: Type: text/html, Size: 4319 bytes --]
^ permalink raw reply
* Re: booting MPC8313 based board with yaffs2 RFS
From: Rupesh Kumar @ 2009-07-16 5:22 UTC (permalink / raw)
To: tonyliu; +Cc: linuxppc-dev
In-Reply-To: <4A5FDCDF.9010005@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
Hi
Thanks for reply.
After erasing one of the flash partition, i mounted it as yaffs2 and
manually created rootfs there.
Though it (careting RFS in NAND partiton) marked blocks bad, I am able to
boot with this yaffs2 filesystem.
When image is created with mkyffs2image binary, board does not boot with
that and says kernel panic.
1. What nand flash is on-board? what's the size of the nand flash page
size, 512/2048?
Nand Flash used on board is K9F2G08U0M-P from Samsung and page size is
2048.
2. what's the version of mkyaffs2image you are using?
mkyaffs2image: image building tool for YAFFS2 built Jan 31 2009
3. Can you mount an empty nand flash partition using yaffs2 type,
mount /dev/mtdblock##x xxx
Yes, i wrote RFS contents to the nand flash partition and booted with
that.
4. It's better to attatch bootup message.
Bootup message is attached for both conditions
1) booting with manually created RFS on flash drive mounted as
yaffs2(boot-up_manual_RFS.txt).
2) booting with yaffs2 image created by mkyaffs2image tool.
Note :- below are steps used for writing RFS iamge
~ # flash_eraseall /dev/mtd11
~ # nandwrite -a -o /dev/mtd11 rootrfs_1.yaffs2
Thanks
Rupesh
tonyliu <Bo.Liu@windriver.com>
07/17/2009 07:37 AM
To
Rupesh Kumar <Rupesh.Kumar@Lntemsys.com>
cc
linuxppc-dev@lists.ozlabs.org
Subject
Re: booting MPC8313 based board with yaffs2 RFS
Rupesh Kumar wrote:
> Hi
> I am using MPC8313 board which is currently booting with JFFS2 root file
> system.
> I am using linux kernel version 2.6.23 from FreeScale's LTIB for
MPC8313.
>
> As, I want it to boot with YAFFS2 root file system, I did compile kernel
> with yaffs2 support, craeted yaffs2 rootfile system and passed yaffs2
> partiton of nand in bootargs. However it didnot work.
>
>
> If any one has done it successfully, can please share the steps to be
> followed ?
>
More detailed info maybe helpful for debugging this issue.
1. What nand flash is on-board? what's the size of the nand flash page
size, 512/2048?
2. what's the version of mkyaffs2image you are using?
3. Can you mount an empty nand flash partition using yaffs2 type,
mount /dev/mtdblock##x xxx
4. It's better to attatch bootup message.
Tony
> Thanks
> Rupesh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
[-- Attachment #2: boot-up_manual_RFS.txt --]
[-- Type: text/plain, Size: 22487 bytes --]
U-Boot 1.3.0-S600-Ver1.0 (Jul 16 2009 - 00:03:56) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, Rev: Unknown revision number:80b10021
Warning: Unsupported cpu revision!
Board: S600 CPU BOARD
I2C: ready
DRAM: 128 MB
FLASH: 16 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
Hit any key to stop autoboot: 6 \b\b\b 5 \b\b\b 4 \b\b\b 3 \b\b\b 2 \b\b\b 1 \b\b\b 0
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 192.168.6.251; our IP address is 192.168.34.10; sending through gateway 192.168.32.47
Filename 'uImage_yaffs2'.
Load address: 0x200000
Loading: *\b#################################################################
#################################################
done
Bytes transferred = 1669252 (197884 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-S600-Ver1.0
Created: 2009-07-16 2:03:41 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1669188 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xfe900000
Loading Device Tree to 007fd000, end 007fef4f ... OK
Using MPC8313 RDB machine description
Linux version 2.6.23-S600-Ver1.0 (root@leapfrogserver) (gcc version 4.1.2) #71 Thu Jul 16 07:33:39 IST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc8313_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/mtdblock12 rootfstype=yaffs2 rw console=ttyS0,115200
IPIC (128 IRQ sources) at fdef9700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126220k/131072k available (3288k kernel code, 4712k reserved, 148k data, 96k bss, 152k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
yaffs Jul 16 2009 04:53:10 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
device node obtained!
sram_irq = 48
Sram driver inserted
Serial: 8250/16550 driver $Revision: 1.90 $ 14 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 18) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 21) is a 16550A
serial8250.0: ttyS2 at MMIO 0xfa000000 (irq = 22) is a ST16654
serial8250.0: ttyS3 at MMIO 0xfa000008 (irq = 22) is a ST16654
serial8250.0: ttyS4 at MMIO 0xfa000010 (irq = 22) is a ST16654
serial8250.0: ttyS5 at MMIO 0xfa000018 (irq = 22) is a ST16654
serial8250.0: ttyS6 at MMIO 0xfa000020 (irq = 22) is a ST16654
serial8250.0: ttyS7 at MMIO 0xfa000028 (irq = 22) is a ST16654
serial8250.0: ttyS8 at MMIO 0xfa000030 (irq = 22) is a ST16654
serial8250.0: ttyS9 at MMIO 0xfa000038 (irq = 22) is a ST16654
serial8250.0: ttyS10 at MMIO 0xfa000040 (irq = 23) is a ST16654
serial8250.0: ttyS11 at MMIO 0xfa000048 (irq = 23) is a ST16654
serial8250.0: ttyS12 at MMIO 0xfa000050 (irq = 23) is a ST16654
serial8250.0: ttyS13 at MMIO 0xfa000058 (irq = 23) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:01
GFAR: SKB Handler initialized at CPU#0(max=32)
eth0: MTU = 1500 (frame size=1526, truesize=1800)
eth0: Running with NAPI enabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:02
GFAR: SKB Handler initialized at CPU#0(max=32)
eth1: MTU = 1500 (frame size=1526, truesize=1800)
eth1: Running with NAPI enabled
eth1: 64/64 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Marvell 88E1101: Registered new driver
Marvell 88E1112: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
Fixed MDIO Bus: probed
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
nor: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
nor: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
physmap-flash nor: Using OF partition information
Creating 6 MTD partitions on "nor":
0x00000000-0x00100000 : "U-Boot"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x01000000 : "Unused"
Freescale eLBC NAND Driver (C) 2006-2007 Freescale
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 1062 at 0x084c0000
Bad eraseblock 1063 at 0x084e0000
Bad eraseblock 1064 at 0x08500000
Bad eraseblock 1065 at 0x08520000
Bad eraseblock 1066 at 0x08540000
Bad eraseblock 1067 at 0x08560000
Bad eraseblock 1068 at 0x08580000
Bad eraseblock 1069 at 0x085a0000
Bad eraseblock 1070 at 0x085c0000
Bad eraseblock 1071 at 0x085e0000
Bad eraseblock 1072 at 0x08600000
Bad eraseblock 1073 at 0x08620000
Bad eraseblock 1074 at 0x08640000
Bad eraseblock 1075 at 0x08660000
Bad eraseblock 1076 at 0x08680000
Bad eraseblock 1077 at 0x086a0000
Bad eraseblock 1078 at 0x086c0000
Bad eraseblock 1079 at 0x086e0000
Bad eraseblock 1080 at 0x08700000
Bad eraseblock 1081 at 0x08720000
Bad eraseblock 1082 at 0x08740000
Bad eraseblock 1083 at 0x08760000
Bad eraseblock 1084 at 0x08780000
Bad eraseblock 1085 at 0x087a0000
Bad eraseblock 1086 at 0x087c0000
Bad eraseblock 1087 at 0x087e0000
Bad eraseblock 1088 at 0x08800000
Bad eraseblock 1089 at 0x08820000
Bad eraseblock 1090 at 0x08840000
Bad eraseblock 1091 at 0x08860000
Bad eraseblock 1092 at 0x08880000
Bad eraseblock 1093 at 0x088a0000
Bad eraseblock 1094 at 0x088c0000
Bad eraseblock 1095 at 0x088e0000
Bad eraseblock 1096 at 0x08900000
Bad eraseblock 1097 at 0x08920000
Bad eraseblock 1098 at 0x08940000
Bad eraseblock 1099 at 0x08960000
Bad eraseblock 1100 at 0x08980000
Bad eraseblock 1101 at 0x089a0000
Bad eraseblock 1102 at 0x089c0000
Bad eraseblock 1103 at 0x089e0000
Bad eraseblock 1104 at 0x08a00000
Bad eraseblock 1105 at 0x08a20000
Bad eraseblock 1106 at 0x08a40000
Bad eraseblock 1107 at 0x08a60000
Bad eraseblock 1108 at 0x08a80000
Bad eraseblock 1109 at 0x08aa0000
Bad eraseblock 1110 at 0x08ac0000
Bad eraseblock 1111 at 0x08ae0000
Bad eraseblock 1112 at 0x08b00000
Bad eraseblock 1113 at 0x08b20000
Bad eraseblock 1114 at 0x08b40000
Bad eraseblock 1115 at 0x08b60000
Bad eraseblock 1116 at 0x08b80000
Bad eraseblock 1117 at 0x08ba0000
Bad eraseblock 1118 at 0x08bc0000
Bad eraseblock 1119 at 0x08be0000
Bad eraseblock 1120 at 0x08c00000
Bad eraseblock 1121 at 0x08c20000
Bad eraseblock 1122 at 0x08c40000
Bad eraseblock 1123 at 0x08c60000
Bad eraseblock 1124 at 0x08c80000
Bad eraseblock 1125 at 0x08ca0000
Bad eraseblock 1126 at 0x08cc0000
Bad eraseblock 1127 at 0x08ce0000
Bad eraseblock 1128 at 0x08d00000
Bad eraseblock 1129 at 0x08d20000
Bad eraseblock 1130 at 0x08d40000
Bad eraseblock 1131 at 0x08d60000
Bad eraseblock 1132 at 0x08d80000
Bad eraseblock 1133 at 0x08da0000
Bad eraseblock 1134 at 0x08dc0000
Bad eraseblock 1135 at 0x08de0000
Bad eraseblock 1136 at 0x08e00000
Bad eraseblock 1137 at 0x08e20000
Bad eraseblock 1138 at 0x08e40000
Bad eraseblock 1139 at 0x08e60000
Bad eraseblock 1140 at 0x08e80000
Bad eraseblock 1141 at 0x08ea0000
Bad eraseblock 1142 at 0x08ec0000
Bad eraseblock 1143 at 0x08ee0000
Bad eraseblock 1144 at 0x08f00000
Bad eraseblock 1145 at 0x08f20000
Bad eraseblock 1146 at 0x08f40000
Bad eraseblock 1147 at 0x08f60000
Bad eraseblock 1148 at 0x08f80000
Bad eraseblock 1149 at 0x08fa0000
Bad eraseblock 1150 at 0x08fc0000
Bad eraseblock 1151 at 0x08fe0000
Bad eraseblock 1152 at 0x09000000
Bad eraseblock 1153 at 0x09020000
Bad eraseblock 1154 at 0x09040000
Bad eraseblock 1155 at 0x09060000
Bad eraseblock 1156 at 0x09080000
Bad eraseblock 1157 at 0x090a0000
Bad eraseblock 1158 at 0x090c0000
Bad eraseblock 1159 at 0x090e0000
Bad eraseblock 1160 at 0x09100000
Bad eraseblock 1161 at 0x09120000
Bad eraseblock 1162 at 0x09140000
Bad eraseblock 1163 at 0x09160000
Bad eraseblock 1164 at 0x09180000
Bad eraseblock 1165 at 0x091a0000
Bad eraseblock 1166 at 0x091c0000
Bad eraseblock 1167 at 0x091e0000
Bad eraseblock 1168 at 0x09200000
Bad eraseblock 1169 at 0x09220000
Bad eraseblock 1170 at 0x09240000
Bad eraseblock 1171 at 0x09260000
Bad eraseblock 1172 at 0x09280000
Bad eraseblock 1173 at 0x092a0000
Bad eraseblock 1174 at 0x092c0000
Bad eraseblock 1175 at 0x092e0000
Bad eraseblock 1176 at 0x09300000
Bad eraseblock 1177 at 0x09320000
Bad eraseblock 1178 at 0x09340000
Bad eraseblock 1179 at 0x09360000
Bad eraseblock 1180 at 0x09380000
Bad eraseblock 1181 at 0x093a0000
Bad eraseblock 1182 at 0x093c0000
Bad eraseblock 1183 at 0x093e0000
Bad eraseblock 1184 at 0x09400000
Bad eraseblock 1185 at 0x09420000
Bad eraseblock 1186 at 0x09440000
Bad eraseblock 1187 at 0x09460000
Bad eraseblock 1188 at 0x09480000
Bad eraseblock 1189 at 0x094a0000
Bad eraseblock 1190 at 0x094c0000
Bad eraseblock 1191 at 0x094e0000
Bad eraseblock 1192 at 0x09500000
Bad eraseblock 1193 at 0x09520000
Bad eraseblock 1194 at 0x09540000
Bad eraseblock 1195 at 0x09560000
Bad eraseblock 1196 at 0x09580000
Bad eraseblock 1197 at 0x095a0000
Bad eraseblock 1198 at 0x095c0000
Bad eraseblock 1199 at 0x095e0000
Bad eraseblock 1200 at 0x09600000
Bad eraseblock 1201 at 0x09620000
Bad eraseblock 1202 at 0x09640000
Bad eraseblock 1203 at 0x09660000
Bad eraseblock 1204 at 0x09680000
Bad eraseblock 1205 at 0x096a0000
Bad eraseblock 1206 at 0x096c0000
Bad eraseblock 1207 at 0x096e0000
Bad eraseblock 1208 at 0x09700000
Bad eraseblock 1209 at 0x09720000
Bad eraseblock 1210 at 0x09740000
Bad eraseblock 1211 at 0x09760000
Bad eraseblock 1212 at 0x09780000
Bad eraseblock 1213 at 0x097a0000
Bad eraseblock 1214 at 0x097c0000
Bad eraseblock 1215 at 0x097e0000
Bad eraseblock 1216 at 0x09800000
Bad eraseblock 1217 at 0x09820000
Bad eraseblock 1218 at 0x09840000
Bad eraseblock 1219 at 0x09860000
Bad eraseblock 1220 at 0x09880000
Bad eraseblock 1221 at 0x098a0000
Bad eraseblock 1222 at 0x098c0000
Bad eraseblock 1223 at 0x098e0000
Bad eraseblock 1224 at 0x09900000
Bad eraseblock 1225 at 0x09920000
Bad eraseblock 1226 at 0x09940000
Bad eraseblock 1227 at 0x09960000
Bad eraseblock 1228 at 0x09980000
Bad eraseblock 1229 at 0x099a0000
Bad eraseblock 1230 at 0x099c0000
Bad eraseblock 1231 at 0x099e0000
Bad eraseblock 1232 at 0x09a00000
Bad eraseblock 1233 at 0x09a20000
Bad eraseblock 1234 at 0x09a40000
fsl-elbc fsl-elbc.0: Using OF partition information
Creating 7 MTD partitions on "nand":
0x00000000-0x00100000 : "U-Boot-NAND"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x08500000 : "RFS1"
0x084c0000-0x0ffc0000 : "RFS2"
mpc83xx_spi.0: MPC83xx SPI Controller driver at 0xc907e000 (irq = 24)
usbmon: debugfs is not available
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
CMD REG : 10009
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds)
mmc_spi spi28672.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
rtc-ds1307 0-0068: setting the system clock to 2009-07-15 13:15:24 (1247663724)
yaffs: dev is 32505868 name is "mtdblock12"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.12, "mtdblock12"
yaffs: restored from checkpoint
yaffs_read_super: isCheckpointed 1
VFS: Mounted root (yaffs2 filesystem).
Freeing unused kernel memory: 152k init
Setting the hostname to S600CPUBoardRev2.1
Mounting filesystems
Running sysctl
Setting up networking on loopback device:
nand_erase: attempt to erase a bad block at page 0x00013180
------retval -5--------1
nand_erase: attempt to erase a bad block at page 0x000131c0
------retval -5--------1
Warning: no IPADDR is set, please set this from the ltib
config screen, or directly in /etc/rc.d/rc.conf.
IP address setup bypassed
Setting up networking on eth1:
Adding static route for default gateway to 192.168.174.47:
**>> yaffs chunk 10432 was not erased
**>> yaffs chunk 10433 was not erased
**>> yaffs chunk 10434 was not erased
**>> yaffs chunk 10435 was not erased
**>> yaffs chunk 10436 was not erased
**>> yaffs chunk 10437 was not erased
**>> yaffs chunk 10438 was not erased
**>> yaffs chunk 10439 was not erased
**>> yaffs chunk 10440 was not erased
**>> yaffs chunk 10441 was not erased
**>> yaffs chunk 10442 was not erased
**>> yaffs chunk 10443 was not erased
**>> yaffs chunk 10444 was not erased
**>> yaffs chunk 10445 was not erased
**>> yaffs chunk 10446 was not erased
**>> yaffs chunk 10447 was not erased
**>> yaffs chunk 10448 was not erased
**>> yaffs chunk 10449 was not erased
**>> yaffs chunk 10450 was not erased
**>> yaffs chunk 10451 was not erased
**>> yaffs chunk 10452 was not erased
**>> yaffs chunk 10453 was not erased
**>> yaffs chunk 10454 was not erased
**>> yaffs chunk 10455 was not erased
**>> yaffs chunk 10456 was not erased
**>> yaffs chunk 10457 was not erased
**>> yaffs chunk 10458 was not erased
**>> yaffs chunk 10459 was not erased
**>> yaffs chunk 10460 was not erased
**>> yaffs chunk 10461 was not erased
**>> yaffs chunk 10462 was not erased
**>> yaffs chunk 10463 was not erased
**>> yaffs chunk 10464 was not erased
**>> yaffs chunk 10465 was not erased
**>> yaffs chunk 10466 was not erased
**>> yaffs chunk 10467 was not erased
**>> yaffs chunk 10468 was not erased
**>> yaffs chunk 10469 was not erased
**>> yaffs chunk 10470 was not erased
**>> yaffs chunk 10471 was not erased
**>> yaffs chunk 10472 was not erased
**>> yaffs chunk 10473 was not erased
**>> yaffs chunk 10474 was not erased
**>> yaffs chunk 10475 was not erased
**>> yaffs chunk 10476 was not erased
**>> yaffs chunk 10477 was not erased
**>> yaffs chunk 10478 was not erased
**>> yaffs chunk 10479 was not erased
**>> yaffs chunk 10480 was not erased
**>> yaffs chunk 10481 was not erased
**>> yaffs chunk 10482 was not erased
**>> yaffs chunk 10483 was not erased
**>> yaffs chunk 10484 was not erased
**>> yaffs chunk 10485 was not erased
**>> yaffs chunk 10486 was not erased
**>> yaffs chunk 10487 was not erased
**>> yaffs chunk 10488 was not erased
**>> yaffs chunk 10489 was not erased
**>> yaffs chunk 10490 was not erased
**>> yaffs chunk 10491 was not erased
**>> yaffs chunk 10492 was not erased
**>> yaffs chunk 10493 was not erased
**>> yaffs chunk 10494 was not erased
**>> yaffs chunk 10495 was not erased
**>> yaffs chunk 10496 was not erased
**>> yaffs chunk 10560 was not erased
**>> yaffs chunk 10624 was not erased
**>> yaffs chunk 10625 was not erased
**>> yaffs chunk 10626 was not erased
**>> yaffs chunk 10627 was not erased
**>> yaffs chunk 10628 was not erased
**>> yaffs chunk 10629 was not erased
**>> yaffs chunk 10630 was not erased
**>> yaffs chunk 10631 was not erased
**>> yaffs chunk 10632 was not erased
**>> yaffs chunk 10633 was not erased
**>> yaffs chunk 10634 was not erased
**>> yaffs chunk 10635 was not erased
**>> yaffs chunk 10636 was not erased
**>> yaffs chunk 10637 was not erased
**>> yaffs chunk 10638 was not erased
**>> yaffs chunk 10639 was not erased
**>> yaffs chunk 10640 was not erased
**>> yaffs chunk 10641 was not erased
**>> yaffs chunk 10642 was not erased
**>> yaffs chunk 10643 was not erased
**>> yaffs chunk 10644 was not erased
**>> yaffs chunk 10645 was not erased
**>> yaffs chunk 10646 was not erased
**>> yaffs chunk 10647 was not erased
**>> yaffs chunk 10648 was not erased
**>> yaffs chunk 10649 was not erased
**>> yaffs chunk 10650 was not erased
**>> yaffs chunk 10651 was not erased
**>> yaffs chunk 10652 was not erased
**>> yaffs chunk 10653 was not erased
**>> yaffs chunk 10654 was not erased
**>> yaffs chunk 10655 was not erased
**>> yaffs chunk 10656 was not erased
**>> yaffs chunk 10657 was not erased
**>> yaffs chunk 10658 was not erased
**>> yaffs chunk 10659 was not erased
**>> yaffs chunk 10660 was not erased
**>> yaffs chunk 10661 was not erased
**>> yaffs chunk 10662 was not erased
**>> yaffs chunk 10663 was not erased
**>> yaffs chunk 10664 was not erased
**>> yaffs chunk 10665 was not erased
**>> yaffs chunk 10666 was not erased
**>> yaffs chunk 10667 was not erased
**>> yaffs chunk 10668 was not erased
**>> yaffs chunk 10669 was not erased
**>> yaffs chunk 10670 was not erased
**>> yaffs chunk 10671 was not erased
**>> yaffs chunk 10672 was not erased
**>> yaffs chunk 10673 was not erased
**>> yaffs chunk 10674 was not erased
**>> yaffs chunk 10675 was not erased
**>> yaffs chunk 10676 was not erased
**>> yaffs chunk 10677 was not erased
**>> yaffs chunk 10678 was not erased
**>> yaffs chunk 10679 was not erased
**>> yaffs chunk 10680 was not erased
**>> yaffs chunk 10681 was not erased
**>> yaffs chunk 10682 was not erased
**>> yaffs chunk 10683 was not erased
**>> yaffs chunk 10684 was not erased
**>> yaffs chunk 10685 was not erased
**>> yaffs chunk 10686 was not erased
**>> yaffs chunk 10687 was not erased
**>> yaffs chunk 10688 was not erased
**>> yaffs chunk 10752 was not erased
**>> yaffs chunk 10816 was not erased
**>> yaffs chunk 10880 was not erased
**>> yaffs chunk 10944 was not erased
**>> yaffs chunk 10945 was not erased
**>> yaffs chunk 10946 was not erased
**>> yaffs chunk 10947 was not erased
**>> yaffs chunk 10948 was not erased
**>> yaffs chunk 10949 was not erased
**>> yaffs chunk 10950 was not erased
**>> yaffs chunk 10951 was not erased
**>> yaffs chunk 10952 was not erased
**>> yaffs chunk 10953 was not erased
**>> yaffs chunk 10954 was not erased
**>> yaffs chunk 10955 was not erased
**>> yaffs chunk 10956 was not erased
**>> yaffs chunk 10957 was not erased
**>> yaffs chunk 10958 was not erased
**>> yaffs chunk 10959 was not erased
**>> yaffs chunk 10960 was not erased
**>> yaffs chunk 10961 was not erased
**>> yaffs chunk 10962 was not erased
**>> yaffs chunk 10963 was not erased
**>> yaffs chunk 10964 was not erased
**>> yaffs chunk 10965 was not erased
**>> yaffs chunk 10966 was not erased
**>> yaffs chunk 10967 was not erased
**>> yaffs chunk 10968 was not erased
**>> yaffs chunk 10969 was not erased
**>> yaffs chunk 10970 was not erased
**>> yaffs chunk 10971 was not erased
**>> yaffs chunk 10972 was not erased
**>> yaffs write required 164 attempts
page 10496 in gc has no object: 165 1 2048
nand_erase: attempt to erase a bad block at page 0x00013240
------retval -5<4>**>> Erasure failed 164
**>> Block 164 retired
Block 164 is in state 9 after gc, should be erased
page 10560 in gc has no object: 166 65 2048
nand_erase: attempt to erase a bad block at page 0x00013280
------retval -5<4>**>> Erasure failed 165
**>> Block 165 retired
Block 165 is in state 9 after gc, should be erased
page 10688 in gc has no object: 168 1 2048
nand_erase: attempt to erase a bad block at page 0x00013300
------retval -5<4>**>> Erasure failed 167
**>> Block 167 retired
Block 167 is in state 9 after gc, should be erased
page 10752 in gc has no object: 169 65 2048
nand_erase: attempt to erase a bad block at page 0x00013340
------retval -5<4>**>> Erasure failed 168
**>> Block 168 retired
Block 168 is in state 9 after gc, should be erased
page 10816 in gc has no object: 136 1 2048
nand_erase: attempt to erase a bad block at page 0x00013380
------retval -5<4>**>> Erasure failed 169
**>> Block 169 retired
Block 169 is in state 9 after gc, should be erased
Setting nameservpage 10880 in gc has no object: 171 65 2048
er to 192.168.1.nand_erase: attempt to erase a bad block at page 0x000133c0
1 in /etc/resolv------retval -5.conf:
<4>**>> Erasure failed 170
**>> Block 170 retired
Block 170 is in state 9 after gc, should be erased
Starting inetd:
Starting the dropbear ssh server:
Setting RS485 Mode
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
S600CPUBoardRev2.1 login: PHY: e0024520:19 - Link is Up - 100/Full
root
Password:
login[889]: root login on `console'
~ #
~ #
~ #
~ #
~ #
~ #
[-- Attachment #3: boot-up_with_RFS_createdby_mkyffs2image_tool.txt --]
[-- Type: text/plain, Size: 19833 bytes --]
Resetting the board.
U-Boot 1.3.0-S600-Ver1.0 (Jul 16 2009 - 00:03:56) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, Rev: Unknown revision number:80b10021
Warning: Unsupported cpu revision!
Board: S600 CPU BOARD
I2C: ready
DRAM: 128 MB
FLASH: 16 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
Hit any key to stop autoboot: 6 \b\b\b 5 \b\b\b 4 \b\b\b 3 \b\b\b 2 \b\b\b 1 \b\b\b 0
Speed: 100, full duplex
Using TSEC1 device
TFTP from server 192.168.6.251; our IP address is 192.168.34.10; sending through gateway 192.168.32.47
Filename 'uImage_yaffs2'.
Load address: 0x200000
Loading: *\b#################################################################
#################################################
done
Bytes transferred = 1669252 (197884 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-S600-Ver1.0
Created: 2009-07-16 2:03:41 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1669188 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xfe900000
Loading Device Tree to 007fd000, end 007fef4f ... OK
Using MPC8313 RDB machine description
Linux version 2.6.23-S600-Ver1.0 (root@leapfrogserver) (gcc version 4.1.2) #71 Thu Jul 16 07:33:39 IST 2009
console [udbg0] enabled
setup_arch: bootmem
mpc8313_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/mtdblock11 rootfstype=yaffs2 rw console=ttyS0,115200
IPIC (128 IRQ sources) at fdef9700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126220k/131072k available (3288k kernel code, 4712k reserved, 148k data, 96k bss, 152k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
yaffs Jul 16 2009 04:53:10 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
device node obtained!
sram_irq = 48
Sram driver inserted
Serial: 8250/16550 driver $Revision: 1.90 $ 14 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 18) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 21) is a 16550A
serial8250.0: ttyS2 at MMIO 0xfa000000 (irq = 22) is a ST16654
serial8250.0: ttyS3 at MMIO 0xfa000008 (irq = 22) is a ST16654
serial8250.0: ttyS4 at MMIO 0xfa000010 (irq = 22) is a ST16654
serial8250.0: ttyS5 at MMIO 0xfa000018 (irq = 22) is a ST16654
serial8250.0: ttyS6 at MMIO 0xfa000020 (irq = 22) is a ST16654
serial8250.0: ttyS7 at MMIO 0xfa000028 (irq = 22) is a ST16654
serial8250.0: ttyS8 at MMIO 0xfa000030 (irq = 22) is a ST16654
serial8250.0: ttyS9 at MMIO 0xfa000038 (irq = 22) is a ST16654
serial8250.0: ttyS10 at MMIO 0xfa000040 (irq = 23) is a ST16654
serial8250.0: ttyS11 at MMIO 0xfa000048 (irq = 23) is a ST16654
serial8250.0: ttyS12 at MMIO 0xfa000050 (irq = 23) is a ST16654
serial8250.0: ttyS13 at MMIO 0xfa000058 (irq = 23) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:01
GFAR: SKB Handler initialized at CPU#0(max=32)
eth0: MTU = 1500 (frame size=1526, truesize=1800)
eth0: Running with NAPI enabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.3-skbr, 00:e0:0c:00:95:02
GFAR: SKB Handler initialized at CPU#0(max=32)
eth1: MTU = 1500 (frame size=1526, truesize=1800)
eth1: Running with NAPI enabled
eth1: 64/64 RX/TX BD ring size
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Marvell 88E1101: Registered new driver
Marvell 88E1112: Registered new driver
Marvell 88E1111: Registered new driver
Marvell 88E1145: Registered new driver
Fixed MDIO Bus: probed
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
nor: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
nor: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
physmap-flash nor: Using OF partition information
Creating 6 MTD partitions on "nor":
0x00000000-0x00100000 : "U-Boot"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x01000000 : "Unused"
Freescale eLBC NAND Driver (C) 2006-2007 Freescale
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 80 at 0x00a00000
Bad eraseblock 81 at 0x00a20000
Bad eraseblock 1062 at 0x084c0000
Bad eraseblock 1063 at 0x084e0000
Bad eraseblock 1064 at 0x08500000
Bad eraseblock 1065 at 0x08520000
Bad eraseblock 1066 at 0x08540000
Bad eraseblock 1067 at 0x08560000
Bad eraseblock 1068 at 0x08580000
Bad eraseblock 1069 at 0x085a0000
Bad eraseblock 1070 at 0x085c0000
Bad eraseblock 1071 at 0x085e0000
Bad eraseblock 1072 at 0x08600000
Bad eraseblock 1073 at 0x08620000
Bad eraseblock 1074 at 0x08640000
Bad eraseblock 1075 at 0x08660000
Bad eraseblock 1076 at 0x08680000
Bad eraseblock 1077 at 0x086a0000
Bad eraseblock 1078 at 0x086c0000
Bad eraseblock 1079 at 0x086e0000
Bad eraseblock 1080 at 0x08700000
Bad eraseblock 1081 at 0x08720000
Bad eraseblock 1082 at 0x08740000
Bad eraseblock 1083 at 0x08760000
Bad eraseblock 1084 at 0x08780000
Bad eraseblock 1085 at 0x087a0000
Bad eraseblock 1086 at 0x087c0000
Bad eraseblock 1087 at 0x087e0000
Bad eraseblock 1088 at 0x08800000
Bad eraseblock 1089 at 0x08820000
Bad eraseblock 1090 at 0x08840000
Bad eraseblock 1091 at 0x08860000
Bad eraseblock 1092 at 0x08880000
Bad eraseblock 1093 at 0x088a0000
Bad eraseblock 1094 at 0x088c0000
Bad eraseblock 1095 at 0x088e0000
Bad eraseblock 1096 at 0x08900000
Bad eraseblock 1097 at 0x08920000
Bad eraseblock 1098 at 0x08940000
Bad eraseblock 1099 at 0x08960000
Bad eraseblock 1100 at 0x08980000
Bad eraseblock 1101 at 0x089a0000
Bad eraseblock 1102 at 0x089c0000
Bad eraseblock 1103 at 0x089e0000
Bad eraseblock 1104 at 0x08a00000
Bad eraseblock 1105 at 0x08a20000
Bad eraseblock 1106 at 0x08a40000
Bad eraseblock 1107 at 0x08a60000
Bad eraseblock 1108 at 0x08a80000
Bad eraseblock 1109 at 0x08aa0000
Bad eraseblock 1110 at 0x08ac0000
Bad eraseblock 1111 at 0x08ae0000
Bad eraseblock 1112 at 0x08b00000
Bad eraseblock 1113 at 0x08b20000
Bad eraseblock 1114 at 0x08b40000
Bad eraseblock 1115 at 0x08b60000
Bad eraseblock 1116 at 0x08b80000
Bad eraseblock 1117 at 0x08ba0000
Bad eraseblock 1118 at 0x08bc0000
Bad eraseblock 1119 at 0x08be0000
Bad eraseblock 1120 at 0x08c00000
Bad eraseblock 1121 at 0x08c20000
Bad eraseblock 1122 at 0x08c40000
Bad eraseblock 1123 at 0x08c60000
Bad eraseblock 1124 at 0x08c80000
Bad eraseblock 1125 at 0x08ca0000
Bad eraseblock 1126 at 0x08cc0000
Bad eraseblock 1127 at 0x08ce0000
Bad eraseblock 1128 at 0x08d00000
Bad eraseblock 1129 at 0x08d20000
Bad eraseblock 1130 at 0x08d40000
Bad eraseblock 1131 at 0x08d60000
Bad eraseblock 1132 at 0x08d80000
Bad eraseblock 1133 at 0x08da0000
Bad eraseblock 1134 at 0x08dc0000
Bad eraseblock 1135 at 0x08de0000
Bad eraseblock 1136 at 0x08e00000
Bad eraseblock 1137 at 0x08e20000
Bad eraseblock 1138 at 0x08e40000
Bad eraseblock 1139 at 0x08e60000
Bad eraseblock 1140 at 0x08e80000
Bad eraseblock 1141 at 0x08ea0000
Bad eraseblock 1142 at 0x08ec0000
Bad eraseblock 1143 at 0x08ee0000
Bad eraseblock 1144 at 0x08f00000
Bad eraseblock 1145 at 0x08f20000
Bad eraseblock 1146 at 0x08f40000
Bad eraseblock 1147 at 0x08f60000
Bad eraseblock 1148 at 0x08f80000
Bad eraseblock 1149 at 0x08fa0000
Bad eraseblock 1150 at 0x08fc0000
Bad eraseblock 1151 at 0x08fe0000
Bad eraseblock 1152 at 0x09000000
Bad eraseblock 1153 at 0x09020000
Bad eraseblock 1154 at 0x09040000
Bad eraseblock 1155 at 0x09060000
Bad eraseblock 1156 at 0x09080000
Bad eraseblock 1157 at 0x090a0000
Bad eraseblock 1158 at 0x090c0000
Bad eraseblock 1159 at 0x090e0000
Bad eraseblock 1160 at 0x09100000
Bad eraseblock 1161 at 0x09120000
Bad eraseblock 1162 at 0x09140000
Bad eraseblock 1163 at 0x09160000
Bad eraseblock 1164 at 0x09180000
Bad eraseblock 1165 at 0x091a0000
Bad eraseblock 1166 at 0x091c0000
Bad eraseblock 1167 at 0x091e0000
Bad eraseblock 1168 at 0x09200000
Bad eraseblock 1169 at 0x09220000
Bad eraseblock 1170 at 0x09240000
Bad eraseblock 1171 at 0x09260000
Bad eraseblock 1172 at 0x09280000
Bad eraseblock 1173 at 0x092a0000
Bad eraseblock 1174 at 0x092c0000
Bad eraseblock 1175 at 0x092e0000
Bad eraseblock 1176 at 0x09300000
Bad eraseblock 1177 at 0x09320000
Bad eraseblock 1178 at 0x09340000
Bad eraseblock 1179 at 0x09360000
Bad eraseblock 1180 at 0x09380000
Bad eraseblock 1181 at 0x093a0000
Bad eraseblock 1182 at 0x093c0000
Bad eraseblock 1183 at 0x093e0000
Bad eraseblock 1184 at 0x09400000
Bad eraseblock 1185 at 0x09420000
Bad eraseblock 1186 at 0x09440000
Bad eraseblock 1187 at 0x09460000
Bad eraseblock 1188 at 0x09480000
Bad eraseblock 1189 at 0x094a0000
Bad eraseblock 1190 at 0x094c0000
Bad eraseblock 1191 at 0x094e0000
Bad eraseblock 1192 at 0x09500000
Bad eraseblock 1193 at 0x09520000
Bad eraseblock 1194 at 0x09540000
Bad eraseblock 1195 at 0x09560000
Bad eraseblock 1196 at 0x09580000
Bad eraseblock 1197 at 0x095a0000
Bad eraseblock 1198 at 0x095c0000
Bad eraseblock 1199 at 0x095e0000
Bad eraseblock 1200 at 0x09600000
Bad eraseblock 1201 at 0x09620000
Bad eraseblock 1202 at 0x09640000
Bad eraseblock 1203 at 0x09660000
Bad eraseblock 1204 at 0x09680000
Bad eraseblock 1205 at 0x096a0000
Bad eraseblock 1206 at 0x096c0000
Bad eraseblock 1207 at 0x096e0000
Bad eraseblock 1208 at 0x09700000
Bad eraseblock 1209 at 0x09720000
Bad eraseblock 1210 at 0x09740000
Bad eraseblock 1211 at 0x09760000
Bad eraseblock 1212 at 0x09780000
Bad eraseblock 1213 at 0x097a0000
Bad eraseblock 1214 at 0x097c0000
Bad eraseblock 1215 at 0x097e0000
Bad eraseblock 1216 at 0x09800000
Bad eraseblock 1217 at 0x09820000
Bad eraseblock 1218 at 0x09840000
Bad eraseblock 1219 at 0x09860000
Bad eraseblock 1220 at 0x09880000
Bad eraseblock 1221 at 0x098a0000
Bad eraseblock 1222 at 0x098c0000
Bad eraseblock 1223 at 0x098e0000
Bad eraseblock 1224 at 0x09900000
Bad eraseblock 1225 at 0x09920000
Bad eraseblock 1226 at 0x09940000
Bad eraseblock 1227 at 0x09960000
Bad eraseblock 1228 at 0x09980000
Bad eraseblock 1229 at 0x099a0000
Bad eraseblock 1230 at 0x099c0000
Bad eraseblock 1231 at 0x099e0000
Bad eraseblock 1232 at 0x09a00000
Bad eraseblock 1233 at 0x09a20000
Bad eraseblock 1234 at 0x09a40000
Bad eraseblock 1235 at 0x09a60000
Bad eraseblock 1236 at 0x09a80000
Bad eraseblock 1237 at 0x09aa0000
Bad eraseblock 1238 at 0x09ac0000
Bad eraseblock 1239 at 0x09ae0000
Bad eraseblock 1240 at 0x09b00000
Bad eraseblock 1241 at 0x09b20000
Bad eraseblock 1242 at 0x09b40000
Bad eraseblock 1243 at 0x09b60000
Bad eraseblock 1244 at 0x09b80000
Bad eraseblock 1245 at 0x09ba0000
Bad eraseblock 1246 at 0x09bc0000
Bad eraseblock 1247 at 0x09be0000
Bad eraseblock 1248 at 0x09c00000
Bad eraseblock 1249 at 0x09c20000
Bad eraseblock 1250 at 0x09c40000
Bad eraseblock 1251 at 0x09c60000
Bad eraseblock 1252 at 0x09c80000
Bad eraseblock 1253 at 0x09ca0000
Bad eraseblock 1254 at 0x09cc0000
Bad eraseblock 1255 at 0x09ce0000
Bad eraseblock 1256 at 0x09d00000
Bad eraseblock 1257 at 0x09d20000
Bad eraseblock 1258 at 0x09d40000
Bad eraseblock 1259 at 0x09d60000
Bad eraseblock 1260 at 0x09d80000
Bad eraseblock 1261 at 0x09da0000
Bad eraseblock 1262 at 0x09dc0000
Bad eraseblock 1263 at 0x09de0000
Bad eraseblock 1264 at 0x09e00000
Bad eraseblock 1265 at 0x09e20000
Bad eraseblock 1266 at 0x09e40000
Bad eraseblock 1267 at 0x09e60000
Bad eraseblock 1268 at 0x09e80000
Bad eraseblock 1269 at 0x09ea0000
Bad eraseblock 1270 at 0x09ec0000
Bad eraseblock 1271 at 0x09ee0000
Bad eraseblock 1272 at 0x09f00000
Bad eraseblock 1273 at 0x09f20000
Bad eraseblock 1274 at 0x09f40000
Bad eraseblock 1275 at 0x09f60000
Bad eraseblock 1276 at 0x09f80000
Bad eraseblock 1277 at 0x09fa0000
Bad eraseblock 1278 at 0x09fc0000
Bad eraseblock 1279 at 0x09fe0000
Bad eraseblock 1280 at 0x0a000000
Bad eraseblock 1281 at 0x0a020000
Bad eraseblock 1282 at 0x0a040000
Bad eraseblock 1283 at 0x0a060000
Bad eraseblock 1284 at 0x0a080000
Bad eraseblock 1285 at 0x0a0a0000
Bad eraseblock 1286 at 0x0a0c0000
Bad eraseblock 1287 at 0x0a0e0000
Bad eraseblock 1288 at 0x0a100000
Bad eraseblock 1289 at 0x0a120000
Bad eraseblock 1290 at 0x0a140000
Bad eraseblock 1291 at 0x0a160000
Bad eraseblock 1292 at 0x0a180000
Bad eraseblock 1293 at 0x0a1a0000
Bad eraseblock 1294 at 0x0a1c0000
Bad eraseblock 1295 at 0x0a1e0000
Bad eraseblock 1296 at 0x0a200000
Bad eraseblock 1297 at 0x0a220000
Bad eraseblock 1298 at 0x0a240000
Bad eraseblock 1299 at 0x0a260000
Bad eraseblock 1300 at 0x0a280000
Bad eraseblock 1301 at 0x0a2a0000
Bad eraseblock 1302 at 0x0a2c0000
Bad eraseblock 1303 at 0x0a2e0000
Bad eraseblock 1304 at 0x0a300000
Bad eraseblock 1305 at 0x0a320000
Bad eraseblock 1306 at 0x0a340000
Bad eraseblock 1307 at 0x0a360000
Bad eraseblock 1308 at 0x0a380000
Bad eraseblock 1309 at 0x0a3a0000
Bad eraseblock 1310 at 0x0a3c0000
Bad eraseblock 1311 at 0x0a3e0000
Bad eraseblock 1312 at 0x0a400000
Bad eraseblock 1313 at 0x0a420000
Bad eraseblock 1314 at 0x0a440000
Bad eraseblock 1315 at 0x0a460000
Bad eraseblock 1316 at 0x0a480000
Bad eraseblock 1317 at 0x0a4a0000
Bad eraseblock 1318 at 0x0a4c0000
Bad eraseblock 1319 at 0x0a4e0000
Bad eraseblock 1320 at 0x0a500000
Bad eraseblock 1321 at 0x0a520000
Bad eraseblock 1322 at 0x0a540000
Bad eraseblock 1323 at 0x0a560000
Bad eraseblock 1324 at 0x0a580000
Bad eraseblock 1325 at 0x0a5a0000
Bad eraseblock 1326 at 0x0a5c0000
Bad eraseblock 1327 at 0x0a5e0000
Bad eraseblock 1328 at 0x0a600000
Bad eraseblock 1329 at 0x0a620000
Bad eraseblock 1330 at 0x0a640000
Bad eraseblock 1331 at 0x0a660000
Bad eraseblock 1332 at 0x0a680000
Bad eraseblock 1333 at 0x0a6a0000
Bad eraseblock 1334 at 0x0a6c0000
Bad eraseblock 1335 at 0x0a6e0000
Bad eraseblock 1336 at 0x0a700000
Bad eraseblock 1337 at 0x0a720000
Bad eraseblock 1338 at 0x0a740000
Bad eraseblock 1339 at 0x0a760000
Bad eraseblock 1340 at 0x0a780000
Bad eraseblock 1341 at 0x0a7a0000
Bad eraseblock 1342 at 0x0a7c0000
Bad eraseblock 1343 at 0x0a7e0000
Bad eraseblock 1344 at 0x0a800000
Bad eraseblock 1345 at 0x0a820000
Bad eraseblock 1346 at 0x0a840000
Bad eraseblock 1347 at 0x0a860000
Bad eraseblock 1348 at 0x0a880000
Bad eraseblock 1349 at 0x0a8a0000
Bad eraseblock 1350 at 0x0a8c0000
Bad eraseblock 1351 at 0x0a8e0000
Bad eraseblock 1352 at 0x0a900000
Bad eraseblock 1353 at 0x0a920000
Bad eraseblock 1354 at 0x0a940000
Bad eraseblock 1355 at 0x0a960000
Bad eraseblock 1356 at 0x0a980000
Bad eraseblock 1357 at 0x0a9a0000
Bad eraseblock 1358 at 0x0a9c0000
Bad eraseblock 1359 at 0x0a9e0000
Bad eraseblock 1360 at 0x0aa00000
Bad eraseblock 1361 at 0x0aa20000
Bad eraseblock 1362 at 0x0aa40000
Bad eraseblock 1363 at 0x0aa60000
Bad eraseblock 1364 at 0x0aa80000
Bad eraseblock 1365 at 0x0aaa0000
Bad eraseblock 1366 at 0x0aac0000
Bad eraseblock 1367 at 0x0aae0000
Bad eraseblock 1368 at 0x0ab00000
Bad eraseblock 1369 at 0x0ab20000
Bad eraseblock 1370 at 0x0ab40000
Bad eraseblock 1371 at 0x0ab60000
Bad eraseblock 1372 at 0x0ab80000
Bad eraseblock 1373 at 0x0aba0000
Bad eraseblock 1374 at 0x0abc0000
Bad eraseblock 1375 at 0x0abe0000
Bad eraseblock 1376 at 0x0ac00000
Bad eraseblock 1377 at 0x0ac20000
Bad eraseblock 1378 at 0x0ac40000
Bad eraseblock 1379 at 0x0ac60000
Bad eraseblock 1380 at 0x0ac80000
Bad eraseblock 1381 at 0x0aca0000
Bad eraseblock 1382 at 0x0acc0000
Bad eraseblock 1383 at 0x0ace0000
Bad eraseblock 1384 at 0x0ad00000
Bad eraseblock 1385 at 0x0ad20000
Bad eraseblock 1386 at 0x0ad40000
Bad eraseblock 1387 at 0x0ad60000
Bad eraseblock 1388 at 0x0ad80000
Bad eraseblock 1389 at 0x0ada0000
Bad eraseblock 1390 at 0x0adc0000
Bad eraseblock 1391 at 0x0ade0000
Bad eraseblock 1392 at 0x0ae00000
Bad eraseblock 1393 at 0x0ae20000
Bad eraseblock 1394 at 0x0ae40000
Bad eraseblock 1395 at 0x0ae60000
Bad eraseblock 1396 at 0x0ae80000
Bad eraseblock 1397 at 0x0aea0000
Bad eraseblock 1398 at 0x0aec0000
Bad eraseblock 1399 at 0x0aee0000
Bad eraseblock 1400 at 0x0af00000
Bad eraseblock 1401 at 0x0af20000
Bad eraseblock 1402 at 0x0af40000
Bad eraseblock 1403 at 0x0af60000
fsl-elbc fsl-elbc.0: Using OF partition information
Creating 7 MTD partitions on "nand":
0x00000000-0x00100000 : "U-Boot-NAND"
0x00100000-0x00500000 : "Kernel1"
0x00500000-0x00900000 : "Kernel2"
0x00900000-0x00980000 : "DTB1"
0x00980000-0x00a00000 : "DTB2"
0x00a00000-0x08500000 : "RFS1"
0x084c0000-0x0ffc0000 : "RFS2"
mpc83xx_spi.0: MPC83xx SPI Controller driver at 0xc907e000 (irq = 24)
usbmon: debugfs is not available
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
CMD REG : 10009
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (25 seconds)
mmc_spi spi28672.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
rtc-ds1307 0-0068: setting the system clock to 2009-07-16 04:53:18 (1247719998)
yaffs: dev is 32505867 name is "mtdblock11"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.11, "mtdblock11"
block 1 is bad
block 2 is bad
block 983 is bad
block 984 is bad
yaffs_read_super: isCheckpointed 0
VFS: Mounted root (yaffs2 filesystem).
Freeing unused kernel memory: 152k init
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Rebooting in 180 seconds..
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Michael Ellerman @ 2009-07-16 7:43 UTC (permalink / raw)
To: catalin.marinas; +Cc: linuxppc-dev
In-Reply-To: <f18967360113efe4354a9ad0d71ead9a0f7579ea.1247707485.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> Very lightly tested, doesn't crash the kernel.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> It doesn't look like we actually need to add any support in the
> arch code - or is there something I'm missing?
Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
our low-level pre-bootmem allocator.
And we have the same problem with _edata as x86.
And I'm seeing lots (~250) of these:
unreferenced object 0xc0000000fcd2e2f0 (size 16):
comm "swapper", pid 1, jiffies 4294892393
backtrace:
[<c00000000014d9c0>] .create_object+0x164/0x2a8
[<c00000000014dc94>] .kmemleak_alloc+0x74/0x120
[<c0000000001474d0>] .__kmalloc+0x20c/0x2ac
[<c00000000036998c>] .kvasprintf+0x64/0xb0
[<c000000000360558>] .kobject_set_name_vargs+0x44/0xb4
[<c0000000003f06d0>] .dev_set_name+0x50/0x6c
[<c00000000042a794>] .scsi_sysfs_device_initialize+0xd0/0x16c
[<c000000000426600>] .scsi_alloc_sdev+0x1c4/0x284
[<c000000000426b50>] .scsi_probe_and_add_lun+0x144/0xbd4
[<c0000000004279bc>] .__scsi_scan_target+0xfc/0x658
[<c000000000427f90>] .scsi_scan_channel+0x78/0xe8
[<c0000000004280cc>] .scsi_scan_host_selected+0xcc/0x154
[<c00000000042823c>] .do_scsi_scan_host+0xe8/0x10c
[<c0000000004286ec>] .scsi_scan_host+0x250/0x294
[<c000000000456ef8>] .ibmvscsi_probe+0x4f8/0x630
[<c000000000027418>] .vio_bus_probe+0x360/0x3cc
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-07-16 8:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a couple of fixes for powerpc for 2.6.31.
The following changes since commit e9e961c9a818a2f24711af493b907a8e40a69efc:
Linus Torvalds (1):
Merge branch 'i2c-for-2631-rc3' of git://aeryn.fluff.org.uk/bjdooks/linux
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Andreas Schwab (1):
powerpc: Fix another bug in move of altivec code to vector.S
Dave Kleikamp (1):
powerpc: Fix booke user_disable_single_step()
arch/powerpc/kernel/ptrace.c | 17 +++++++++--------
arch/powerpc/kernel/vector.S | 6 +++---
2 files changed, 12 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Josh Boyer @ 2009-07-16 11:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: catalin.marinas, linuxppc-dev
In-Reply-To: <1247730230.18228.5.camel@concordia>
On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote:
>On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
>> Very lightly tested, doesn't crash the kernel.
>>
>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>> ---
>>
>> It doesn't look like we actually need to add any support in the
>> arch code - or is there something I'm missing?
>
>Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
>our low-level pre-bootmem allocator.
>
>And we have the same problem with _edata as x86.
I'll point out that the Fedora developers enabled this in the rawhide kernels
for 3 days, and then turned it back off because most of the things found were
false positives.
Might still be worth poking at, but until it gets a bit less buggy itself it
could be a timesink.
josh
^ permalink raw reply
* Linux with RAM mapped other than zero.
From: Sumesh Kaana @ 2009-07-16 12:08 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
Hi all, I've a system design (32 bit) with SDRAM mapped at 0xf8000000 rather than at 0. what are the changes i should make to successfully boot a kernel..? my design with SDRAM at 0 (64MB) is working fine with xilinx git line kernel(2.6.27). i was using 'make simpleImage.xilinx (where xilinx.dts is my device tree file) i tried to change the link_address in arch/powerpc/boot/wrapper from 0x400000 to 0xf4000000. when i analysed the dump with step mode in xmd, it fails in platform_init()function in arch/powerpc/boot/simpleboot.c may be at /* Only interested in memory based at 0 */
for (i = 0; i < *na; i++)
if (*reg++ != 0)
fatal("Memory range is not based at address 0\n"); can anyone tell what are the changes i shoud do if my memory ranges from 0xf8000000 to 0xfbffffff..? (64MB)
is it possible to change the physical address of kernel from 0 to any other location..? is the option provided in menuconfig..? or in any linker script..?
Thanks in advance,Sumesh.
_________________________________________________________________
Looking for a new car this winter? Let us help with car news, reviews and more
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
[-- Attachment #2: Type: text/html, Size: 5713 bytes --]
^ permalink raw reply
* riscwatch shows up core status UNKNOWN for 970mp ppc processor
From: anil kumar @ 2009-07-16 12:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]
Hello
I am newbie to RISCWatch and debugging using JTAG interface .I want to debug
Linux Kernel on target board
using jtag interface provided on board.
To debug 970MP dual core ppc processor on traget board, I installed
RISCWatch software on my window host.
My Setup:
----------
Host <--(over ethernet)--> RISCWatch 13H6423 <--(jtag interface)--> 970MP
Processor
I am able to detect two core on target 970MP processor but it shows both
cores as `UNKNOWN` . I have no idea,
why riscwatch shows up status of both cores as UNKNOWN?
I would like to mention:
-------------------------
1) After attaching JTAG cable & switching on riscwatch box, powered cycle
was done on the target board
and restart RISCWatch. But still core status is shown `UNKNOWN`
2) For PVR value 0x00440101, I used `REV = 1' in rwppc.env file. Correct us
if I am wrong.
3) I am able to ping RISCWatch 13H6423 from host system.
4) When I reset target board, target status changes from "UNKNOWN to HALTED"
and "HALTED to UNKNOWN"
I noticed that PVR register value is 0x00440101. I am not sure if this
confirms that revision of the processor(970mp) is 1.
Please find the rwppc.env file (C:\Program Files\RISCWatch\rwppc.env) that I
configured:
------------------------------
----------------------------------------------------------
PROC = 970MP
REV = 1
TARGET_TYPE = jtag_eth
TARGET_NAME = 192.168.10.5
RWPPC_DIR = .
SEARCH_PATH = .
LOG_FILE_DIR = .
SAVE_LAYOUT = no
PRD_FILE = rwppc.prd
Please find board information:
------------------------------
KAT2000 970MP (1.0)=> boardinfo
board config data version: 1.0
processor name : 970MP
processor PVR value : 0x00440101
timer clock frequency : 112500000
total SDRAM memory : 4096MB
SDRAM frequency : 533333333
system clk frequency (Hz): 225000000
CPU frequency : 1800000000
CPU frequency ind. est. : 1800001200
CPU to EI speed ratio : 2:1
frequency scaling divider: 1
serial clk frequency : 1843200
HID0 value : 0011008180000000
HID1 value : fd3c200000000000
HID4 value : 0000001000000000
HID5 value : 0000000000000080
SDR1 value : 0000000000d00002
PIR value : 00000000
Ethernet hardware addr 0 : FFFFFFFFFFFF
RISCWatch log:
--------------
12:37:18 - RISCWatch program start
12:37:18 - RISCWatch v7.1 for Windows XP
12:37:18 - Current directory: C:\Program Files\RISCWatch
12:37:18 - Environment file: RWPPC.ENV
12:37:18 - RWPPC_DIR = .
12:37:18 - TARGET_TYPE = JTAG_Ethernet
12:37:18 - TARGET_NAME = 192.168.10.5
12:37:18 - Requested Processor 970MPRev1:CORE1
12:37:18 - Requested Processor 970MPRev1:CORE2
12:37:18 - Unable to get port number for jtag_eth service, using 6470
default 12:37:30 - Configuring probe 12:37:30 - cf default; jtagch a32,a32
12:37:31 - HPE8130A Series Emulation System
12:37:31 - Version: A.01.20 04Apr02 Unreleased
12:37:31 - Location: Generics
12:37:31 - HPEGPUL PowerPC 970 JTAG Emulator
12:37:31 - Version: A.00.I0 22Jul08 13:48 Proto
12:37:31 - WARNING : Could not read processor status, slowing JTAG clock
and retrying
12:37:31 - ERROR : bad status received, see README for possible causes
12:37:36 - Starting MPS mode
12:43:18 - STATUS : CORE1 status changed from UNKNOWN to HALTED
12:43:18 - STATUS : CORE2 status changed from UNKNOWN to HALTED
Note---> Status become HALTED because I reset target board
12:43:19 - ERROR : CORE1 status changed from HALTED to UNKNOWN
12:43:19 - ERROR : CORE2 status changed from HALTED to UNKNOWN
Thanks in advance.
Regards,
Anil
[-- Attachment #2: Type: text/html, Size: 4143 bytes --]
^ permalink raw reply
* Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
From: Catalin Marinas @ 2009-07-16 13:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090716113100.GB7102@zod.rchland.ibm.com>
On Thu, 2009-07-16 at 07:31 -0400, Josh Boyer wrote:
> On Thu, Jul 16, 2009 at 05:43:50PM +1000, Michael Ellerman wrote:
> >On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> >> Very lightly tested, doesn't crash the kernel.
> >>
> >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> >> ---
> >>
> >> It doesn't look like we actually need to add any support in the
> >> arch code - or is there something I'm missing?
> >
> >Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
> >our low-level pre-bootmem allocator.
> >
> >And we have the same problem with _edata as x86.
>
> I'll point out that the Fedora developers enabled this in the rawhide kernels
> for 3 days, and then turned it back off because most of the things found were
> false positives.
Yes, but with 2.6.31-rc3 the number of false positives dropped
considerably. I don't plan to push any new kmemleak patches for 2.6.31
(probably only a bug-fix).
Anyway, even when it reports real leaks, it is very time consuming to
investigate.
I don't have any PPC hardware but as long as someone sorts out things
like _edata or other PPC-specific allocators which aren't currently
tracked by kmemleak, I'm OK with the original patch:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
--
Catalin
^ permalink raw reply
* rtas instantiation when commandline contains mem
From: Benjamin Krill @ 2009-07-16 13:12 UTC (permalink / raw)
To: enjamin Herrenschmidt, Michael Ellerman; +Cc: linuxppc-dev
Hi,
the rtas instantiation (prom_init.c) doesn't work correctly if the
kernel parameter "mem=" is used. The current code doesn't evaluate
the kernel parameter which causes the issue that alloc_down
allocates somewhere in the "real" memory space. So it can
happen that the allocation space is above "mem=".
Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
evaluation of "mem=".
cheers
ben
^ 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