* Doubt about Linux PCIe infraestructure
From: Carlos Roberto Moratelli @ 2010-09-28 11:16 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a simple doubt about linux PCI/PCIe infraestructure.
When I register a PCI driver using pci_register_driver() will the
probe function be automatically called or will it just be called if PCI
infraestructure match a Vendor and Device id on bus?
I am loading a PCI driver that register itself using
pci_register_driver() but the probe function isn't called.
thanks,
Carlos R. Moratelli
^ permalink raw reply
* Re: [PATCH v2 2/3] USB: add of_platform glue driver for FSL USB DR controller
From: Anatolij Gustschin @ 2010-09-28 11:35 UTC (permalink / raw)
To: Grant Likely
Cc: Greg Kroah-Hartman, Wolfgang Denk, Detlev Zundel, linux-usb,
linuxppc-dev, David Brownell
In-Reply-To: <AANLkTinnodk8wA2aHXBjmZRhv_OFS+zQdb5Tc6of36jQ@mail.gmail.com>
Hi Grant,
On Tue, 28 Sep 2010 19:01:28 +0900
Grant Likely <grant.likely@secretlab.ca> wrote:
...
> Looks pretty good. Comments below. Main comment is that with the
> recent changes in mainline, this no longer needs to be an
> of_platform_driver. It can be a plain old platform_driver instead.
> It gets registered as a platform_driver anyway, but of_platform_driver
> is a shim that adds a bit of overhead, so it is best to avoid it.
> I'll detail the changes you need to make in my comments below.
Thanks. I'll change to platform_driver. My reply below.
...
> > +{
> > + =A0 =A0 =A0 struct device_node *np =3D ofdev->dev.of_node;
> > + =A0 =A0 =A0 struct platform_device *usb_dev;
> > + =A0 =A0 =A0 struct fsl_usb2_platform_data data, *pdata;
> > + =A0 =A0 =A0 struct fsl_usb2_dev_data *dev_data;
> > + =A0 =A0 =A0 const unsigned char *prop;
> > + =A0 =A0 =A0 static unsigned int idx;
> > + =A0 =A0 =A0 int i;
> > +
> > + =A0 =A0 =A0 if (!of_device_is_available(np))
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> > +
> > + =A0 =A0 =A0 pdata =3D match->data;
> > + =A0 =A0 =A0 if (!pdata) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(&data, 0, sizeof(data));
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata =3D &data;
> > + =A0 =A0 =A0 }
>=20
> This is bad behaviour. *match->data must not be modified in probe
> because multiple instances of the device can exist. The target of
> pdata is modified later in the probe routine.
>=20
> However, the above 4 lines can be removed entirely since none of the
> fsl_usb2_mph_dr_of_match entries actually set the data pointer. The
> local 'data' structure can be used directly.
A match entry for mpc5121 is added by the third patch. I'll fix
this so that only local 'data' structure is modified later in the
probe routine.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/fsl_soc.c: remove FSL USB platform code
From: Anton Vorontsov @ 2010-09-28 11:40 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: David Brownell, Wolfgang Denk, Detlev Zundel, linux-usb,
linuxppc-dev, Greg Kroah-Hartman
In-Reply-To: <1285666594-21150-2-git-send-email-agust@denx.de>
On Tue, Sep 28, 2010 at 11:36:32AM +0200, Anatolij Gustschin wrote:
> This removed code will be replaced by simple of_platform
> driver for creation of FSL USB platform devices which is
> added by next patch of the series.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
This is not bisectable. You have to merge 1/3 and 2/3.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [RFC][PATCH 0/3] fixes and MPC8308 support for the mpc512x_dma driver
From: Ilya Yanok @ 2010-09-28 12:24 UTC (permalink / raw)
To: linuxppc-dev, wd, dzu, vlad; +Cc: Piotr Ziecik, Ilya Yanok
Hello everybody,
I've found that mpc512x_dma doesn't work reliable in my tests (dmatest
module and NetPipe with CONFIG_NET_DMA enabled).
These patches fixes two issues I've found: inproper handling of
scatter/gather transfers and missing interrupts.
The third patch adds support for MPC8308 which has pretty much the same
DMA controller as MPC5121.
The first patch has an issue: I'm accessing IO space with direct memory
access not via accessor functions. I don't know how to use accessor
functions with bitfield structures.
Any comments would be appreciated.
With these patches applied my tests succeed both on MPC5121 and MPC8308.
Regards, Ilya.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
^ permalink raw reply
* [PATCH 3/3] mpc512x_dma: add MPC8308 support
From: Ilya Yanok @ 2010-09-28 12:24 UTC (permalink / raw)
To: linuxppc-dev, wd, dzu, vlad; +Cc: Piotr Ziecik, Ilya Yanok
In-Reply-To: <1285676696-5358-1-git-send-email-yanok@emcraft.com>
MPC8308 has pretty much the same DMA controller as MPC5121 and
this patch adds support for MPC8308 to the mpc512x_dma driver.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
---
drivers/dma/Kconfig | 2 +-
drivers/dma/mpc512x_dma.c | 95 +++++++++++++++++++++++++++++++++-----------
2 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9520cf0..5c5e95b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -100,7 +100,7 @@ config FSL_DMA
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
- depends on PPC_MPC512x
+ depends on PPC_MPC512x || PPC_MPC831x
select DMA_ENGINE
---help---
Enable support for the Freescale MPC512x built-in DMA engine.
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 0717527..97b92ec 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
* Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
*
* Written by Piotr Ziecik <kosmo@semihalf.com>. Hardware description
* (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -70,6 +71,8 @@
#define MPC_DMA_DMAES_SBE (1 << 1)
#define MPC_DMA_DMAES_DBE (1 << 0)
+#define MPC_DMA_DMAGPOR_SNOOP_ENABLE (1 << 6)
+
#define MPC_DMA_TSIZE_1 0x00
#define MPC_DMA_TSIZE_2 0x01
#define MPC_DMA_TSIZE_4 0x02
@@ -104,7 +107,10 @@ struct __attribute__ ((__packed__)) mpc_dma_regs {
/* 0x30 */
u32 dmahrsh; /* DMA hw request status high(ch63~32) */
u32 dmahrsl; /* DMA hardware request status low(ch31~0) */
- u32 dmaihsa; /* DMA interrupt high select AXE(ch63~32) */
+ union {
+ u32 dmaihsa; /* DMA interrupt high select AXE(ch63~32) */
+ u32 dmagpor; /* (General purpose register on MPC8308) */
+ };
u32 dmailsa; /* DMA interrupt low select AXE(ch31~0) */
/* 0x40 ~ 0xff */
u32 reserve0[48]; /* Reserved */
@@ -195,7 +201,9 @@ struct mpc_dma {
struct mpc_dma_regs __iomem *regs;
struct mpc_dma_tcd __iomem *tcd;
int irq;
+ int irq2;
uint error_status;
+ int is_mpc8308;
/* Lock for error_status field in this structure */
spinlock_t error_status_lock;
@@ -307,8 +315,10 @@ static irqreturn_t mpc_dma_irq(int irq, void *data)
spin_unlock(&mdma->error_status_lock);
/* Handle interrupt on each channel */
- mpc_dma_irq_process(mdma, in_be32(&mdma->regs->dmainth),
+ if (mdma->dma.chancnt > 32) {
+ mpc_dma_irq_process(mdma, in_be32(&mdma->regs->dmainth),
in_be32(&mdma->regs->dmaerrh), 32);
+ }
mpc_dma_irq_process(mdma, in_be32(&mdma->regs->dmaintl),
in_be32(&mdma->regs->dmaerrl), 0);
@@ -562,6 +572,7 @@ static struct dma_async_tx_descriptor *
mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
size_t len, unsigned long flags)
{
+ struct mpc_dma *mdma = dma_chan_to_mpc_dma(chan);
struct mpc_dma_chan *mchan = dma_chan_to_mpc_dma_chan(chan);
struct mpc_dma_desc *mdesc = NULL;
struct mpc_dma_tcd *tcd;
@@ -590,7 +601,8 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
tcd->dsize = MPC_DMA_TSIZE_32;
tcd->soff = 32;
tcd->doff = 32;
- } else if (IS_ALIGNED(src | dst | len, 16)) {
+ } else if (!mdma->is_mpc8308 && IS_ALIGNED(src | dst | len, 16)) {
+ /* MPC8308 doesn't support 16 byte transfers */
tcd->ssize = MPC_DMA_TSIZE_16;
tcd->dsize = MPC_DMA_TSIZE_16;
tcd->soff = 16;
@@ -650,6 +662,15 @@ static int __devinit mpc_dma_probe(struct platform_device *op,
return -EINVAL;
}
+ if (of_device_is_compatible(dn, "fsl,mpc8308-dma")) {
+ mdma->is_mpc8308 = 1;
+ mdma->irq2 = irq_of_parse_and_map(dn, 1);
+ if (mdma->irq2 == NO_IRQ) {
+ dev_err(dev, "Error mapping IRQ!\n");
+ return -EINVAL;
+ }
+ }
+
retval = of_address_to_resource(dn, 0, &res);
if (retval) {
dev_err(dev, "Error parsing memory region!\n");
@@ -680,11 +701,23 @@ static int __devinit mpc_dma_probe(struct platform_device *op,
return -EINVAL;
}
+ if (mdma->is_mpc8308) {
+ retval = devm_request_irq(dev, mdma->irq2, &mpc_dma_irq, 0,
+ DRV_NAME, mdma);
+ if (retval) {
+ dev_err(dev, "Error requesting IRQ2!\n");
+ return -EINVAL;
+ }
+ }
+
spin_lock_init(&mdma->error_status_lock);
dma = &mdma->dma;
dma->dev = dev;
- dma->chancnt = MPC_DMA_CHANNELS;
+ if (!mdma->is_mpc8308)
+ dma->chancnt = MPC_DMA_CHANNELS;
+ else
+ dma->chancnt = 16; /* MPC8308 DMA has only 16 channels */
dma->device_alloc_chan_resources = mpc_dma_alloc_chan_resources;
dma->device_free_chan_resources = mpc_dma_free_chan_resources;
dma->device_issue_pending = mpc_dma_issue_pending;
@@ -720,26 +753,40 @@ static int __devinit mpc_dma_probe(struct platform_device *op,
* - Round-robin group arbitration,
* - Round-robin channel arbitration.
*/
- out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
- MPC_DMA_DMACR_ERGA | MPC_DMA_DMACR_ERCA);
-
- /* Disable hardware DMA requests */
- out_be32(&mdma->regs->dmaerqh, 0);
- out_be32(&mdma->regs->dmaerql, 0);
-
- /* Disable error interrupts */
- out_be32(&mdma->regs->dmaeeih, 0);
- out_be32(&mdma->regs->dmaeeil, 0);
-
- /* Clear interrupts status */
- out_be32(&mdma->regs->dmainth, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaintl, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaerrh, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaerrl, 0xFFFFFFFF);
-
- /* Route interrupts to IPIC */
- out_be32(&mdma->regs->dmaihsa, 0);
- out_be32(&mdma->regs->dmailsa, 0);
+ if (!mdma->is_mpc8308) {
+ out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
+ MPC_DMA_DMACR_ERGA | MPC_DMA_DMACR_ERCA);
+
+ /* Disable hardware DMA requests */
+ out_be32(&mdma->regs->dmaerqh, 0);
+ out_be32(&mdma->regs->dmaerql, 0);
+
+ /* Disable error interrupts */
+ out_be32(&mdma->regs->dmaeeih, 0);
+ out_be32(&mdma->regs->dmaeeil, 0);
+
+ /* Clear interrupts status */
+ out_be32(&mdma->regs->dmainth, 0xFFFFFFFF);
+ out_be32(&mdma->regs->dmaintl, 0xFFFFFFFF);
+ out_be32(&mdma->regs->dmaerrh, 0xFFFFFFFF);
+ out_be32(&mdma->regs->dmaerrl, 0xFFFFFFFF);
+
+ /* Route interrupts to IPIC */
+ out_be32(&mdma->regs->dmaihsa, 0);
+ out_be32(&mdma->regs->dmailsa, 0);
+ } else {
+ /* MPC8308 has 16 channels and lacks some registers */
+ out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
+
+ /* enable snooping */
+ out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
+ /* Disable error interrupts */
+ out_be32(&mdma->regs->dmaeeil, 0);
+
+ /* Clear interrupts status */
+ out_be32(&mdma->regs->dmaintl, 0xFFFF);
+ out_be32(&mdma->regs->dmaerrl, 0xFFFF);
+ }
/* Register DMA engine */
dev_set_drvdata(dev, mdma);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] mpc512x_dma: fix the hanged transfer issue
From: Ilya Yanok @ 2010-09-28 12:24 UTC (permalink / raw)
To: linuxppc-dev, wd, dzu, vlad; +Cc: Piotr Ziecik, Ilya Yanok
In-Reply-To: <1285676696-5358-1-git-send-email-yanok@emcraft.com>
Current code clears interrupt active status _after_ submiting new
transfers. This leaves a possibility of clearing the interrupt for this
new transfer (if it is triggered fast enough) and thus lose this
interrupt. We want to clear interrupt active status _before_ new
transfers is submited and for current channel only.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
---
drivers/dma/mpc512x_dma.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 1bc04aa..0717527 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -276,6 +276,9 @@ static void mpc_dma_irq_process(struct mpc_dma *mdma, u32 is, u32 es, int off)
spin_lock(&mchan->lock);
+ out_8(&mdma->regs->dmacint, ch + off);
+ out_8(&mdma->regs->dmacerr, ch + off);
+
/* Check error status */
if (es & (1 << ch))
list_for_each_entry(mdesc, &mchan->active, node)
@@ -309,12 +312,6 @@ static irqreturn_t mpc_dma_irq(int irq, void *data)
mpc_dma_irq_process(mdma, in_be32(&mdma->regs->dmaintl),
in_be32(&mdma->regs->dmaerrl), 0);
- /* Ack interrupt on all channels */
- out_be32(&mdma->regs->dmainth, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaintl, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaerrh, 0xFFFFFFFF);
- out_be32(&mdma->regs->dmaerrl, 0xFFFFFFFF);
-
/* Schedule tasklet */
tasklet_schedule(&mdma->tasklet);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] mpc512x_dma: scatter/gather fix
From: Ilya Yanok @ 2010-09-28 12:24 UTC (permalink / raw)
To: linuxppc-dev, wd, dzu, vlad; +Cc: Piotr Ziecik, Ilya Yanok
In-Reply-To: <1285676696-5358-1-git-send-email-yanok@emcraft.com>
While testing mpc512x-dma driver with dmatest module I've found that
I can hang the mpc512x-dma issueing request from multiple threads to
the single channel.
(insmod dmatest.ko max_channels=1 threads_per_chan=16)
After investingating this case I've managed to find that this happens
if and only if we have more than one quequed requests.
In this case the driver tries to make use of hardware scatter/gather
functionality. I've found two problems with scatter/gather:
1. When TCD is copied form RAM to the TCD register space with memcpy_io()
e_sg bit eventually gets cleared. This results in only first TCD being
executed. I've added setting of e_sg bit excplicitly in the TCD registers.
BTW, what is the correct way to do this? (How can I use setbits with bitfield
structure?) After that hardware loads consecutive TCDs and we hit the
second issue.
2. Existing code clears int_maj bit in the last TCD so we never get
an interrupt on transfefr completion.
With these fixes my tests with many threads of single channel succeed but
tests that use many channels simultaneously still don't work reliable.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
---
drivers/dma/mpc512x_dma.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 4e9cbf3..1bc04aa 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -252,11 +252,13 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
prev = mdesc;
}
- prev->tcd->start = 0;
prev->tcd->int_maj = 1;
/* Send first descriptor in chain into hardware */
memcpy_toio(&mdma->tcd[cid], first->tcd, sizeof(struct mpc_dma_tcd));
+
+ if (first != prev)
+ mdma->tcd[cid].e_sg = 1;
out_8(&mdma->regs->dmassrt, cid);
}
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Robin Holt @ 2010-09-28 12:38 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4CA0EBEB.1030204@austin.ibm.com>
I was tasked with looking at a slowdown in similar sized SGI machines
booting x86_64. Jack Steiner had already looked into the memory_dev_init.
I was looking at link_mem_sections().
I made a dramatic improvement on a 16TB machine in that function by
merely caching the most recent memory section and checking to see if
the next memory section happens to be the subsequent in the linked list
of kobjects.
That simple cache reduced the time for link_mem_sections from 1 hour 27
minutes down to 46 seconds.
I would like to propose we implement something along those lines also,
but I am currently swamped. I can probably get you a patch tomorrow
afternoon that applies at the end of this set.
Thanks,
Robin
On Mon, Sep 27, 2010 at 02:09:31PM -0500, Nathan Fontenot wrote:
> This set of patches decouples the concept that a single memory
> section corresponds to a single directory in
> /sys/devices/system/memory/. On systems
> with large amounts of memory (1+ TB) there are perfomance issues
> related to creating the large number of sysfs directories. For
> a powerpc machine with 1 TB of memory we are creating 63,000+
> directories. This is resulting in boot times of around 45-50
> minutes for systems with 1 TB of memory and 8 hours for systems
> with 2 TB of memory. With this patch set applied I am now seeing
> boot times of 5 minutes or less.
>
> The root of this issue is in sysfs directory creation. Every time
> a directory is created a string compare is done against all sibling
> directories to ensure we do not create duplicates. The list of
> directory nodes in sysfs is kept as an unsorted list which results
> in this being an exponentially longer operation as the number of
> directories are created.
>
> The solution solved by this patch set is to allow a single
> directory in sysfs to span multiple memory sections. This is
> controlled by an optional architecturally defined function
> memory_block_size_bytes(). The default definition of this
> routine returns a memory block size equal to the memory section
> size. This maintains the current layout of sysfs memory
> directories as it appears to userspace to remain the same as it
> is today.
>
> For architectures that define their own version of this routine,
> as is done for powerpc in this patchset, the view in userspace
> would change such that each memoryXXX directory would span
> multiple memory sections. The number of sections spanned would
> depend on the value reported by memory_block_size_bytes.
>
> In both cases a new file 'end_phys_index' is created in each
> memoryXXX directory. This file will contain the physical id
> of the last memory section covered by the sysfs directory. For
> the default case, the value in 'end_phys_index' will be the same
> as in the existing 'phys_index' file.
>
> This version of the patch set includes an update to to properly
> report block_size_bytes, phys_index, and end_phys_index. Additionally,
> the patch that adds the end_phys_index sysfs file is now patch 5/8
> instead of being patch 2/8 as in the previous version of the patches.
>
> -Nathan Fontenot
> --
> 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 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Avi Kivity @ 2010-09-28 12:44 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4CA0EBEB.1030204@austin.ibm.com>
On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
> This set of patches decouples the concept that a single memory
> section corresponds to a single directory in
> /sys/devices/system/memory/. On systems
> with large amounts of memory (1+ TB) there are perfomance issues
> related to creating the large number of sysfs directories. For
> a powerpc machine with 1 TB of memory we are creating 63,000+
> directories. This is resulting in boot times of around 45-50
> minutes for systems with 1 TB of memory and 8 hours for systems
> with 2 TB of memory. With this patch set applied I am now seeing
> boot times of 5 minutes or less.
>
> The root of this issue is in sysfs directory creation. Every time
> a directory is created a string compare is done against all sibling
> directories to ensure we do not create duplicates. The list of
> directory nodes in sysfs is kept as an unsorted list which results
> in this being an exponentially longer operation as the number of
> directories are created.
>
> The solution solved by this patch set is to allow a single
> directory in sysfs to span multiple memory sections. This is
> controlled by an optional architecturally defined function
> memory_block_size_bytes(). The default definition of this
> routine returns a memory block size equal to the memory section
> size. This maintains the current layout of sysfs memory
> directories as it appears to userspace to remain the same as it
> is today.
>
Why not update sysfs directory creation to be fast, for example by using
an rbtree instead of a linked list. This fixes an implementation
problem in the kernel instead of working around it and creating a new ABI.
New ABIs mean old tools won't work, and new tools need to understand
both ABIs.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 8/8] v2 Update memory hotplug documentation
From: Avi Kivity @ 2010-09-28 12:45 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4CA0F076.1070803@austin.ibm.com>
On 09/27/2010 09:28 PM, Nathan Fontenot wrote:
>
> For example, assume 1GiB section size. A device for a memory starting at
> 0x100000000 is /sys/device/system/memory/memory4
> (0x100000000 / 1Gib = 4)
> This device covers address range [0x100000000 ... 0x140000000)
>
> -Under each section, you can see 4 files.
> +Under each section, you can see 5 files.
Shouldn't this be, 4 or 5 files depending on kernel version?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 4/8] v2 Allow memory block to span multiple memory sections
From: Robin Holt @ 2010-09-28 12:48 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4CA0EFAA.8050000@austin.ibm.com>
> +u32 __weak memory_block_size_bytes(void)
> +{
> + return MIN_MEMORY_BLOCK_SIZE;
> +}
> +
> +static u32 get_memory_block_size(void)
Can we make this an unsigned long? We are testing on a system whose
smallest possible configuration is 4GB per socket with 512 sockets.
We would like to be able to specify this as 2GB by default (results
in the least lost memory) and suggest we add a command line option
which overrides this value. We have many installations where 16GB may
be optimal. Large configurations will certainly become more prevalent.
...
> @@ -551,12 +608,16 @@
> unsigned int i;
> int ret;
> int err;
> + int block_sz;
This one needs to match the return above. In our tests, we ended up
with a negative sections_per_block which caused very unexpected results.
Robin
^ permalink raw reply
* Re: [PATCH 3/3] mpc512x_dma: add MPC8308 support
From: Wolfgang Denk @ 2010-09-28 13:09 UTC (permalink / raw)
To: Ilya Yanok; +Cc: vlad, linuxppc-dev, Piotr Ziecik, dzu
In-Reply-To: <1285676696-5358-4-git-send-email-yanok@emcraft.com>
Dear Ilya Yanok,
In message <1285676696-5358-4-git-send-email-yanok@emcraft.com> you wrote:
> MPC8308 has pretty much the same DMA controller as MPC5121 and
> this patch adds support for MPC8308 to the mpc512x_dma driver.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> Cc: Piotr Ziecik <kosmo@semihalf.com>
> ---
> drivers/dma/Kconfig | 2 +-
> drivers/dma/mpc512x_dma.c | 95 +++++++++++++++++++++++++++++++++-----------
> 2 files changed, 72 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 9520cf0..5c5e95b 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -100,7 +100,7 @@ config FSL_DMA
>
> config MPC512X_DMA
> tristate "Freescale MPC512x built-in DMA engine support"
> - depends on PPC_MPC512x
> + depends on PPC_MPC512x || PPC_MPC831x
Is MPC831x correct here? My understanding is that MPC831x processors
have yet other DMA cotnrollers, and we're on a MPC8308 here?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"A little knowledge is a dangerous thing." - Doug Gwyn
^ permalink raw reply
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2010-09-28 13:09 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
A few small updates for the next branch. A new board/SoC from AMCC, and
some 476 changes from Shaggy. Please pull.
josh
The following changes since commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352:
powerpc/perf: Fix sampling enable for PPC970 (2010-09-23 17:03:56 +1000)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Dave Kleikamp (2):
powerpc/476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB
powerpc/476: lazy flush_tlb_mm for nohash architectures
Josh Boyer (1):
powerpc/44x: Update ppc44x_defconfig
Tirumala Marri (1):
powerpc/44x: Add support for the AMCC APM821xx SoC
arch/powerpc/boot/dts/bluestone.dts | 254 ++++++++++++++++++++++++++
arch/powerpc/configs/44x/bluestone_defconfig | 68 +++++++
arch/powerpc/configs/ppc44x_defconfig | 9 +-
arch/powerpc/include/asm/reg_booke.h | 4 +
arch/powerpc/kernel/cpu_setup_44x.S | 1 +
arch/powerpc/kernel/cputable.c | 15 ++
arch/powerpc/kernel/head_44x.S | 25 +++
arch/powerpc/mm/mmu_context_nohash.c | 154 ++++++++++++++--
arch/powerpc/mm/mmu_decl.h | 8 +
arch/powerpc/mm/tlb_nohash.c | 28 +++-
arch/powerpc/mm/tlb_nohash_low.S | 14 ++-
arch/powerpc/platforms/44x/Kconfig | 16 ++
arch/powerpc/platforms/44x/misc_44x.S | 26 +++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
14 files changed, 602 insertions(+), 21 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bluestone.dts
create mode 100644 arch/powerpc/configs/44x/bluestone_defconfig
^ permalink raw reply
* powerpc kernel 2.6.35.6 crash with gianfar ethernet at full line rate traffic
From: emre kara @ 2010-09-28 13:32 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Hi all,=0A=0AI have a serious problem with latest stable kernel (2.6.35.6) =
and gianfar ethernet driver.=0A=0AI'am using default SMP kernel configurati=
on and MPC8572DS development board and also using an hardware packet genera=
tor.=0A=0AMy test is ip forwarding between eth0 and eth1, and Hardware pack=
et generator produces full duplex, full line rate traffic with random packe=
t length and random payload . After 1.2 billion packet passed, kernel produ=
ces this bellow crash message.=0A=0AI have done same test with an intel qua=
d core pc and sky2 gigabit ethernet controller. No errors occured yet. So t=
hat it seems that this problem may be related with gianfar.=0A=0AAny comme=
nt and help are appreciated.=0A=0A=0A=0AThanks.=0A=0AEmre=0A=0A=0A=0A=0A=0A=
------------[ cut here ]------------=0A=0Akernel BUG at net/core/skbuff.c:1=
27!=0A=0AOops: Exception in kernel mode, sig: 5 [#1]=0A=0ASMP NR_CPUS=3D8 M=
PC8572 DS=0A=0Alast sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsys=
tem_device=0A=0AModules linked in:=0A=0ANIP: c0255260 LR: c0255260 CTR: c02=
21f64=0A=0AREGS: effebd70 TRAP: 0700 Not tainted (2.6.35.6)=0A=0AMSR: 00=
029000 <EE,ME,CE> CR: 24028022 XER: 20000000=0A=0ATASK =3D ef03ce10[3] 'k=
softirqd/0' THREAD: ef04a000 CPU: 0=0A=0AGPR00: c0255260 effebe20 ef03ce10 =
0000007c 00021000 ffffffff c0225ac0 c04364cc=0A=0AGPR08: c042e9ac c04364e0 =
effea000 c0430000 20028048 1001a108 ef550000 ef0f6d70=0A=0AGPR16: ef0f6e18 =
ef0f685c 00000000 ef550800 00000008 00000001 ef0f6800 0000003f=0A=0AGPR24: =
ef141a80 ef0f6b60 00000000 ef550950 ef0f6b60 00000420 ef3f0400 ef525600=0A=
=0ANIP [c0255260] skb_put+0x8c/0x94=0A=0ALR [c0255260] skb_put+0x8c/0x94=0A=
=0ACall Trace:=0A=0A[effebe20] [c0255260] skb_put+0x8c/0x94 (unreliable)=0A=
=0A[effebe30] [c023e004] gfar_clean_rx_ring+0x10c/0x4d8=0A=0A[effebe90] [c0=
23e794] gfar_poll+0x3c4/0x5f4=0A=0A[effebf60] [c0262498] net_rx_action+0xf8=
/0x1a4=0A=0A[effebfa0] [c0049dcc] __do_softirq+0xe0/0x178=0A=0A[effebff0] [=
c0010790] call_do_softirq+0x14/0x24=0A=0A[ef04bf50] [c0004868] do_softirq+0=
x90/0xa0=0A=0A[ef04bf70] [c004a98c] run_ksoftirqd+0xb4/0x164=0A=0A[ef04bfb0=
] [c005dacc] kthread+0x78/0x7c=0A=0A[ef04bff0] [c0010b9c] kernel_thread+0x4=
c/0x68=0A=0AInstruction dump:=0A=0A81030098 2f800000 409e000c 3d20c03d 3809=
e0d8 3c60c03d 7c8802a6 7d695b78=0A=0A3863ee60 90010008 4cc63182 4bdefaa9 <0=
fe00000> 48000000 9421fff0 7c0802a6=0A=0AKernel panic - not syncing: Fatal =
exception in interrupt=0A=0ACall Trace:=0A=0A[effebb20] [c00082fc] show_sta=
ck+0x4c/0x180 (unreliable)=0A=0A[effebb50] [c0043720] panic+0xa0/0x11c=0A=
=0A[effebbe0] [c000db44] die+0x184/0x1d0=0A=0A[effebc10] [c000dcfc] _except=
ion+0x114/0x130=0A=0A[effebd60] [c0011440] ret_from_except_full+0x0/0x4c=0A=
=0A--- Exception: 700 at skb_put+0x8c/0x94=0A=0A LR =3D skb_put+0x8c/0x9=
4=0A=0A[effebe30] [c023e004] gfar_clean_rx_ring+0x10c/0x4d8=0A=0A[effebe90]=
[c023e794] gfar_poll+0x3c4/0x5f4=0A=0A[effebf60] [c0262498] net_rx_action+=
0xf8/0x1a4=0A=0A[effebfa0] [c0049dcc] __do_softirq+0xe0/0x178=0A=0A[effebff=
0] [c0010790] call_do_softirq+0x14/0x24=0A=0A[ef04bf50] [c0004868] do_softi=
rq+0x90/0xa0=0A=0A[ef04bf70] [c004a98c] run_ksoftirqd+0xb4/0x164=0A=0A[ef04=
bfb0] [c005dacc] kthread+0x78/0x7c=0A=0A[ef04bff0] [c0010b9c] kernel_thread=
+0x4c/0x68=0A=0ARebooting in 180 seconds..=0A=0A=0A
^ permalink raw reply
* Re: Doubt about Linux PCIe infraestructure
From: Micha Nelissen @ 2010-09-28 13:46 UTC (permalink / raw)
To: Carlos Roberto Moratelli; +Cc: linuxppc-dev
In-Reply-To: <1285672565.6920.3.camel@parana.digitel.com.br>
Carlos Roberto Moratelli wrote:
> When I register a PCI driver using pci_register_driver() will the
> probe function be automatically called or will it just be called if PCI
> infraestructure match a Vendor and Device id on bus?
Yes, vendor and device id must match. You can find those in lspci.
Micha
^ permalink raw reply
* Re: Doubt about Linux PCIe infraestructure
From: david.hagood @ 2010-09-28 14:20 UTC (permalink / raw)
To: Carlos Roberto Moratelli; +Cc: linuxppc-dev
In-Reply-To: <1285672565.6920.3.camel@parana.digitel.com.br>
> Hi,
>
> I have a simple doubt about linux PCI/PCIe infraestructure.
>
> When I register a PCI driver using pci_register_driver() will the
> probe function be automatically called or will it just be called if PCI
> infraestructure match a Vendor and Device id on bus?
When you register your driver, you supply a list of VID/DID pairs for
which your driver is applicable, and if those devices are on the bus, your
probe will be called.
>
> I am loading a PCI driver that register itself using
> pci_register_driver() but the probe function isn't called.
>
If you didn't indicate your driver was for the VID/DID of the device, your
probe won't be called - why should it? As far as you told the kernel,
there's no hardware pertaining to your driver.
The old days of "every driver probes every device" are gone.
Here's an example code fragment:
/* define the list of devices we support */
static struct pci_device_id ppc_ep_device_ids[] =
{
{PCI_DEVICE(PCI_VENDOR_ID_FREESCALE,PCI_DEVICE_ID_MPC8641D)},
{0} /* end of list indicator */
};
MODULE_DEVICE_TABLE(pci, ppc_ep_device_ids); /* tell udev to load our
module for these devices */
pci_register_driver(&ppc_ep_device_driver); /* tell the kernel we handle
these devices */
^ permalink raw reply
* Parsing a bus fault message?
From: david.hagood @ 2010-09-28 14:26 UTC (permalink / raw)
To: linuxppc-dev
I finally found my problems accessing the PPC OWBAR registers as an
endpoint (copy/paste brown paper bag bug on my part), but I still get a
bus fault trying to access the device.
The problem is that I don't know if the fault is internal to the PPC (e.g.
I don't have something in the chip set up) or if the fault is happening on
the PCIe side of things.
Are there any good how-tos on interpreting the kernel machine check error
for the PPC, that might help me know where to look for the problem?
Alternatively, can somebody see a hint in the message that I don't know
enough to pick out? At this point, my code is trying to memcpy() from the
PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
either a) the ATMU is not accessible b) the ATMU is accessible but not
mapped (which I would have thought the ioremap call I made would have
handled) or c) the chip is not able to bus master on the PCI bus.
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2 EP8641A
Modules linked in: Endpoint_driver rionetlink
NIP: c0014e80 LR: f102d434 CTR: 00000200
REGS: ef05fdf0 TRAP: 0200 Not tainted (2.6.26.2-ep1.10)
MSR: 00149030 <EE,ME,IR,DR> CR: 24004482 XER: 00000000
TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0
GPR00: 00000000 ef05fea0 ef05b310 eed06000 f14dfffc 00001000 eed05ffc
80000000
GPR08: 00000000 00000000 00001000 c0014e60 00001000 100a7264 0ffff100
00000001
GPR16: ffffffff 004005b4 007fff00 c0290000 c02f0000 ef05ff20 bfba5978
eed06000
GPR24: eed14ce0 ef02c678 eed61910 00000000 00000000 efb8d4b0 fffffffb
00001000
NIP [c0014e80] memcpy+0x20/0x9c
LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver]
Call Trace:
[ef05fea0] [ef05609c] 0xef05609c (unreliable)
[ef05feb0] [c00cf2c0] read+0xd8/0x1c8
[ef05fef0] [c007ff40] vfs_read+0xcc/0x16c
[ef05ff10] [c008074c] sys_read+0x4c/0x90
[ef05ff40] [c0011174] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff697f0
LR = 0x10007008
Instruction dump:
4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
70c00003 7ce903a6 40820054 80e40004 <85040008> 90e60004 95060008 4200fff0
---[ end trace e0620da52f69882d ]---
^ permalink raw reply
* Re: [PATCH 3/3] mpc512x_dma: add MPC8308 support
From: Ilya Yanok @ 2010-09-28 13:47 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: vlad, linuxppc-dev, Piotr Ziecik, dzu
In-Reply-To: <20100928130919.1558AD5218F@gemini.denx.de>
Dear Wolfgang,
28.09.2010 17:09, Wolfgang Denk wrote:
>> config MPC512X_DMA
>> tristate "Freescale MPC512x built-in DMA engine support"
>> - depends on PPC_MPC512x
>> + depends on PPC_MPC512x || PPC_MPC831x
>
> Is MPC831x correct here? My understanding is that MPC831x processors
> have yet other DMA cotnrollers, and we're on a MPC8308 here?
Well, PPC_MPC831x is not correct here in the strict sense, but there are
some reasons for it:
1. We don't really have PPC_MPC8308 config option for MPC8308
processor. Well, maybe that was my fault that I didn't add it when I
initially introduced support for MPC8308. But I don't actually see the
point for it. All the differencies from MPC831x are handled run-time
based on device-tree.
2. Some of MPC831x (I believe it's MPC8315) really has the compatible
DMA controller (it's called something like DMA controller of the TDM
module). Well it will probably need some additional work in the driver
to support this controller but hardware is mostly the same.
3. Well, it's only compilation option you need a proper device-tree
node for the driver to start. Ok, you can make your kernel bigger by
compiling in the driver which is useless for your CPU but you can't
break it provided you have a correct device-tree.
Regards, Ilya.
^ permalink raw reply
* [PATCH] powerpc: cell: Fix axion_msi irq shutdown
From: Thomas Gleixner @ 2010-09-28 15:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
Calling unmask_msi_irq on irq shutdown is at least suboptimal.
Use mask_msi_irq instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/powerpc/platforms/cell/axon_msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/axon_msi.c
+++ linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
@@ -312,7 +312,7 @@ static void axon_msi_teardown_msi_irqs(s
static struct irq_chip msic_irq_chip = {
.mask = mask_msi_irq,
.unmask = unmask_msi_irq,
- .shutdown = unmask_msi_irq,
+ .shutdown = mask_msi_irq,
.name = "AXON-MSI",
};
^ permalink raw reply
* Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Robin Holt @ 2010-09-28 15:12 UTC (permalink / raw)
To: Avi Kivity
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4CA1E338.6070201@redhat.com>
On Tue, Sep 28, 2010 at 02:44:40PM +0200, Avi Kivity wrote:
> On 09/27/2010 09:09 PM, Nathan Fontenot wrote:
> >This set of patches decouples the concept that a single memory
> >section corresponds to a single directory in
> >/sys/devices/system/memory/. On systems
> >with large amounts of memory (1+ TB) there are perfomance issues
> >related to creating the large number of sysfs directories. For
> >a powerpc machine with 1 TB of memory we are creating 63,000+
> >directories. This is resulting in boot times of around 45-50
> >minutes for systems with 1 TB of memory and 8 hours for systems
> >with 2 TB of memory. With this patch set applied I am now seeing
> >boot times of 5 minutes or less.
> >
> >The root of this issue is in sysfs directory creation. Every time
> >a directory is created a string compare is done against all sibling
> >directories to ensure we do not create duplicates. The list of
> >directory nodes in sysfs is kept as an unsorted list which results
> >in this being an exponentially longer operation as the number of
> >directories are created.
> >
> >The solution solved by this patch set is to allow a single
> >directory in sysfs to span multiple memory sections. This is
> >controlled by an optional architecturally defined function
> >memory_block_size_bytes(). The default definition of this
> >routine returns a memory block size equal to the memory section
> >size. This maintains the current layout of sysfs memory
> >directories as it appears to userspace to remain the same as it
> >is today.
> >
>
> Why not update sysfs directory creation to be fast, for example by
> using an rbtree instead of a linked list. This fixes an
> implementation problem in the kernel instead of working around it
> and creating a new ABI.
Because the old ABI creates 129,000+ entries inside
/sys/devices/system/memory with their associated links from
/sys/devices/system/node/node*/ back to those directory entries.
Thankfully things like rpm, hald, and other miscellaneous commands scan
that information. On our 8 TB test machine, hald runs continuously
following boot for nearly an hour mostly scanning useless information
from /sys/
Robin
>
> New ABIs mean old tools won't work, and new tools need to understand
> both ABIs.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> 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] powerpc: cell: Fix axion_msi irq shutdown
From: Arnd Bergmann @ 2010-09-28 15:13 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev
In-Reply-To: <alpine.LFD.2.00.1009281708350.2416@localhost6.localdomain6>
On Tuesday 28 September 2010, Thomas Gleixner wrote:
> Calling unmask_msi_irq on irq shutdown is at least suboptimal.
> Use mask_msi_irq instead.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Dave Hansen @ 2010-09-28 15:17 UTC (permalink / raw)
To: Avi Kivity
Cc: linuxppc-dev, Greg KH, linux-kernel, linux-mm, KAMEZAWA Hiroyuki
In-Reply-To: <4CA1E338.6070201@redhat.com>
On Tue, 2010-09-28 at 14:44 +0200, Avi Kivity wrote:
> Why not update sysfs directory creation to be fast, for example by using
> an rbtree instead of a linked list. This fixes an implementation
> problem in the kernel instead of working around it and creating a new ABI.
>
> New ABIs mean old tools won't work, and new tools need to understand
> both ABIs.
Just to be clear _these_ patches do not change the existing ABI.
They do add a new ABI: the end_phys_index file. But, it is completely
redundant at the moment. It could be taken out of these patches.
That said, fixing the directory creation speed is probably a worthwhile
endeavor too.
-- Dave
^ permalink raw reply
* Re: [PATCH 6/8] v2 Update node sysfs code
From: Dave Hansen @ 2010-09-28 15:21 UTC (permalink / raw)
To: Robin Holt
Cc: linuxppc-dev, Greg KH, linux-kernel, linux-mm, KAMEZAWA Hiroyuki
In-Reply-To: <20100928092919.GF14068@sgi.com>
On Tue, 2010-09-28 at 04:29 -0500, Robin Holt wrote:
> Also, I don't think I much care for the weirdness that occurs if a
> memory block spans two nodes. I have not thought through how possible
> (or likely) this is, but the code certainly permits it. If that were
> the case, how would we know which sections need to be taken offline,
> etc?
Since the architecture is the one doing the memory_block_size_bytes()
override, I'd expect that the per-arch code knows enough to ensure that
this doesn't happen. It's probably something to add to the
documentation or the patch descriptions. "How should an architecture
define this? When should it be overridden?"
It's just like the question of SECTION_SIZE. What if a section spans a
node? Well, they don't because the sections are a software concept and
we _define_ them to not be able to cross nodes. If they do, just make
them smaller.
-- Dave
^ permalink raw reply
* Re: Parsing a bus fault message?
From: Ira W. Snyder @ 2010-09-28 15:31 UTC (permalink / raw)
To: david.hagood; +Cc: linuxppc-dev
In-Reply-To: <2bef2051c143a8d6e619519b222016f9.squirrel@localhost>
On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hagood@gmail.com wrote:
> I finally found my problems accessing the PPC OWBAR registers as an
> endpoint (copy/paste brown paper bag bug on my part), but I still get a
> bus fault trying to access the device.
>
> The problem is that I don't know if the fault is internal to the PPC (e.g.
> I don't have something in the chip set up) or if the fault is happening on
> the PCIe side of things.
>
> Are there any good how-tos on interpreting the kernel machine check error
> for the PPC, that might help me know where to look for the problem?
>
>
> Alternatively, can somebody see a hint in the message that I don't know
> enough to pick out? At this point, my code is trying to memcpy() from the
> PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
> either a) the ATMU is not accessible b) the ATMU is accessible but not
> mapped (which I would have thought the ioremap call I made would have
> handled) or c) the chip is not able to bus master on the PCI bus.
>
>
> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal
^^^ this is the line that contains some critical info
In the 86xx CPU manual, you should be able to find information about the
SRR1 register. Decoding the hex SRR1=0x149030 may help.
The kernel is telling you this is a TEA (transfer error acknowledge)
error. I've only seen this when I get an unhandled timeout on the local
bus. For example, a FPGA that has died in the middle of a request.
On the PCI bus, I haven't seen this error. The 83xx PCI controller is
smart enough to return 0xffffffff when reading a non-existent device.
I'm only familiar with 83xx, so I can't help too much on an 86xx board.
My best advice is: check your addresses. Make sure they're correct.
I assume that PCI on 86xx behaves similarly to 83xx. If you read from an
outbound window, your access gets translated into a PCI address and goes
onto the PCI bus. A good way of testing this is with the devmem utility
(part of busybox). It allows you to read/write any physical memory
location.
Using devmem will help you determine if the problem is in your code or
in your setup procedure.
I hope it helps,
Ira
> Oops: Machine check, sig: 7 [#1]
> SMP NR_CPUS=2 EP8641A
> Modules linked in: Endpoint_driver rionetlink
> NIP: c0014e80 LR: f102d434 CTR: 00000200
> REGS: ef05fdf0 TRAP: 0200 Not tainted (2.6.26.2-ep1.10)
> MSR: 00149030 <EE,ME,IR,DR> CR: 24004482 XER: 00000000
> TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0
> GPR00: 00000000 ef05fea0 ef05b310 eed06000 f14dfffc 00001000 eed05ffc
> 80000000
> GPR08: 00000000 00000000 00001000 c0014e60 00001000 100a7264 0ffff100
> 00000001
> GPR16: ffffffff 004005b4 007fff00 c0290000 c02f0000 ef05ff20 bfba5978
> eed06000
> GPR24: eed14ce0 ef02c678 eed61910 00000000 00000000 efb8d4b0 fffffffb
> 00001000
> NIP [c0014e80] memcpy+0x20/0x9c
> LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver]
> Call Trace:
> [ef05fea0] [ef05609c] 0xef05609c (unreliable)
> [ef05feb0] [c00cf2c0] read+0xd8/0x1c8
> [ef05fef0] [c007ff40] vfs_read+0xcc/0x16c
> [ef05ff10] [c008074c] sys_read+0x4c/0x90
> [ef05ff40] [c0011174] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff697f0
> LR = 0x10007008
> Instruction dump:
> 4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
> 70c00003 7ce903a6 40820054 80e40004 <85040008> 90e60004 95060008 4200fff0
> ---[ end trace e0620da52f69882d ]---
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/8] v2 De-Couple sysfs memory directories from memory sections
From: Avi Kivity @ 2010-09-28 16:34 UTC (permalink / raw)
To: Robin Holt
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <20100928151218.GJ14068@sgi.com>
On 09/28/2010 05:12 PM, Robin Holt wrote:
> > Why not update sysfs directory creation to be fast, for example by
> > using an rbtree instead of a linked list. This fixes an
> > implementation problem in the kernel instead of working around it
> > and creating a new ABI.
>
> Because the old ABI creates 129,000+ entries inside
> /sys/devices/system/memory with their associated links from
> /sys/devices/system/node/node*/ back to those directory entries.
>
> Thankfully things like rpm, hald, and other miscellaneous commands scan
> that information. On our 8 TB test machine, hald runs continuously
> following boot for nearly an hour mostly scanning useless information
> from /sys/
I see - so the problem wasn't just kernel internal; the ABI itself was
unsuitable. Too bad this wasn't considered at the time it was added.
(129k entries / 1 hour = 35 entries/sec; not very impressive)
--
error compiling committee.c: too many arguments to function
^ 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