* Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Kim Phillips @ 2009-12-16 22:41 UTC (permalink / raw)
To: Vishnu Suresh
Cc: herbert, B04825, linux-kernel, linux-raid, linuxppc-dev,
linux-crypto, Dipen Dudhat, dan.j.williams, Maneesh Gupta, R58472
In-Reply-To: <1260977698-4076-1-git-send-email-Vishnu@freescale.com>
On Wed, 16 Dec 2009 21:04:58 +0530
Vishnu Suresh <Vishnu@freescale.com> wrote:
> Expose Talitos's XOR functionality to be used for
> RAID Parity calculation via the Async_tx layer.
>
> Known Issue:
> When used with fsldma, random crashes are observed
> on some platforms. Hence, inter-operability with fsldma
> is currently disabled
>
> Thanks to Surender Kumar and Lee Nipper for their help in
> realising this driver
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
> Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
> ---
> Changes with respect to v1 as per comments received
> o. Rebased to linux-next as of 20091216
> o. The selection is based exclusive of fsldma
> o. Intoduced a new Kernel Configuration variable
> *. This enables selecting the Cryptographic functionality
> of Talitos along with fsldma.
> *. Disables the XOR parity calculation offload, if fsldma enabled
> either as kernel in-built or as a module
> *. Once the inter-operability with fsldma is resolved, this option
> can be removed
wait, why can't the interoperability bug be fixed in the first place?
Kim
^ permalink raw reply
* Re: AltiVec in the kernel
From: Sebastian Andrzej Siewior @ 2009-12-16 22:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Simon Richter, linuxppc-dev
In-Reply-To: <200912111649.25617.arnd@arndb.de>
* Arnd Bergmann | 2009-12-11 16:49:25 [+0100]:
>On Friday 11 December 2009, Simon Richter wrote:
>> Hi,
>>
>> since there has been a thread on allowing the use of a coprocessor in
>> the kernel already: I am wondering if it'd make sense to use AltiVec for
>> AES in dm-crypt, and how difficult it would be to implement that.
>>
>> I'm using a PegasosII which has a G4 running at 1 GHz; I get around 3
>> MB/s throughput when accessing harddisks. I think that could be
>> improved.
>>
>> If I understand correctly, the actual encryption work runs in a kernel
>> thread, which is scheduled normally, so it ought to be possible to
>> enable AltiVec for that thread; am I missing something here?
dm-crypt is async these days so the patches Arnd mentioned could be
used actually :) I've never tested them with dm-crypt but it should
work. Back then I had around 20MiB/sec encryption and around 15 MiB/sec
for decryption on 4KiB page on a PS3 [0]. This was pure testing, no
subsystem was involved. dm-crypt will feed multiple 512 byte requests.
And according [1] 512 bytes are aren't slow :) However [2] says that
that AltiVec was always slower than the generic implementation. Maybe
PS3's AltiVec unit was slower than the average one because everyone was
focuesed on the SPUs. Maybe not and you get similar results.
>Sebastian Siewior has implemented this some time ago:
>
>http://old.nabble.com/-RFC-0-3--Experiments-with-AES-AltiVec,-part-2-tc10034255.html
>
>You can try the old patches on your machine to see if they are any good
>there.
Ah you remember :)
[0] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-46002r2
[1] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-46004r4
[2] http://diploma-thesis.siewior.net/html/diplomarbeitch4.html#x12-47017r5
>
> Arnd <><
Sebastian
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Jesse Barnes @ 2009-12-16 22:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1260341533.16132.20.camel@pasglop>
On Wed, 09 Dec 2009 17:52:13 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The cardbus code creates PCI devices without ever going through the
> necessary fixup bits and pieces that normal PCI devices go through.
>
> There's in fact a commented out call to pcibios_fixup_bus() in there,
> it's commented because ... it doesn't work.
>
> I could make pcibios_fixup_bus() do the right thing on powerpc easily
> but I felt it cleaner instead to provide a specific hook
> pci_fixup_cardbus for which a weak empty implementation is provided
> by the PCI core.
>
> This fixes cardbus on powerbooks and probably all other PowerPC
> platforms which was broken completely for ever on some platforms and
> since 2.6.31 on others such as PowerBooks when we made the DMA ops
> mandatory (since those are setup by the fixups).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Note: In the long run we might want to streamline the hooks for fixing
> up new devices vs. new busses and make some stuff common between
> cardbus and PCI hotplug which is actually a mess.
>
> This is a quick fix that makes it work again in the meantime, and that
> I would like to see in 2.6.31 and 2.6.32 stable at least.
>
> Another option if you prefer is I can make my pcibios_fixup_bus() do
> the right thing in all cases I believe (by testing bus->is_added to
> skip stuff that must not be done twice) and we can remove the comment
> and stick the call in #ifdef CONFIG_PPC but I felt that solution was
> a tad cleaner.
>
> Olof, once that's in you should be able to remove the hack you have in
> the PA-Semi code to work around this.
>
Oops, looks like this fails for the modular case? I get an unresolved
symbol error when building this with my default config...
Care to resend with the fix against my for-linus branch?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] cardbus: Add a fixup hook and fix powerpc
From: Jesse Barnes @ 2009-12-16 19:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linux-pci, blofeldus, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1260341533.16132.20.camel@pasglop>
On Wed, 09 Dec 2009 17:52:13 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The cardbus code creates PCI devices without ever going through the
> necessary fixup bits and pieces that normal PCI devices go through.
>
> There's in fact a commented out call to pcibios_fixup_bus() in there,
> it's commented because ... it doesn't work.
>
> I could make pcibios_fixup_bus() do the right thing on powerpc easily
> but I felt it cleaner instead to provide a specific hook
> pci_fixup_cardbus for which a weak empty implementation is provided
> by the PCI core.
>
> This fixes cardbus on powerbooks and probably all other PowerPC
> platforms which was broken completely for ever on some platforms and
> since 2.6.31 on others such as PowerBooks when we made the DMA ops
> mandatory (since those are setup by the fixups).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Applied, thanks. Had to fix up a conflict since someone had "helpfully"
changed the comment from a // to a /* .. */ in cardbus.c.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] powerpc: fix cpu name in show-cpuinfo
From: Michael Wolf @ 2009-12-16 17:53 UTC (permalink / raw)
To: linuxppc-dev
When looking at /proc/cpuinfo the cpuname will be 'unknown"
if the pvr mask is 0. This is the case for the kernel running
on new or unknown hardware. However the cpuname is always specified
so use the name regardless of the pvr mask.
Signed-off-by: Mike Wolf <mjw@us.ibm.com>
---
--- mainline.orig/arch/powerpc/kernel/setup-common.c 2009-12-15
11:33:36.000000000 -0600
+++ mainline/arch/powerpc/kernel/setup-common.c 2009-12-16
11:26:26.000000000 -0600
@@ -219,7 +219,7 @@
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "cpu\t\t: ");
- if (cur_cpu_spec->pvr_mask)
+ if (cur_cpu_spec->cpu_name)
seq_printf(m, "%s", cur_cpu_spec->cpu_name);
else
seq_printf(m, "unknown (%08x)", pvr);
^ permalink raw reply
* [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
From: Vishnu Suresh @ 2009-12-16 15:34 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams,
linux-crypto, herbert
Cc: R58472, B04825, Vishnu Suresh, Dipen Dudhat, Maneesh Gupta
Expose Talitos's XOR functionality to be used for
RAID Parity calculation via the Async_tx layer.
Known Issue:
When used with fsldma, random crashes are observed
on some platforms. Hence, inter-operability with fsldma
is currently disabled
Thanks to Surender Kumar and Lee Nipper for their help in
realising this driver
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v1 as per comments received
o. Rebased to linux-next as of 20091216
o. The selection is based exclusive of fsldma
o. Intoduced a new Kernel Configuration variable
*. This enables selecting the Cryptographic functionality
of Talitos along with fsldma.
*. Disables the XOR parity calculation offload, if fsldma enabled
either as kernel in-built or as a module
*. Once the inter-operability with fsldma is resolved, this option
can be removed
drivers/crypto/Kconfig | 9 +
drivers/crypto/talitos.c | 402 +++++++++++++++++++++++++++++++++++++++++++++-
drivers/crypto/talitos.h | 2 +
3 files changed, 412 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..f8a6376 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -203,6 +203,15 @@ config CRYPTO_DEV_TALITOS
To compile this driver as a module, choose M here: the module
will be called talitos.
+config CRYPTO_DEV_TALITOS_RAIDXOR
+ bool "Talitos RAID5 XOR Calculation Offload"
+ select DMA_ENGINE
+ depends on CRYPTO_DEV_TALITOS
+ depends on FSL_DMA=n
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC) to
+ offload RAID XOR parity Calculation
+
config CRYPTO_DEV_IXP4XX
tristate "Driver for IXP4xx crypto hardware acceleration"
depends on ARCH_IXP4XX
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c47ffe8..e63b25a 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1,7 +1,7 @@
/*
* talitos - Freescale Integrated Security Engine (SEC) device driver
*
- * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008-2009 Freescale Semiconductor, Inc.
*
* Scatterlist Crypto API glue code copied from files with the following:
* Copyright (c) 2006-2007 Herbert Xu <herbert@gondor.apana.org.au>
@@ -37,6 +37,8 @@
#include <linux/io.h>
#include <linux/spinlock.h>
#include <linux/rtnetlink.h>
+#include <linux/dmaengine.h>
+#include <linux/raid/xor.h>
#include <crypto/algapi.h>
#include <crypto/aes.h>
@@ -140,6 +142,10 @@ struct talitos_private {
/* hwrng device */
struct hwrng rng;
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /* XOR Device */
+ struct dma_device dma_dev_common;
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
};
/* .features flag */
@@ -684,6 +690,375 @@ static void talitos_unregister_rng(struct device *dev)
hwrng_unregister(&priv->rng);
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+/*
+ * async_tx interface for XOR-capable SECs
+ *
+ * Dipen Dudhat <Dipen.Dudhat@freescale.com>
+ * Maneesh Gupta <Maneesh.Gupta@freescale.com>
+ * Vishnu Suresh <Vishnu@freescale.com>
+ */
+
+/**
+ * talitos_xor_chan - context management for the async_tx channel
+ * @completed_cookie: the last completed cookie
+ * @desc_lock: lock for tx queue
+ * @total_desc: number of descriptors allocated
+ * @submit_q: queue of submitted descriptors
+ * @pending_q: queue of pending descriptors
+ * @in_progress_q: queue of descriptors in progress
+ * @free_desc: queue of unused descriptors
+ * @dev: talitos device implementing this channel
+ * @common: the corresponding xor channel in async_tx
+ */
+struct talitos_xor_chan {
+ dma_cookie_t completed_cookie;
+ spinlock_t desc_lock;
+ unsigned int total_desc;
+ struct list_head submit_q;
+ struct list_head pending_q;
+ struct list_head in_progress_q;
+ struct list_head free_desc;
+ struct device *dev;
+ struct dma_chan common;
+};
+
+/**
+ * talitos_xor_desc - software xor descriptor
+ * @async_tx: the referring async_tx descriptor
+ * @node:
+ * @hwdesc: h/w descriptor
+ */
+struct talitos_xor_desc {
+ struct dma_async_tx_descriptor async_tx;
+ struct list_head tx_list;
+ struct list_head node;
+ struct talitos_desc hwdesc;
+};
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ dma_cookie_t *done,
+ dma_cookie_t *used)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan->cookie;
+ last_complete = xor_chan->completed_cookie;
+
+ if (done)
+ *done = last_complete;
+
+ if (used)
+ *used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error)
+{
+ struct talitos_xor_desc *desc = context;
+ struct talitos_xor_chan *xor_chan;
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ if (unlikely(error)) {
+ dev_err(dev, "xor operation: talitos error %d\n", error);
+ BUG();
+ }
+
+ xor_chan = container_of(desc->async_tx.chan, struct talitos_xor_chan,
+ common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ if (xor_chan->completed_cookie < desc->async_tx.cookie)
+ xor_chan->completed_cookie = desc->async_tx.cookie;
+
+ callback = desc->async_tx.callback;
+ callback_param = desc->async_tx.callback_param;
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ if (callback)
+ callback(callback_param);
+
+ /* run dependent operations */
+ dma_run_dependencies(&desc->async_tx);
+}
+
+static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
+{
+ struct talitos_xor_desc *desc, *_desc;
+
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ if (talitos_submit(xor_chan->dev, &desc->hwdesc,
+ talitos_release_xor, desc) != -EINPROGRESS)
+ break;
+
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->in_progress_q);
+ }
+ spin_unlock_bh(&xor_chan->desc_lock);
+}
+
+/**
+ * talitos_issue_pending - move the descriptors in submit
+ * queue to pending queue and submit them for processing
+ * @chan: DMA channel
+ */
+static void talitos_issue_pending(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_tail_init(&xor_chan->submit_q,
+ &xor_chan->pending_q);
+ spin_unlock_bh(&xor_chan->desc_lock);
+ talitos_process_pending(xor_chan);
+}
+
+static dma_cookie_t talitos_async_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct talitos_xor_desc *desc;
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t cookie;
+
+ desc = container_of(tx, struct talitos_xor_desc, async_tx);
+ xor_chan = container_of(tx->chan, struct talitos_xor_chan, common);
+
+ cookie = xor_chan->common.cookie + 1;
+ if (cookie < 0)
+ cookie = 1;
+
+ desc->async_tx.cookie = cookie;
+ xor_chan->common.cookie = desc->async_tx.cookie;
+
+ list_splice_tail_init(&desc->tx_list,
+ &xor_chan->submit_q);
+
+ return cookie;
+}
+
+static struct talitos_xor_desc *talitos_xor_alloc_descriptor(
+ struct talitos_xor_chan *xor_chan, gfp_t flags)
+{
+ struct talitos_xor_desc *desc;
+
+ desc = kmalloc(sizeof(*desc), flags);
+ if (desc) {
+ xor_chan->total_desc++;
+ memset(desc, 0, sizeof(*desc));
+ dma_async_tx_descriptor_init(&desc->async_tx, &xor_chan->common);
+ desc->async_tx.tx_submit = talitos_async_tx_submit;
+ INIT_LIST_HEAD(&desc->node);
+ INIT_LIST_HEAD(&desc->tx_list);
+ }
+
+ return desc;
+}
+
+static void talitos_free_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc, *_desc;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ list_for_each_entry_safe(desc, _desc, &xor_chan->submit_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->in_progress_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->free_desc, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ BUG_ON(unlikely(xor_chan->total_desc)); /* Some descriptor not freed? */
+}
+
+static int talitos_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc;
+ LIST_HEAD(tmp_list);
+ int i;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc))
+ return xor_chan->total_desc;
+
+ /* 256 initial descriptors */
+ for (i = 0; i < 256; i++) {
+ desc = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ if (!desc) {
+ dev_err(xor_chan->common.device->dev,
+ "Only %d initial descriptors\n", i);
+ break;
+ }
+ list_add_tail(&desc->node, &tmp_list);
+ }
+
+ if (!i)
+ return -ENOMEM;
+
+ /* At least one desc is allocated */
+ list_splice_init(&tmp_list, &xor_chan->free_desc);
+
+ return xor_chan->total_desc;
+}
+
+static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+ unsigned int src_cnt, size_t len, unsigned long flags)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *new;
+ struct talitos_desc *desc;
+ int i, j;
+
+ BUG_ON(unlikely(len > TALITOS_MAX_DATA_LEN));
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc)) {
+ new = container_of(xor_chan->free_desc.next,
+ struct talitos_xor_desc, node);
+ list_del(&new->node);
+ } else {
+ new = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ }
+
+ if (!new) {
+ dev_err(xor_chan->common.device->dev,
+ "No free memory for XOR DMA descriptor\n");
+ return NULL;
+ }
+
+ desc = &new->hwdesc;
+ /* Set destination: Last pointer pair */
+ to_talitos_ptr(&desc->ptr[6], dest);
+ desc->ptr[6].len = cpu_to_be16(len);
+ desc->ptr[6].j_extent = 0;
+
+ /* Set Sources: End loading from second-last pointer pair */
+ for (i = 5, j = 0; (j < src_cnt) && (i > 0); i--, j++) {
+ to_talitos_ptr(&desc->ptr[i], src[j]);
+ desc->ptr[i].len = cpu_to_be16(len);
+ desc->ptr[i].j_extent = 0;
+ }
+
+ /*
+ * documentation states first 0 ptr/len combo marks end of sources
+ * yet device produces scatter boundary error unless all subsequent
+ * sources are zeroed out
+ */
+ for (; i >= 0; i--) {
+ to_talitos_ptr(&desc->ptr[i], 0);
+ desc->ptr[i].len = 0;
+ desc->ptr[i].j_extent = 0;
+ }
+
+ desc->hdr = DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XOR
+ | DESC_HDR_TYPE_RAID_XOR;
+
+ list_add_tail(&new->node, &new->tx_list);
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ return &new->async_tx;
+}
+
+static void talitos_unregister_async_xor(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct talitos_xor_chan *xor_chan;
+ struct dma_chan *chan;
+
+ if (priv->dma_dev_common.chancnt)
+ dma_async_device_unregister(&priv->dma_dev_common);
+
+ list_for_each_entry(chan, &priv->dma_dev_common.channels, device_node) {
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ list_del(&chan->device_node);
+ priv->dma_dev_common.chancnt--;
+ kfree(xor_chan);
+ }
+}
+
+/**
+ * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
+ * It is registered as a DMA device with the capability to perform
+ * XOR operation with the Async_tx layer.
+ * The various queues and channel resources are also allocated.
+ */
+static int talitos_register_async_tx(struct device *dev, int max_xor_srcs)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct dma_device *dma_dev = &priv->dma_dev_common;
+ struct talitos_xor_chan *xor_chan;
+ int err;
+
+ xor_chan = kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
+ if (!xor_chan) {
+ dev_err(dev, "unable to allocate xor channel\n");
+ return -ENOMEM;
+ }
+
+ dma_dev->dev = dev;
+ dma_dev->device_alloc_chan_resources = talitos_alloc_chan_resources;
+ dma_dev->device_free_chan_resources = talitos_free_chan_resources;
+ dma_dev->device_prep_dma_xor = talitos_prep_dma_xor;
+ dma_dev->max_xor = max_xor_srcs;
+ dma_dev->device_is_tx_complete = talitos_is_tx_complete;
+ dma_dev->device_issue_pending = talitos_issue_pending;
+ INIT_LIST_HEAD(&dma_dev->channels);
+ dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+
+ xor_chan->dev = dev;
+ xor_chan->common.device = dma_dev;
+ xor_chan->total_desc = 0;
+ INIT_LIST_HEAD(&xor_chan->submit_q);
+ INIT_LIST_HEAD(&xor_chan->pending_q);
+ INIT_LIST_HEAD(&xor_chan->in_progress_q);
+ INIT_LIST_HEAD(&xor_chan->free_desc);
+ spin_lock_init(&xor_chan->desc_lock);
+
+ list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
+ dma_dev->chancnt++;
+
+ err = dma_async_device_register(dma_dev);
+ if (err) {
+ dev_err(dev, "Unable to register XOR with Async_tx\n");
+ goto err_out;
+ }
+
+ return err;
+
+err_out:
+ talitos_unregister_async_xor(dev);
+ return err;
+}
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
/*
* crypto alg
*/
@@ -1768,6 +2143,10 @@ static int talitos_remove(struct of_device *ofdev)
tasklet_kill(&priv->done_task);
iounmap(priv->reg);
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ if (priv->dma_dev_common.chancnt)
+ talitos_unregister_async_xor(dev);
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
dev_set_drvdata(dev, NULL);
@@ -1926,6 +2305,27 @@ static int talitos_probe(struct of_device *ofdev,
dev_info(dev, "hwrng\n");
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /*
+ * register with async_tx xor, if capable
+ * SEC 2.x support up to 3 RAID sources,
+ * SEC 3.x support up to 6
+ */
+ if (hw_supports(dev, DESC_HDR_SEL0_AESU | DESC_HDR_TYPE_RAID_XOR)) {
+ int max_xor_srcs = 3;
+ if (of_device_is_compatible(np, "fsl,sec3.0"))
+ max_xor_srcs = 6;
+
+ err = talitos_register_async_tx(dev, max_xor_srcs);
+ if (err) {
+ dev_err(dev, "failed to register async_tx xor: %d\n",
+ err);
+ goto err_out;
+ }
+ dev_info(dev, "max_xor_srcs %d\n", max_xor_srcs);
+ }
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
+
/* register crypto algorithms the device supports */
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index ff5a145..b6197bc 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -155,6 +155,7 @@
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
+#define DESC_HDR_MODE0_AESU_XOR cpu_to_be32(0x0c600000)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
#define DESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x00200000)
#define DESC_HDR_MODE0_MDEU_INIT cpu_to_be32(0x01000000)
@@ -202,6 +203,7 @@
#define DESC_HDR_TYPE_IPSEC_ESP cpu_to_be32(1 << 3)
#define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU cpu_to_be32(2 << 3)
#define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU cpu_to_be32(4 << 3)
+#define DESC_HDR_TYPE_RAID_XOR cpu_to_be32(21 << 3)
/* link table extent field bits */
#define DESC_PTR_LNKTBL_JUMP 0x80
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2 1/2] fsldma: Delete DMA_INTERRUPT capability
From: Vishnu Suresh @ 2009-12-16 15:34 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams
Cc: Vishnu Suresh, B04825, R58472
The DMA_INTERRUPT is a NULL transfer, triggering a
Programming Error. Though this Error is handled in
the driver with the fix given in "fsldma: Fix the DMA
halt when using DMA_INTERRUPT async_tx transfer."
<f79abb627f033c85a6088231f20c85bc4a9bd757>,
the RAID5 operation, which initiated the transaction
via Async_tx, hangs.
Hence, this patch removes the DMA_INTERRUPT capability
and the associated code from the driver.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v1
o. Rebased to linux-next as of 20091216
drivers/dma/fsldma.c | 31 -------------------------------
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 296f9e7..272097a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -449,35 +449,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *chan)
fsl_chan->desc_pool = NULL;
}
-static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *chan, unsigned long flags)
-{
- struct fsl_dma_chan *fsl_chan;
- struct fsl_desc_sw *new;
-
- if (!chan)
- return NULL;
-
- fsl_chan = to_fsl_chan(chan);
-
- new = fsl_dma_alloc_descriptor(fsl_chan);
- if (!new) {
- dev_err(fsl_chan->dev, "No free memory for link descriptor\n");
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list*/
- set_ld_eol(fsl_chan, new);
-
- return &new->async_tx;
-}
-
static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dest, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1200,11 +1171,9 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
- fdev->reg.start + 1);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
--
1.6.4.2
^ permalink raw reply related
* [PATCH 1/5] powerpc/iseries: use DECLARE_COMPLETION_ONSTACK for non-constant completion
From: Yong Zhang @ 2009-12-16 14:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1260974161-6934-1-git-send-email-yong.zhang0@gmail.com>
The _ONSTACK variant should be used for on-stack completion,
otherwise it will break lockdep.
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/platforms/iseries/viopath.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/viopath.c b/arch/powerpc/platforms/iseries/viopath.c
index 49ff4dc..5aea94f 100644
--- a/arch/powerpc/platforms/iseries/viopath.c
+++ b/arch/powerpc/platforms/iseries/viopath.c
@@ -116,7 +116,7 @@ static int proc_viopath_show(struct seq_file *m, void *v)
u16 vlanMap;
dma_addr_t handle;
HvLpEvent_Rc hvrc;
- DECLARE_COMPLETION(done);
+ DECLARE_COMPLETION_ONSTACK(done);
struct device_node *node;
const char *sysid;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] pata_mpc52xx: optimizing code size by change of ATA timing data types
From: Roman Fietze @ 2009-12-16 13:29 UTC (permalink / raw)
To: linuxppc-dev
Hello Everybody,
A totally simple patch that reduces the text size as of the
ppc_6xx-size command of pata_mpc52xx by more than 10%, by reducing the
rodata size from 0x4a4 to 0x17e bytes. This is simply done by changing
the data types of the ATA timing constants.
If you are interested at all, and it's worth the trouble, here the
details:
ppc_6xx-size:
text data bss dec hex filename
old: 6532 1068 0 7600 1db0 pata_mpc52xx.o
new: 5718 1068 0 6786 1a82 pata_mpc52xx.o
The (assembler) code itself doesn't really change very much. I double
checked the final results inside mpc52xx_ata_apply_timings() and they
match.
BTW: Should I break lines at col 72 or 80?
=46rom: Roman Fietze <roman.fietze@telemotive.de>
Date: Wed, 16 Dec 2009 13:10:31 +0100
Subject: [PATCH] pata_mpc52xx: reduce code size by simple change of constan=
t data types
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
=2D--
drivers/ata/pata_mpc52xx.c | 78 ++++++++++++++++++++++------------------=
=2D---
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index 2bc2dbe..e4e5e82 100644
=2D-- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -64,13 +64,13 @@ struct mpc52xx_ata_priv {
=20
=20
/* ATAPI-4 PIO specs (in ns) */
=2Dstatic const int ataspec_t0[5] =3D {600, 383, 240, 180, 120};
=2Dstatic const int ataspec_t1[5] =3D { 70, 50, 30, 30, 25};
=2Dstatic const int ataspec_t2_8[5] =3D {290, 290, 290, 80, 70};
=2Dstatic const int ataspec_t2_16[5] =3D {165, 125, 100, 80, 70};
=2Dstatic const int ataspec_t2i[5] =3D { 0, 0, 0, 70, 25};
=2Dstatic const int ataspec_t4[5] =3D { 30, 20, 15, 10, 10};
=2Dstatic const int ataspec_ta[5] =3D { 35, 35, 35, 35, 35};
+static const u16 ataspec_t0[5] =3D {600, 383, 240, 180, 120};
+static const u16 ataspec_t1[5] =3D { 70, 50, 30, 30, 25};
+static const u16 ataspec_t2_8[5] =3D {290, 290, 290, 80, 70};
+static const u16 ataspec_t2_16[5] =3D {165, 125, 100, 80, 70};
+static const u16 ataspec_t2i[5] =3D { 0, 0, 0, 70, 25};
+static const u16 ataspec_t4[5] =3D { 30, 20, 15, 10, 10};
+static const u16 ataspec_ta[5] =3D { 35, 35, 35, 35, 35};
=20
#define CALC_CLKCYC(c,v) ((((v)+(c)-1)/(c)))
=20
@@ -78,13 +78,13 @@ static const int ataspec_ta[5] =3D { 35, 35, 35, =
35, 35};
=20
/* ATAPI-4 MDMA specs (in clocks) */
struct mdmaspec {
=2D u32 t0M;
=2D u32 td;
=2D u32 th;
=2D u32 tj;
=2D u32 tkw;
=2D u32 tm;
=2D u32 tn;
+ u8 t0M;
+ u8 td;
+ u8 th;
+ u8 tj;
+ u8 tkw;
+ u8 tm;
+ u8 tn;
};
=20
static const struct mdmaspec mdmaspec66[3] =3D {
@@ -101,23 +101,23 @@ static const struct mdmaspec mdmaspec132[3] =3D {
=20
/* ATAPI-4 UDMA specs (in clocks) */
struct udmaspec {
=2D u32 tcyc;
=2D u32 t2cyc;
=2D u32 tds;
=2D u32 tdh;
=2D u32 tdvs;
=2D u32 tdvh;
=2D u32 tfs;
=2D u32 tli;
=2D u32 tmli;
=2D u32 taz;
=2D u32 tzah;
=2D u32 tenv;
=2D u32 tsr;
=2D u32 trfs;
=2D u32 trp;
=2D u32 tack;
=2D u32 tss;
+ u8 tcyc;
+ u8 t2cyc;
+ u8 tds;
+ u8 tdh;
+ u8 tdvs;
+ u8 tdvh;
+ u8 tfs;
+ u8 tli;
+ u8 tmli;
+ u8 taz;
+ u8 tzah;
+ u8 tenv;
+ u8 tsr;
+ u8 trfs;
+ u8 trp;
+ u8 tack;
+ u8 tss;
};
=20
static const struct udmaspec udmaspec66[6] =3D {
@@ -270,7 +270,7 @@ mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv=
*priv, int dev, int pio)
{
struct mpc52xx_ata_timings *timing =3D &priv->timings[dev];
unsigned int ipb_period =3D priv->ipb_period;
=2D unsigned int t0, t1, t2_8, t2_16, t2i, t4, ta;
+ u32 t0, t1, t2_8, t2_16, t2i, t4, ta;
=20
if ((pio < 0) || (pio > 4))
return -EINVAL;
@@ -299,8 +299,8 @@ mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_pri=
v *priv, int dev,
if (speed < 0 || speed > 2)
return -EINVAL;
=20
=2D t->mdma1 =3D (s->t0M << 24) | (s->td << 16) | (s->tkw << 8) | (s->tm);
=2D t->mdma2 =3D (s->th << 24) | (s->tj << 16) | (s->tn << 8);
+ t->mdma1 =3D ((u32)s->t0M << 24) | ((u32)s->td << 16) | ((u32)s->tkw << 8=
) | s->tm;
+ t->mdma2 =3D ((u32)s->th << 24) | ((u32)s->tj << 16) | ((u32)s->tn << 8);
t->using_udma =3D 0;
=20
return 0;
@@ -316,11 +316,11 @@ mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_p=
riv *priv, int dev,
if (speed < 0 || speed > 2)
return -EINVAL;
=20
=2D t->udma1 =3D (s->t2cyc << 24) | (s->tcyc << 16) | (s->tds << 8) | s->td=
h;
=2D t->udma2 =3D (s->tdvs << 24) | (s->tdvh << 16) | (s->tfs << 8) | s->tli;
=2D t->udma3 =3D (s->tmli << 24) | (s->taz << 16) | (s->tenv << 8) | s->tsr;
=2D t->udma4 =3D (s->tss << 24) | (s->trfs << 16) | (s->trp << 8) | s->tack;
=2D t->udma5 =3D (s->tzah << 24);
+ t->udma1 =3D ((u32)s->t2cyc << 24) | ((u32)s->tcyc << 16) | ((u32)s->tds =
<< 8) | s->tdh;
+ t->udma2 =3D ((u32)s->tdvs << 24) | ((u32)s->tdvh << 16) | ((u32)s->tfs <=
< 8) | s->tli;
+ t->udma3 =3D ((u32)s->tmli << 24) | ((u32)s->taz << 16) | ((u32)s->tenv <=
< 8) | s->tsr;
+ t->udma4 =3D ((u32)s->tss << 24) | ((u32)s->trfs << 16) | ((u32)s->trp <<=
8) | s->tack;
+ t->udma5 =3D (u32)s->tzah << 24;
t->using_udma =3D 1;
=20
return 0;
=2D-=20
1.6.5.3
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 12:27 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B28CBC4.4010501@embedded-sol.com>
> From: Felix Radensky [mailto:felix@embedded-sol.com]=20
> Sent: Wednesday, December 16, 2009 5:30 PM
> > As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for this=20
> > ctlr, which is the exactly the case with other SoC's p2020ds,=20
> > mpc8536ds, mpc8572ds. To me it seems like a board issue and=20
> it needs=20
> > to be followed up.
> >
> > I plugged in ralink rt2860 pcie wirless card in the=20
> mini-pcie slot of=20
> > p2020rdb, which ran fine becaused it used MSI by default.
> > How hard is it to enable MSI in the atheros wireless driver.
> >
> > =20
>=20
> I've enabled MSI in ath9k driver, by simply adding=20
> pci_enable_msi() and
> pci_disable_msi() at relevant places. The MSI interrupt is allocated.
>=20
> irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 18
> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:=20
> mem=3D0xf2160000, irq=3D18
>=20
> cat /proc/interrupts
> CPU0
> 18: 0 FSL-MSI Edge ath9k
>=20
> lspci -v shows that MSI was enabled on device
>=20
> But I don't get any interrupts. I've posted a question to=20
> ath9k list, maybe folks there will have some ideas.
I just noticed a MSI enable bit in drivers/net/wireless/ath/ath9k/reg.h=20
as under, may be we need to trun this on:-
reg.h:1013:#define AR_PCIE_MSI 0x4094
reg.h:1014:#define AR_PCIE_MSI_ENABLE 0x00000001
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-16 12:00 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A6076776@zin33exm23.fsl.freescale.net>
Mahajan Vivek-B08308 wrote:
>> From: Felix Radensky [mailto:felix@embedded-sol.com]
>> Sent: Wednesday, December 16, 2009 2:56 PM
>> To: Mahajan Vivek-B08308
>> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
>> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>>
>> Hi,
>>
>>> Looks like INTA is not being routed to IRQ0 properly for this PCIe
>>> ctlr. Try changing the interrupt-map prop for the ctlr at
>>>
>> 0xffe0a000
>>
>>> to the following, temporarily:-
>>>
>>> interrupt-map = <
>>> /* IDSEL 0x0 */
>>> 0000 0x0 0x0 0x1 &mpic 0x1 0x1
>>> 0000 0x0 0x0 0x2 &mpic 0x2 0x1
>>> 0000 0x0 0x0 0x3 &mpic 0x3 0x1
>>> 0000 0x0 0x0 0x4 &mpic 0x0 0x1
>>>
>>>
>> Thanks for your help. With this change "nobody cared" message
>> disappears, but interrupts are not coming at all.
>>
>> Is it a SoC problem or a board problem ?
>>
>
> As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for
> this ctlr, which is the exactly the case with other SoC's
> p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board
> issue and it needs to be followed up.
>
> I plugged in ralink rt2860 pcie wirless card in the mini-pcie
> slot of p2020rdb, which ran fine becaused it used MSI by default.
> How hard is it to enable MSI in the atheros wireless driver.
>
>
I've enabled MSI in ath9k driver, by simply adding pci_enable_msi() and
pci_disable_msi() at relevant places. The MSI interrupt is allocated.
irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 18
phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf2160000, irq=18
cat /proc/interrupts
CPU0
18: 0 FSL-MSI Edge ath9k
lspci -v shows that MSI was enabled on device
But I don't get any interrupts. I've posted a question to ath9k list,
maybe folks there
will have some ideas.
Thanks.
Felix.
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-16 11:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20091209145748.GB3112@pengutronix.de>
Hello Wolfram,
On Wednesday 09 December 2009 15:57:48 Wolfram Sang wrote:
> Do you have a way to measure performance penalties?
As I said, I do.
And here they are. They won't win a price for the most impartial
benchmarks ever seen, but thet'll be a good starting point to get a
feeling what stability might cost.
The board is using the MPC5200B on a board derived from the old
lite5200, but with the fixes for the MPC5200B. All tests are run using
an ST940813AM hard drive with an ext2 and an ext3 of 10GB each,
default mkfs options. The OS is Debian 4.0. The network connection is
between a fast Athlon XP2 6400 and the target, using 100MBit/s wiring
and a 100MBit/s switch.
The F always stands for fast settings, coherent cache, XLB features
like snooping, etc. turned on, XLB config 0x0000a006 or 0x0001a006
(makes no or no big difference).
The S always stands for slow settings, non coherent cache, XLB
features like snooping, etc. turned on, XLB config 0x80012006.
Bonnie++ V1.03:
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
=46 ext2: 256M 2676 99 14759 47 5502 24 2792 98 16201 26 136.2 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 85 99 84712 99 14517 100 86 99 114078 100 309 99
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
S ext2: 256M 2647 99 14462 56 5468 29 2778 99 15856 32 134.2 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 87 99 85872 100 15919 99 88 99 114094 99 317 99
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
=46 ext3: 256M 2461 96 13327 73 5792 29 2798 98 16213 27 133.9 3
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 2826 92 59290 99 3803 71 2778 90 114706 100 3872 74
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
S ext3: 256M 2455 97 13340 85 5533 33 2759 98 15855 32 136.7 4
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64 2774 92 59474 100 3810 74 2726 91 113937 100 3905 77
Netcat tests to or from my MPC5200B target. All times are the netcat
time -p output real/user/sys and the network data rate in MB/s. The
source data itself is either a dd from /dev/zero with bs=3D10M
count=3D1024 or a file of equal size either on an ext2 or ext3
filesystem. The destination is either /dev/null or a file on an ext2
or ext3.
Server:/dev/zero -> Target:/dev/null
F: 1594/15.3/1031 6.8
S: 1864/8.8/921 5.8
Target:/dev/zero -> Server:/dev/null
F: 1396/35.8/1361 7.7
S: 1578/51.5/1526 6.8
Server:/dev/zero -> Target:ext2
F: 1799/37.0/1721 6.0
S: 2093/42.6/2009 5.1
Target:ext2 -> Server:/dev/null
F: 2423/31.3/1030 4.4
S: 2820/15.2/1186 3.8
Server:/dev/zero -> Target:ext3
F: 2110/33.4/1912.88 5.1
S: 2397/47.5/2208.63 4.5
Target:ext3 -> Server:/dev/null
F: 2407/17.9/1016 4.5
S: 2676/15.4/1160 4.0
I repeated one or the other test and got comparable results.
And please keep in mind, that adding some more or less high load on
the SCLPC/LPC the F system crashed either right away or at least once
every few hours, depending on what we did (TX/RX, FLASH/FPGA,
SCLPC+DMA/SCLPC/CPU, ...), and depending on the concurrent load on the
=46EC and ATA. If you only need one or the other peripheral with your
system you might get away with alls the XLB fetures turned on.
Additionally to that, I got wrong data reading from FLASH or the FPGA
using SCLPC+DMA in the first few bytes with the fast settings, when I
did not manually flush or invalidate the cache prior to the DMA
submission as dma_map_single would do it in non cache coherent setups.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Porting EP852 based system from kernel 2.4.24 to 2.6.x
From: Cristiano Cortezia @ 2009-12-16 11:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
I work on a EP825 (MPC852T) based system running a 2.4.24 linux kernel
(which I didn't bring up in first place). Now I need to bring the board
alive over the latest kernel it may be possible to.
I've managed to cross-compile 2.26.32 kernel using most of the options I
could take from the existing 2.4.24 .config.
I could also download the generated uImage to the board using u-boot 1.0.2.
Uncompressed OK and then hung.
I've checked on mailing lists that the 2.6 series works with dts
(device-tree-sources). There are built-in make targets to generate images
backward compatibles with ancient u-boot versions. Then I tried one of these
targets to build a cuImage.xxx, but trying to boot from it also hangs. I
guess there is no make target that correspond to EP852.
Could someone point me some directions on what should I probably be missing
(from the very start of the "default porting procedure") ?
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 9:52 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <4B28A7C3.6040209@embedded-sol.com>
> From: Felix Radensky [mailto:felix@embedded-sol.com]=20
> Sent: Wednesday, December 16, 2009 2:56 PM
> To: Mahajan Vivek-B08308
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hi,
> >
> > Looks like INTA is not being routed to IRQ0 properly for this PCIe=20
> > ctlr. Try changing the interrupt-map prop for the ctlr at=20
> 0xffe0a000=20
> > to the following, temporarily:-
> >
> > interrupt-map =3D <
> > /* IDSEL 0x0 */
> > 0000 0x0 0x0 0x1 &mpic 0x1 0x1
> > 0000 0x0 0x0 0x2 &mpic 0x2 0x1
> > 0000 0x0 0x0 0x3 &mpic 0x3 0x1
> > 0000 0x0 0x0 0x4 &mpic 0x0 0x1
> > =20
>=20
> Thanks for your help. With this change "nobody cared" message=20
> disappears, but interrupts are not coming at all.
>=20
> Is it a SoC problem or a board problem ?
As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for=20
this ctlr, which is the exactly the case with other SoC's=20
p2020ds, mpc8536ds, mpc8572ds. To me it seems like a board=20
issue and it needs to be followed up.
I plugged in ralink rt2860 pcie wirless card in the mini-pcie=20
slot of p2020rdb, which ran fine becaused it used MSI by default.
How hard is it to enable MSI in the atheros wireless driver.
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2009-12-16 9:26 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Aggrwal Poonam-B10812
In-Reply-To: <0949C49693EF1A47A54B0F0113CDB4A607674F@zin33exm23.fsl.freescale.net>
Hi,
Mahajan Vivek-B08308 wrote:
>
>> Hi,
>>
>> I'm trying to use mini-PCI-E WLAN card on P2020RDB running
>> 2.6.32, but so far without success.
>> ath9k driver identifies the device, I can run ifconfig,
>> iwconfig and hostapd on wlan0, but device is not getting any
>> interrupts, so I suspect the interrupt configuration is
>> wrong. Atheros ath9k driver reports:
>>
>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:
>> mem=0xf1060000, irq=16
>>
>> The mapping for irq 16 is:
>>
>> irq: irq 1 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>>
>> According to /proc/interrupts:
>>
>> CPU0
>> 16: 0 OpenPIC Edge ath9k
>>
>> The same problem happens if Atheros card is plugged (with
>> adapter) into regular PCI-E slot.
>>
>> It seems that p2020rdb device tree is missing
>> interrupt-map-mask and interrupt-map properties in PCI-E nodes.
>>
>> I've tried running kernel from latest FSL BSP for this board
>> (based on 2.6.32-rc3). The device tree has the
>> interrupt-map-mask and interrupt-map properties, and
>> interrupt mapping is different:
>>
>> irq: irq 0 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>>
>> In /proc/interrups I see
>> CPU0
>> 16: 100001 OpenPIC Level ath9k
>>
>> However, when ath9k driver is loaded I get this:
>>
>> irq 16: nobody cared (try booting with the "irqpoll" option)
>> Call Trace:
>> [efbefa40] [c00074b0] show_stack+0x4c/0x16c (unreliable)
>> [efbefa70] [c0073970] __report_bad_irq+0x38/0xd0 [efbefa90]
>> [c0073bd4] note_interrupt+0x1cc/0x22c [efbefac0] [c00747d0]
>> handle_fasteoi_irq+0xf4/0x128 [efbefae0] [c0004eb8]
>> do_IRQ+0xc8/0xf4 [efbefb00] [c001081c]
>> ret_from_except+0x0/0x18 [efbefbc0] [00000000] (null)
>> [efbefc10] [c0004d24] do_softirq+0x60/0x64 [efbefc20]
>> [c0044670] irq_exit+0x88/0xa8 [efbefc30] [c0004ebc]
>> do_IRQ+0xcc/0xf4 [efbefc50] [c001081c]
>> ret_from_except+0x0/0x18 [efbefd10] [c00730b4]
>> __setup_irq+0x320/0x39c [efbefd30] [c0073214]
>> request_threaded_irq+0xe4/0x148 [efbefd60] [f2244218]
>> ath_pci_probe+0x1b0/0x3a4 [ath9k] [efbefda0] [c01c386c]
>> local_pci_probe+0x24/0x34 [efbefdb0] [c01c3bc0]
>> pci_device_probe+0x84/0xa8 [efbefde0] [c01e86b8]
>> driver_probe_device+0xa8/0x1a8 [efbefe00] [c01e8874]
>> __driver_attach+0xbc/0xc0 [efbefe20] [c01e7d88]
>> bus_for_each_dev+0x70/0xac [efbefe50] [c01e84d8]
>> driver_attach+0x24/0x34 [efbefe60] [c01e7504]
>> bus_add_driver+0xb8/0x278 [efbefe90] [c01e8bec]
>> driver_register+0x84/0x178 [efbefeb0] [c01c3e6c]
>> __pci_register_driver+0x54/0xe4 [efbefed0] [f2244434]
>> ath_pci_init+0x28/0x38 [ath9k] [efbefee0] [f215702c]
>> ath9k_init+0x2c/0x100 [ath9k] [efbefef0] [c0001d34]
>> do_one_initcall+0x3c/0x1e8 [efbeff20] [c006f9f0]
>> sys_init_module+0xf8/0x220 [efbeff40] [c00101c4]
>> ret_from_syscall+0x0/0x3c
>> handlers:
>> [<f223badc>] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #16
>>
>
> Looks like INTA is not being routed to IRQ0 properly for this
> PCIe ctlr. Try changing the interrupt-map prop for the ctlr
> at 0xffe0a000 to the following, temporarily:-
>
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0x0 0x0 0x1 &mpic 0x1 0x1
> 0000 0x0 0x0 0x2 &mpic 0x2 0x1
> 0000 0x0 0x0 0x3 &mpic 0x3 0x1
> 0000 0x0 0x0 0x4 &mpic 0x0 0x1
>
Thanks for your help. With this change "nobody cared" message disappears,
but interrupts are not coming at all.
Is it a SoC problem or a board problem ?
Thanks.
Felix.
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 9:07 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B289955.2010705@in.ibm.com>
On Wed, Dec 16, 2009 at 4:24 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Xiaotian Feng wrote:
>>
>> Could follow be possible? =C2=A0We know there's cpu 0 and cpu 1,
>>
>> offline cpu1 > done
>> offline cpu0 > false
>>
>> consider this in cpu_down code,
>>
>>
>> int __ref cpu_down(unsigned int cpu)
>> {
>> <snip>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0set_cpu_active(cpu, false); // here, we set c=
pu 0 to inactive
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0synchronize_sched();
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D _cpu_down(cpu, 0);
>> out:
>> <snip>
>> }
>>
>> Then in _cpu_down code:
>>
>> static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
>> {
>> <snip>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (num_online_cpus() =3D=3D 1) =C2=A0 =C2=A0=
=C2=A0 =C2=A0// if we're trying to
>> offline cpu0, num_online_cpus will be 1
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EBUSY; =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// aft=
er return back
>> to cpu_down, we didn't change cpu 0 back to active
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!cpu_online(cpu))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL;
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!alloc_cpumask_var(&old_allowed, GFP_KERN=
EL))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENOMEM;
>> <snip>
>> }
>>
>> Then cpu 0 is not active, but online, then we try to offline cpu1, .....=
..
>> This can not be exposed because x86 does not have
>> /sys/devices/system/cpu0/online.
>> I guess following patch fixes this bug.
>>
>
> Just tested this one on the POWER box and the test passed.
> I did not observe the hang.
Thanks for confirm, I will send formatted patch to upstream then:-)
>
> Thanks
> -Sachin
>
>> ---
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index 291ac58..21ddace 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
>> tasks_frozen)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.hcpu =3D hcpu,
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0};
>>
>> - =C2=A0 =C2=A0 =C2=A0 if (num_online_cpus() =3D=3D 1)
>> + =C2=A0 =C2=A0 =C2=A0 if (num_online_cpus() =3D=3D 1) {
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set_cpu_active(cpu, t=
rue);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EBUSY;
>> + =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!cpu_online(cpu))
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EINVAL;
>>
>> - =C2=A0 =C2=A0 =C2=A0 if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
>> + =C2=A0 =C2=A0 =C2=A0 if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))=
{
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set_cpu_active(cpu, t=
rue);
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -ENOMEM;
>> + =C2=A0 =C2=A0 =C2=A0 }
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0cpu_hotplug_begin();
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D __raw_notifier_call_chain(&cpu_chain,=
CPU_DOWN_PREPARE | mod,
>>
>>
>>
>>>
>>> Unless of course, I messed up, which appears to be rather likely given
>>> these problems ;-)
>>>
>>>
>>>
>>
>>
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 8:24 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152357m75aea5dfl6fe063d716517baf@mail.gmail.com>
Xiaotian Feng wrote:
> Could follow be possible? We know there's cpu 0 and cpu 1,
>
> offline cpu1 > done
> offline cpu0 > false
>
> consider this in cpu_down code,
>
>
> int __ref cpu_down(unsigned int cpu)
> {
> <snip>
> set_cpu_active(cpu, false); // here, we set cpu 0 to inactive
>
> synchronize_sched();
>
> err = _cpu_down(cpu, 0);
> out:
> <snip>
> }
>
> Then in _cpu_down code:
>
> static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
> {
> <snip>
> if (num_online_cpus() == 1) // if we're trying to
> offline cpu0, num_online_cpus will be 1
> return -EBUSY; // after return back
> to cpu_down, we didn't change cpu 0 back to active
>
> if (!cpu_online(cpu))
> return -EINVAL;
>
> if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
> return -ENOMEM;
> <snip>
> }
>
> Then cpu 0 is not active, but online, then we try to offline cpu1, .......
> This can not be exposed because x86 does not have
> /sys/devices/system/cpu0/online.
> I guess following patch fixes this bug.
>
Just tested this one on the POWER box and the test passed.
I did not observe the hang.
Thanks
-Sachin
> ---
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 291ac58..21ddace 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
> tasks_frozen)
> .hcpu = hcpu,
> };
>
> - if (num_online_cpus() == 1)
> + if (num_online_cpus() == 1) {
> + set_cpu_active(cpu, true);
> return -EBUSY;
> + }
>
> if (!cpu_online(cpu))
> return -EINVAL;
>
> - if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
> + if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL)) {
> + set_cpu_active(cpu, true);
> return -ENOMEM;
> + }
>
> cpu_hotplug_begin();
> err = __raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE | mod,
>
>
>
>> Unless of course, I messed up, which appears to be rather likely given
>> these problems ;-)
>>
>>
>>
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 7:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Linux/PPC Development, linux-next, Ingo Molnar
In-Reply-To: <1260947890.8023.1281.camel@laptop>
On Wed, Dec 16, 2009 at 3:18 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
>> Xiaotian Feng wrote:
>> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
>> >
>> >> Xiaotian Feng wrote:
>> >>
>> >>> Does this testcase hotplug cpu 0 off?
>> >>>
>> >>>
>> >> No, i don't think so. It skips cpu0 during online/offline
>> >> process.
>> >>
>> >
>> > Then how could this happen ? Looks like cpu 0 is offline ....
>> > 0:mon> <4>IRQ 17 affinity broken off cpu 0
>> > <4>IRQ 18 affinity broken off cpu 0
>> > <4>IRQ 19 affinity broken off cpu 0
>> > <4>IRQ 264 affinity broken off cpu 0
>> > <4>cpu 0 (hwid 0) Ready to die...
>> > <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>> >
>> Sorry i was looking at only one script. Looking more closely
>> at the test there are 6 different sub tests. The rest of the
>> tests do seem to hotplug CPU 0.
>
> Ooh, cute, so you can actually hotplug cpu 0.. no wonder that didn't get
> exposed on x86.
>
> Still, the only time cpu_active_mask should not be equal to
> cpu_online_mask is when we're in the middle of a hotplug, we clear
> active early and set it late, but its all done under the hotplug mutex,
> so we can at most have 1 cpu differences with online mask.
>
Could follow be possible? We know there's cpu 0 and cpu 1,
offline cpu1 > done
offline cpu0 > false
consider this in cpu_down code,
int __ref cpu_down(unsigned int cpu)
{
<snip>
set_cpu_active(cpu, false); // here, we set cpu 0 to inactive
synchronize_sched();
err = _cpu_down(cpu, 0);
out:
<snip>
}
Then in _cpu_down code:
static int __ref _cpu_down(unsigned int cpu, int tasks_frozen)
{
<snip>
if (num_online_cpus() == 1) // if we're trying to
offline cpu0, num_online_cpus will be 1
return -EBUSY; // after return back
to cpu_down, we didn't change cpu 0 back to active
if (!cpu_online(cpu))
return -EINVAL;
if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
return -ENOMEM;
<snip>
}
Then cpu 0 is not active, but online, then we try to offline cpu1, .......
This can not be exposed because x86 does not have
/sys/devices/system/cpu0/online.
I guess following patch fixes this bug.
---
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 291ac58..21ddace 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -199,14 +199,18 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
.hcpu = hcpu,
};
- if (num_online_cpus() == 1)
+ if (num_online_cpus() == 1) {
+ set_cpu_active(cpu, true);
return -EBUSY;
+ }
if (!cpu_online(cpu))
return -EINVAL;
- if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL))
+ if (!alloc_cpumask_var(&old_allowed, GFP_KERNEL)) {
+ set_cpu_active(cpu, true);
return -ENOMEM;
+ }
cpu_hotplug_begin();
err = __raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE | mod,
> Unless of course, I messed up, which appears to be rather likely given
> these problems ;-)
>
>
^ permalink raw reply related
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-16 7:18 UTC (permalink / raw)
To: Sachin Sant
Cc: linux-kernel, Linux/PPC Development, linux-next, Xiaotian Feng,
Ingo Molnar
In-Reply-To: <4B288413.2070704@in.ibm.com>
On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
> Xiaotian Feng wrote:
> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> >
> >> Xiaotian Feng wrote:
> >>
> >>> Does this testcase hotplug cpu 0 off?
> >>>
> >>>
> >> No, i don't think so. It skips cpu0 during online/offline
> >> process.
> >>
> >
> > Then how could this happen ? Looks like cpu 0 is offline ....
> > 0:mon> <4>IRQ 17 affinity broken off cpu 0
> > <4>IRQ 18 affinity broken off cpu 0
> > <4>IRQ 19 affinity broken off cpu 0
> > <4>IRQ 264 affinity broken off cpu 0
> > <4>cpu 0 (hwid 0) Ready to die...
> > <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
> >
> Sorry i was looking at only one script. Looking more closely
> at the test there are 6 different sub tests. The rest of the
> tests do seem to hotplug CPU 0.
Ooh, cute, so you can actually hotplug cpu 0.. no wonder that didn't get
exposed on x86.
Still, the only time cpu_active_mask should not be equal to
cpu_online_mask is when we're in the middle of a hotplug, we clear
active early and set it late, but its all done under the hotplug mutex,
so we can at most have 1 cpu differences with online mask.
Unless of course, I messed up, which appears to be rather likely given
these problems ;-)
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-16 7:14 UTC (permalink / raw)
To: Sachin Sant; +Cc: Ingo Molnar, linux-next, linux-kernel, Linux/PPC Development
In-Reply-To: <4B287242.5070002@in.ibm.com>
On Wed, 2009-12-16 at 11:08 +0530, Sachin Sant wrote:
> Peter Zijlstra wrote:
> > Could you try the below?
> >
> No luck. Still the same issue. The mask values don't change.
Bugger, that patch did solve a similar problem for a patch I'm working
on.
Can you maybe add a print of the cpu_active_mask() in set_cpu_active()
using WARN() so we can see where it changes the mask, and why it things
its empty?
> > ---
> > init/main.c | 7 +------
> > 1 files changed, 1 insertions(+), 6 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 4051d75..4be7de2 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -369,12 +369,6 @@ static void __init smp_init(void)
> > {
> > unsigned int cpu;
> >
> > - /*
> > - * Set up the current CPU as possible to migrate to.
> > - * The other ones will be done by cpu_up/cpu_down()
> > - */
> > - set_cpu_active(smp_processor_id(), true);
> > -
> > /* FIXME: This should be done in userspace --RR */
> > for_each_present_cpu(cpu) {
> > if (num_online_cpus() >= setup_max_cpus)
> > @@ -486,6 +480,7 @@ static void __init boot_cpu_init(void)
> > int cpu = smp_processor_id();
> > /* Mark the boot cpu "present", "online" etc for SMP and UP case */
> > set_cpu_online(cpu, true);
> > + set_cpu_active(cpu, true);
> > set_cpu_present(cpu, true);
> > set_cpu_possible(cpu, true);
> > }
> >
> >
> >
>
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 6:56 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B279370.5050800@in.ibm.com>
On Tue, Dec 15, 2009 at 9:47 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Peter Zijlstra wrote:
>>>
>>> I added some debug statements within the above code. This is a 2 cpu
>>> machine.
>>>
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 1024 XMON dest_cpu =3D 1024 . dead_cpu =3D 1
>>>
>>> Seems to me that the control is stuck in an infinite loop and hence the
>>> machine appears to be in hung state. The dest_cpu value is always 1024
>>> and never changes, which result in an infinite loop.
>>>
>>> In working scenario the o/p is something on the following lines
>>>
>>> XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_ids =3D 2
>>> XMON dest_cpu =3D 0 XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_id=
s =3D 2
>>> XMON dest_cpu =3D 0 XMON dest_cpu =3D 1024 . dead_cpu =3D 1 . nr_cpu_id=
s =3D 2
>>> XMON dest_cpu =3D 0
>>> Let me know if i should try to record any specific value ?
>>>
>>
>> Could you possibly print the two masks themselves? cpumask_scnprintf()
>> and friend come in handy for this.
>>
>> The dest_cpu=3D1024 thing seem to suggest the intersection between
>> p->cpus_allowed and cpu_active_mask is empty for some reason, even
>> though we forcefully reset p->cpus_allowed to the full set using
>> cpuset_cpus_allowed_locked().
>>
>
> So here is the data related to the two masks.
>
> cpu_active_mask =3D 00000000,00000000,00000000,00000000,00000000,00000000=
,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000
> XMON dest_cpu =3D 1024
>
How about cpu_online_mask? commit 6ad4c1 switches from cpu_online_mask
to cpu_active_mask.
Is there a mismatch for cpu_online_mask and cpu_active_mask?
> while p->cpus_allowed =3D =C2=A000000000,00000000,00000000,00000000,00000=
000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000001
> XMON dest_cpu =3D 1024
>
> In working scenario the above data looks like
>
> cpu_active_mask =3D 00000000,00000000,00000000,00000000,00000000,00000000=
,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000002
> XMON dest_cpu =3D 1
>
> while p->cpus_allowed =3D =C2=A000000000,00000000,00000000,00000000,00000=
000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,
> 00000000,00000000,00000002
> XMON dest_cpu =3D 1
>
>
> hope i got the data correct.
>
> Thanks
> -Sachin
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 6:54 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152245v61a7f1ebgb41f4857134f3476@mail.gmail.com>
Xiaotian Feng wrote:
> On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
>
>> Xiaotian Feng wrote:
>>
>>> Does this testcase hotplug cpu 0 off?
>>>
>>>
>> No, i don't think so. It skips cpu0 during online/offline
>> process.
>>
>
> Then how could this happen ? Looks like cpu 0 is offline ....
> 0:mon> <4>IRQ 17 affinity broken off cpu 0
> <4>IRQ 18 affinity broken off cpu 0
> <4>IRQ 19 affinity broken off cpu 0
> <4>IRQ 264 affinity broken off cpu 0
> <4>cpu 0 (hwid 0) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>
Sorry i was looking at only one script. Looking more closely
at the test there are 6 different sub tests. The rest of the
tests do seem to hotplug CPU 0.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Mahajan Vivek-B08308 @ 2009-12-16 6:49 UTC (permalink / raw)
To: Felix Radensky, linuxppc-dev, Aggrwal Poonam-B10812, Kumar Gala
In-Reply-To: <4B27FEE3.80001@embedded-sol.com>
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists.ozlabs.
> org=20
> [mailto:linuxppc-dev-bounces+vivek.mahajan=3Dfreescale.com@lists
.ozlabs.org] On Behalf Of Felix Radensky
> Sent: Wednesday, December 16, 2009 2:56 AM
> To: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
> Subject: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hi,
>=20
> I'm trying to use mini-PCI-E WLAN card on P2020RDB running=20
> 2.6.32, but so far without success.
> ath9k driver identifies the device, I can run ifconfig,=20
> iwconfig and hostapd on wlan0, but device is not getting any=20
> interrupts, so I suspect the interrupt configuration is=20
> wrong. Atheros ath9k driver reports:
>=20
> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0:=20
> mem=3D0xf1060000, irq=3D16
>=20
> The mapping for irq 16 is:
>=20
> irq: irq 1 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>=20
> According to /proc/interrupts:
>=20
> CPU0
> 16: 0 OpenPIC Edge ath9k
>=20
> The same problem happens if Atheros card is plugged (with=20
> adapter) into regular PCI-E slot.
>=20
> It seems that p2020rdb device tree is missing=20
> interrupt-map-mask and interrupt-map properties in PCI-E nodes.
>=20
> I've tried running kernel from latest FSL BSP for this board=20
> (based on 2.6.32-rc3). The device tree has the=20
> interrupt-map-mask and interrupt-map properties, and=20
> interrupt mapping is different:
>=20
> irq: irq 0 on host /soc@ffe00000/pic@40000 mapped to virtual irq 16
>=20
> In /proc/interrups I see
> CPU0
> 16: 100001 OpenPIC Level ath9k
>=20
> However, when ath9k driver is loaded I get this:
>=20
> irq 16: nobody cared (try booting with the "irqpoll" option)=20
> Call Trace:
> [efbefa40] [c00074b0] show_stack+0x4c/0x16c (unreliable)=20
> [efbefa70] [c0073970] __report_bad_irq+0x38/0xd0 [efbefa90]=20
> [c0073bd4] note_interrupt+0x1cc/0x22c [efbefac0] [c00747d0]=20
> handle_fasteoi_irq+0xf4/0x128 [efbefae0] [c0004eb8]=20
> do_IRQ+0xc8/0xf4 [efbefb00] [c001081c]=20
> ret_from_except+0x0/0x18 [efbefbc0] [00000000] (null)=20
> [efbefc10] [c0004d24] do_softirq+0x60/0x64 [efbefc20]=20
> [c0044670] irq_exit+0x88/0xa8 [efbefc30] [c0004ebc]=20
> do_IRQ+0xcc/0xf4 [efbefc50] [c001081c]=20
> ret_from_except+0x0/0x18 [efbefd10] [c00730b4]=20
> __setup_irq+0x320/0x39c [efbefd30] [c0073214]=20
> request_threaded_irq+0xe4/0x148 [efbefd60] [f2244218]=20
> ath_pci_probe+0x1b0/0x3a4 [ath9k] [efbefda0] [c01c386c]=20
> local_pci_probe+0x24/0x34 [efbefdb0] [c01c3bc0]=20
> pci_device_probe+0x84/0xa8 [efbefde0] [c01e86b8]=20
> driver_probe_device+0xa8/0x1a8 [efbefe00] [c01e8874]=20
> __driver_attach+0xbc/0xc0 [efbefe20] [c01e7d88]=20
> bus_for_each_dev+0x70/0xac [efbefe50] [c01e84d8]=20
> driver_attach+0x24/0x34 [efbefe60] [c01e7504]=20
> bus_add_driver+0xb8/0x278 [efbefe90] [c01e8bec]=20
> driver_register+0x84/0x178 [efbefeb0] [c01c3e6c]=20
> __pci_register_driver+0x54/0xe4 [efbefed0] [f2244434]=20
> ath_pci_init+0x28/0x38 [ath9k] [efbefee0] [f215702c]=20
> ath9k_init+0x2c/0x100 [ath9k] [efbefef0] [c0001d34]=20
> do_one_initcall+0x3c/0x1e8 [efbeff20] [c006f9f0]=20
> sys_init_module+0xf8/0x220 [efbeff40] [c00101c4]=20
> ret_from_syscall+0x0/0x3c
> handlers:
> [<f223badc>] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #16
Looks like INTA is not being routed to IRQ0 properly for this
PCIe ctlr. Try changing the interrupt-map prop for the ctlr=20
at 0xffe0a000 to the following, temporarily:-
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x1 0x1
0000 0x0 0x0 0x2 &mpic 0x2 0x1
0000 0x0 0x0 0x3 &mpic 0x3 0x1
0000 0x0 0x0 0x4 &mpic 0x0 0x1
>;
>=20
> Atheros card plugged into regular PCI-E slot works OK in FSL BSP.
>=20
> Any help in resolving this is much appreciated.
>=20
> Thanks.
>=20
> Felix.
>=20
Thanks,
Vivek
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Xiaotian Feng @ 2009-12-16 6:45 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <4B288131.2050306@in.ibm.com>
On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant <sachinp@in.ibm.com> wrote:
> Xiaotian Feng wrote:
>>
>> Does this testcase hotplug cpu 0 off?
>>
>
> No, i don't think so. It skips cpu0 during online/offline
> process.
Then how could this happen ? Looks like cpu 0 is offline ....
0:mon> <4>IRQ 17 affinity broken off cpu 0
<4>IRQ 18 affinity broken off cpu 0
<4>IRQ 19 affinity broken off cpu 0
<4>IRQ 264 affinity broken off cpu 0
<4>cpu 0 (hwid 0) Ready to die...
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>
> thanks
> -Sachin
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
>
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-16 6:41 UTC (permalink / raw)
To: Xiaotian Feng
Cc: Peter Zijlstra, linux-kernel, Linux/PPC Development, linux-next,
Ingo Molnar
In-Reply-To: <7b6bb4a50912152225p4f5dde13re83c439407c16eaf@mail.gmail.com>
Xiaotian Feng wrote:
> Does this testcase hotplug cpu 0 off?
>
No, i don't think so. It skips cpu0 during online/offline
process.
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ 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