* [PATCH v3 00/17] Platform Facilities Option and crypto accelerators
From: Kent Yoder @ 2012-04-12 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: key, rcj, linuxppc-dev, linux-crypto
This patch series adds support for a new device type, the Platform
Facilities Option (PFO). PFO resources are a set of accelerators that
share some system resources managed by the VIO bus. This patchset
includes the basic support for the devices in the VIO bus code along
with drivers for the random number generator and the cryptographic
accelerators.
Thanks,
Kent
ChangeLog for v3:
- reorder patches putting nx driver first (Dave Miller)
ChangeLog for v2:
- move crypto driver sysfs stuff to debugfs (Greg K-H)
- Remove CONFIG_ dependencies for the CMO bits (Anton Blanchard)
- move nx driver code to drivers/crypto (Kumar Gala)
- Add inline comment for nx_build_sg_list (Rob Jennings)
- make sure kmalloc'd pointers are aligned (Rob Jennings)
- get rid of bitfields in nx_csbcpb.h (Rob Jennings)
- Compile against Ben Herrenschmidt's ppc device naming patch
- Rebase against latest upstream
Kent Yoder (12):
powerpc: crypto: nx driver code supporting nx encryption
powerpc: crypto: AES-CBC mode routines for nx encryption
powerpc: crypto: AES-CCM mode routines for nx encryption
powerpc: crypto: AES-CTR mode routines for nx encryption
powerpc: crypto: AES-ECB mode routines for nx encryption
powerpc: crypto: AES-GCM mode routines for nx encryption
powerpc: crypto: AES-XCBC mode routines for nx encryption
powerpc: crypto: SHA256 hash routines for nx encryption
powerpc: crypto: SHA512 hash routines for nx encryption
powerpc: crypto: debugfs routines and docs for the nx device driver
powerpc: crypto: Build files for the nx device driver
powerpc: crypto: enable the PFO-based encryption device
Michael Neuling (1):
hwrng: pseries - PFO-based hwrng driver
Robert Jennings (4):
powerpc: Add new hvcall constants to support PFO
powerpc: Add pseries update notifier for OFDT prop changes
powerpc: Add PFO support to the VIO bus
pseries: Enabled the PFO-based RNG accelerator
Documentation/ABI/testing/debugfs-pfo-nx-crypto | 45 ++
arch/powerpc/Makefile | 1 +
arch/powerpc/include/asm/hvcall.h | 25 +-
arch/powerpc/include/asm/pSeries_reconfig.h | 12 +
arch/powerpc/include/asm/vio.h | 46 ++
arch/powerpc/kernel/prom_init.c | 9 +-
arch/powerpc/kernel/vio.c | 273 ++++++++--
arch/powerpc/platforms/pseries/reconfig.c | 7 +
drivers/char/hw_random/Kconfig | 13 +
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/pseries-rng.c | 96 +++
drivers/crypto/Kconfig | 17 +
drivers/crypto/nx/Makefile | 11 +
drivers/crypto/nx/nx-aes-cbc.c | 140 +++++
drivers/crypto/nx/nx-aes-ccm.c | 465 +++++++++++++++
drivers/crypto/nx/nx-aes-ctr.c | 177 ++++++
drivers/crypto/nx/nx-aes-ecb.c | 138 +++++
drivers/crypto/nx/nx-aes-gcm.c | 353 +++++++++++
drivers/crypto/nx/nx-aes-xcbc.c | 234 ++++++++
drivers/crypto/nx/nx-sha256.c | 244 ++++++++
drivers/crypto/nx/nx-sha512.c | 263 +++++++++
drivers/crypto/nx/nx.c | 711 +++++++++++++++++++++++
drivers/crypto/nx/nx.h | 192 ++++++
drivers/crypto/nx/nx_csbcpb.h | 205 +++++++
drivers/crypto/nx/nx_debugfs.c | 103 ++++
25 files changed, 3739 insertions(+), 42 deletions(-)
create mode 100644 Documentation/ABI/testing/debugfs-pfo-nx-crypto
create mode 100644 drivers/char/hw_random/pseries-rng.c
create mode 100644 drivers/crypto/nx/Makefile
create mode 100644 drivers/crypto/nx/nx-aes-cbc.c
create mode 100644 drivers/crypto/nx/nx-aes-ccm.c
create mode 100644 drivers/crypto/nx/nx-aes-ctr.c
create mode 100644 drivers/crypto/nx/nx-aes-ecb.c
create mode 100644 drivers/crypto/nx/nx-aes-gcm.c
create mode 100644 drivers/crypto/nx/nx-aes-xcbc.c
create mode 100644 drivers/crypto/nx/nx-sha256.c
create mode 100644 drivers/crypto/nx/nx-sha512.c
create mode 100644 drivers/crypto/nx/nx.c
create mode 100644 drivers/crypto/nx/nx.h
create mode 100644 drivers/crypto/nx/nx_csbcpb.h
create mode 100644 drivers/crypto/nx/nx_debugfs.c
^ permalink raw reply
* [PATCH v3 08/17] powerpc: crypto: AES-CCM mode routines for nx encryption
From: Kent Yoder @ 2012-04-12 15:28 UTC (permalink / raw)
To: linux-kernel; +Cc: key, rcj, linuxppc-dev, linux-crypto
In-Reply-To: <1334242825.18090.4.camel@key-ThinkPad-W510>
These routines add support for AES in CCM mode on the Power7+ CPU's
in-Nest accelerator driver.
Signed-off-by: Kent Yoder <key@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx-aes-ccm.c | 465 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 465 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/nx/nx-aes-ccm.c
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
new file mode 100644
index 0000000..e418bef
--- /dev/null
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -0,0 +1,465 @@
+/**
+ * AES CCM routines supporting the Power 7+ Nest Accelerators driver
+ *
+ * Copyright (C) 2012 International Business Machines Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 only.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Author: Kent Yoder <yoder1@us.ibm.com>
+ */
+
+#include <crypto/internal/aead.h>
+#include <crypto/aes.h>
+#include <crypto/algapi.h>
+#include <crypto/scatterwalk.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/crypto.h>
+#include <asm/vio.h>
+
+#include "nx_csbcpb.h"
+#include "nx.h"
+
+
+static int ccm_aes_nx_set_key(struct crypto_aead *tfm,
+ const u8 *in_key,
+ unsigned int key_len)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&tfm->base);
+ struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ struct nx_csbcpb *csbcpb_aead = nx_ctx->csbcpb_aead;
+
+ nx_ctx_init(nx_ctx, HCOP_FC_AES);
+
+ switch (key_len) {
+ case AES_KEYSIZE_128:
+ NX_CPB_SET_KEY_SIZE(csbcpb, NX_KS_AES_128);
+ NX_CPB_SET_KEY_SIZE(csbcpb_aead, NX_KS_AES_128);
+ nx_ctx->ap = &nx_ctx->props[NX_PROPS_AES_128];
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ csbcpb->cpb.hdr.mode = NX_MODE_AES_CCM;
+ memcpy(csbcpb->cpb.aes_ccm.key, in_key, key_len);
+
+ csbcpb_aead->cpb.hdr.mode = NX_MODE_AES_CCA;
+ memcpy(csbcpb_aead->cpb.aes_cca.key, in_key, key_len);
+
+ return 0;
+
+}
+
+static int ccm4309_aes_nx_set_key(struct crypto_aead *tfm,
+ const u8 *in_key,
+ unsigned int key_len)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&tfm->base);
+
+ if (key_len < 3)
+ return -EINVAL;
+
+ key_len -= 3;
+
+ memcpy(nx_ctx->priv.ccm.nonce, in_key + key_len, 3);
+
+ return ccm_aes_nx_set_key(tfm, in_key, key_len);
+}
+
+static int ccm_aes_nx_setauthsize(struct crypto_aead *tfm,
+ unsigned int authsize)
+{
+ switch (authsize) {
+ case 4:
+ case 6:
+ case 8:
+ case 10:
+ case 12:
+ case 14:
+ case 16:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ crypto_aead_crt(tfm)->authsize = authsize;
+
+ return 0;
+}
+
+static int ccm4309_aes_nx_setauthsize(struct crypto_aead *tfm,
+ unsigned int authsize)
+{
+ switch (authsize) {
+ case 8:
+ case 12:
+ case 16:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ crypto_aead_crt(tfm)->authsize = authsize;
+
+ return 0;
+}
+
+/* taken from crypto/ccm.c */
+static int set_msg_len(u8 *block, unsigned int msglen, int csize)
+{
+ __be32 data;
+
+ memset(block, 0, csize);
+ block += csize;
+
+ if (csize >= 4)
+ csize = 4;
+ else if (msglen > (unsigned int)(1 << (8 * csize)))
+ return -EOVERFLOW;
+
+ data = cpu_to_be32(msglen);
+ memcpy(block - csize, (u8 *)&data + 4 - csize, csize);
+
+ return 0;
+}
+
+/* taken from crypto/ccm.c */
+static inline int crypto_ccm_check_iv(const u8 *iv)
+{
+ /* 2 <= L <= 8, so 1 <= L' <= 7. */
+ if (1 > iv[0] || iv[0] > 7)
+ return -EINVAL;
+
+ return 0;
+}
+
+/* based on code from crypto/ccm.c */
+static int generate_b0(u8 *iv, unsigned int assoclen, unsigned int authsize,
+ unsigned int cryptlen, u8 *b0)
+{
+ unsigned int l, lp, m = authsize;
+ int rc;
+
+ memcpy(b0, iv, 16);
+
+ lp = b0[0];
+ l = lp + 1;
+
+ /* set m, bits 3-5 */
+ *b0 |= (8 * ((m - 2) / 2));
+
+ /* set adata, bit 6, if associated data is used */
+ if (assoclen)
+ *b0 |= 64;
+
+ rc = set_msg_len(b0 + 16 - l, cryptlen, l);
+
+ return rc;
+}
+
+static int generate_pat(u8 *iv,
+ struct aead_request *req,
+ struct nx_crypto_ctx *nx_ctx,
+ unsigned int authsize,
+ unsigned int nbytes,
+ u8 *out)
+{
+ struct nx_sg *nx_insg = nx_ctx->in_sg;
+ struct nx_sg *nx_outsg = nx_ctx->out_sg;
+ unsigned int iauth_len = 0;
+ struct vio_pfo_op *op = NULL;
+ u8 tmp[16], *b1 = NULL, *b0 = NULL, *result = NULL;
+ int rc;
+
+ /* zero the ctr value */
+ memset(iv + 15 - iv[0], 0, iv[0] + 1);
+
+ if (!req->assoclen) {
+ b0 = nx_ctx->csbcpb->cpb.aes_ccm.in_pat_or_b0;
+ } else if (req->assoclen <= 14) {
+ /* if associated data is 14 bytes or less, we do 1 GCM
+ * operation on 2 AES blocks, B0 (stored in the csbcpb) and B1,
+ * which is fed in through the source buffers here */
+ b0 = nx_ctx->csbcpb->cpb.aes_ccm.in_pat_or_b0;
+ b1 = nx_ctx->priv.ccm.iauth_tag;
+ iauth_len = req->assoclen;
+
+ nx_insg = nx_build_sg_list(nx_insg, b1, 16, nx_ctx->ap->sglen);
+ nx_outsg = nx_build_sg_list(nx_outsg, tmp, 16,
+ nx_ctx->ap->sglen);
+
+ /* inlen should be negative, indicating to phyp that its a
+ * pointer to an sg list */
+ nx_ctx->op.inlen = (nx_ctx->in_sg - nx_insg) *
+ sizeof(struct nx_sg);
+ nx_ctx->op.outlen = (nx_ctx->out_sg - nx_outsg) *
+ sizeof(struct nx_sg);
+
+ NX_CPB_FDM(nx_ctx->csbcpb) |= NX_FDM_ENDE_ENCRYPT;
+ NX_CPB_FDM(nx_ctx->csbcpb) |= NX_FDM_INTERMEDIATE;
+
+ op = &nx_ctx->op;
+ result = nx_ctx->csbcpb->cpb.aes_ccm.out_pat_or_mac;
+ } else if (req->assoclen <= 65280) {
+ /* if associated data is less than (2^16 - 2^8), we construct
+ * B1 differently and feed in the associated data to a CCA
+ * operation */
+ b0 = nx_ctx->csbcpb_aead->cpb.aes_cca.b0;
+ b1 = nx_ctx->csbcpb_aead->cpb.aes_cca.b1;
+ iauth_len = 14;
+
+ /* remaining assoc data must have scatterlist built for it */
+ nx_insg = nx_walk_and_build(nx_insg, nx_ctx->ap->sglen,
+ req->assoc, iauth_len,
+ req->assoclen - iauth_len);
+ nx_ctx->op_aead.inlen = (nx_ctx->in_sg - nx_insg) *
+ sizeof(struct nx_sg);
+
+ op = &nx_ctx->op_aead;
+ result = nx_ctx->csbcpb_aead->cpb.aes_cca.out_pat_or_b0;
+ } else {
+ /* if associated data is less than (2^32), we construct B1
+ * differently yet again and feed in the associated data to a
+ * CCA operation */
+ pr_err("associated data len is %u bytes (returning -EINVAL)\n",
+ req->assoclen);
+ rc = -EINVAL;
+ }
+
+ rc = generate_b0(iv, req->assoclen, authsize, nbytes, b0);
+ if (rc)
+ goto done;
+
+ if (b1) {
+ memset(b1, 0, 16);
+ *(u16 *)b1 = (u16)req->assoclen;
+
+ scatterwalk_map_and_copy(b1 + 2, req->assoc, 0,
+ iauth_len, SCATTERWALK_FROM_SG);
+
+ rc = nx_hcall_sync(nx_ctx, op);
+ if (rc)
+ goto done;
+
+ atomic_inc(&(nx_ctx->stats->aes_ops));
+ atomic64_add(req->assoclen, &(nx_ctx->stats->aes_bytes));
+
+ memcpy(out, result, AES_BLOCK_SIZE);
+ }
+done:
+ return rc;
+}
+
+static int ccm_nx_decrypt(struct aead_request *req,
+ struct blkcipher_desc *desc)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
+ struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned int nbytes = req->cryptlen;
+ unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
+ struct nx_ccm_priv *priv = &nx_ctx->priv.ccm;
+ int rc = -1;
+
+ if (nbytes > nx_ctx->ap->databytelen)
+ return -EINVAL;
+
+ nbytes -= authsize;
+
+ /* copy out the auth tag to compare with later */
+ scatterwalk_map_and_copy(priv->oauth_tag,
+ req->src, nbytes, authsize,
+ SCATTERWALK_FROM_SG);
+
+ rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes,
+ csbcpb->cpb.aes_ccm.in_pat_or_b0);
+ if (rc)
+ goto out;
+
+ rc = nx_build_sg_lists(nx_ctx, desc, req->dst, req->src, nbytes,
+ csbcpb->cpb.aes_ccm.iv_or_ctr);
+ if (rc)
+ goto out;
+
+ NX_CPB_FDM(nx_ctx->csbcpb) &= ~NX_FDM_ENDE_ENCRYPT;
+ NX_CPB_FDM(nx_ctx->csbcpb) &= ~NX_FDM_INTERMEDIATE;
+
+ rc = nx_hcall_sync(nx_ctx, &nx_ctx->op);
+ if (rc)
+ goto out;
+
+ atomic_inc(&(nx_ctx->stats->aes_ops));
+ atomic64_add(csbcpb->csb.processed_byte_count,
+ &(nx_ctx->stats->aes_bytes));
+
+ rc = memcmp(csbcpb->cpb.aes_ccm.out_pat_or_mac, priv->oauth_tag,
+ authsize) ? -EBADMSG : 0;
+out:
+ return rc;
+}
+
+static int ccm_nx_encrypt(struct aead_request *req,
+ struct blkcipher_desc *desc)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
+ struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned int nbytes = req->cryptlen;
+ unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
+ int rc = -1;
+
+ if (nbytes > nx_ctx->ap->databytelen)
+ return -EINVAL;
+
+ rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes,
+ csbcpb->cpb.aes_ccm.in_pat_or_b0);
+ if (rc)
+ goto out;
+
+ rc = nx_build_sg_lists(nx_ctx, desc, req->dst, req->src, nbytes,
+ csbcpb->cpb.aes_ccm.iv_or_ctr);
+ if (rc)
+ goto out;
+
+ NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
+ NX_CPB_FDM(csbcpb) &= ~NX_FDM_INTERMEDIATE;
+
+ rc = nx_hcall_sync(nx_ctx, &nx_ctx->op);
+ if (rc)
+ goto out;
+
+ atomic_inc(&(nx_ctx->stats->aes_ops));
+ atomic64_add(csbcpb->csb.processed_byte_count,
+ &(nx_ctx->stats->aes_bytes));
+
+ /* copy out the auth tag */
+ scatterwalk_map_and_copy(csbcpb->cpb.aes_ccm.out_pat_or_mac,
+ req->dst, nbytes, authsize,
+ SCATTERWALK_TO_SG);
+out:
+ return rc;
+}
+
+static int ccm4309_aes_nx_encrypt(struct aead_request *req)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
+ struct blkcipher_desc desc;
+ u8 *iv = nx_ctx->priv.ccm.iv;
+
+ iv[0] = 3;
+ memcpy(iv + 1, nx_ctx->priv.ccm.nonce, 3);
+ memcpy(iv + 4, req->iv, 8);
+
+ desc.info = iv;
+ desc.tfm = (struct crypto_blkcipher *)req->base.tfm;
+
+ return ccm_nx_encrypt(req, &desc);
+}
+
+static int ccm_aes_nx_encrypt(struct aead_request *req)
+{
+ struct blkcipher_desc desc;
+ int rc;
+
+ desc.info = req->iv;
+ desc.tfm = (struct crypto_blkcipher *)req->base.tfm;
+
+ rc = crypto_ccm_check_iv(desc.info);
+ if (rc)
+ return rc;
+
+ return ccm_nx_encrypt(req, &desc);
+}
+
+static int ccm4309_aes_nx_decrypt(struct aead_request *req)
+{
+ struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(req->base.tfm);
+ struct blkcipher_desc desc;
+ u8 *iv = nx_ctx->priv.ccm.iv;
+
+ iv[0] = 3;
+ memcpy(iv + 1, nx_ctx->priv.ccm.nonce, 3);
+ memcpy(iv + 4, req->iv, 8);
+
+ desc.info = iv;
+ desc.tfm = (struct crypto_blkcipher *)req->base.tfm;
+
+ return ccm_nx_decrypt(req, &desc);
+}
+
+static int ccm_aes_nx_decrypt(struct aead_request *req)
+{
+ struct blkcipher_desc desc;
+ int rc;
+
+ desc.info = req->iv;
+ desc.tfm = (struct crypto_blkcipher *)req->base.tfm;
+
+ rc = crypto_ccm_check_iv(desc.info);
+ if (rc)
+ return rc;
+
+ return ccm_nx_decrypt(req, &desc);
+}
+
+/* tell the block cipher walk routines that this is a stream cipher by
+ * setting cra_blocksize to 1. Even using blkcipher_walk_virt_block
+ * during encrypt/decrypt doesn't solve this problem, because it calls
+ * blkcipher_walk_done under the covers, which doesn't use walk->blocksize,
+ * but instead uses this tfm->blocksize. */
+struct crypto_alg nx_ccm_aes_alg = {
+ .cra_name = "ccm(aes)",
+ .cra_driver_name = "ccm-aes-nx",
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = 1,
+ .cra_ctxsize = sizeof(struct nx_crypto_ctx),
+ .cra_type = &crypto_aead_type,
+ .cra_module = THIS_MODULE,
+ .cra_list = LIST_HEAD_INIT(nx_ccm_aes_alg.cra_list),
+ .cra_init = nx_crypto_ctx_aes_ccm_init,
+ .cra_exit = nx_crypto_ctx_exit,
+ .cra_aead = {
+ .ivsize = AES_BLOCK_SIZE,
+ .maxauthsize = AES_BLOCK_SIZE,
+ .setkey = ccm_aes_nx_set_key,
+ .setauthsize = ccm_aes_nx_setauthsize,
+ .encrypt = ccm_aes_nx_encrypt,
+ .decrypt = ccm_aes_nx_decrypt,
+ }
+};
+
+struct crypto_alg nx_ccm4309_aes_alg = {
+ .cra_name = "rfc4309(ccm(aes))",
+ .cra_driver_name = "rfc4309-ccm-aes-nx",
+ .cra_priority = 300,
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = 1,
+ .cra_ctxsize = sizeof(struct nx_crypto_ctx),
+ .cra_type = &crypto_nivaead_type,
+ .cra_module = THIS_MODULE,
+ .cra_list = LIST_HEAD_INIT(nx_ccm4309_aes_alg.cra_list),
+ .cra_init = nx_crypto_ctx_aes_ccm_init,
+ .cra_exit = nx_crypto_ctx_exit,
+ .cra_aead = {
+ .ivsize = 8,
+ .maxauthsize = AES_BLOCK_SIZE,
+ .setkey = ccm4309_aes_nx_set_key,
+ .setauthsize = ccm4309_aes_nx_setauthsize,
+ .encrypt = ccm4309_aes_nx_encrypt,
+ .decrypt = ccm4309_aes_nx_decrypt,
+ .geniv = "seqiv",
+ }
+};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Jeff Garzik @ 2012-04-12 20:05 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: devicetree-discuss, linux-kernel, Rob Herring, linux-ide,
Thang Q. Nguyen, Paul Mackerras, linuxppc-dev
In-Reply-To: <4F7AE584.3050805@mvista.com>
On 04/03/2012 07:56 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>
>> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
>> ---
>> Changes for v2:
>> - Use git rename feature to change the driver to the newname and for
>> easier review.
>
>> arch/powerpc/boot/dts/bluestone.dts | 21 +
>> drivers/ata/Makefile | 2 +-
>> drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} | 1371
>> ++++++++++++++--------
>> 3 files changed, 904 insertions(+), 490 deletions(-)
>> rename drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} (56%)
>
> You submitted a magapatch doing several things at once (some even
> needlessly) and even in two areas of the kernel. This needs proper
> splitting/description.
Agreed...
^ permalink raw reply
* Re: [PATCH v5 00/21] EEH reorganization
From: Anton Blanchard @ 2012-04-12 21:39 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1330409051-8941-1-git-send-email-shangw@linux.vnet.ibm.com>
Hi Gavin,
> This series of patches is going to reorganize EEH so that it could
> support multiple platforms in future. The requirements were raised
> from the aspects.
I just hit this on mainline from today (3.4.0-rc2-00065-gf549e08).
Haven't had a chance to narrow it down yet.
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c000000000055af8 LR: c000000000033204 CTR: 0000000000000000
REGS: c000001f42fb7990 TRAP: 0300 Tainted: G W (3.4.0-rc2-00065-gf549e08-dirty)
MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24008084 XER: 00000000
SOFTE: 1
CFAR: 00000000000049b8
DAR: 0000000000000070, DSISR: 40000000
TASK = c000001f6c7dfc40[19010] 'eehd' THREAD: c000001f42fb4000 CPU: 6
GPR00: 0000000000000001 c000001f42fb7c10 c000000000bd3a28 c000001f80ab0800
GPR04: c000001f7c57d418 0000000000000380 c000001f7c57e070 c000000000ed5360
GPR08: 0000000000000000 c000000000c77088 0000000000000000 0000000000000001
GPR12: 0000000044008088 c00000000eda1500 00000000019ffa78 0000000000a70000
GPR16: 00000000000000bb c000000000a9f754 c000000000963230 000000000000005e
GPR20: 0000000001b37e80 00000000000000bb 0000000000000000 c000000000b0ad90
GPR24: 0000000000000000 c000000000b10588 0000000000000001 c000001f80ab0800
GPR28: 0000000000000000 c000001f80ab0828 0000000000000000 c000001f7ee10000
NIP [c000000000055af8] .eeh_add_device_tree_late+0x58/0xf0
LR [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
Call Trace:
[c000001f42fb7c10] [00000000fdffffff] 0xfdffffff (unreliable)
[c000001f42fb7ca0] [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
[c000001f42fb7d20] [c000000000059a5c] .pcibios_add_pci_devices+0x7c/0x190
[c000001f42fb7db0] [c000000000057a6c] .eeh_reset_device+0xfc/0x1a0
[c000001f42fb7e50] [c000000000057e18] .handle_eeh_events+0x308/0x480
[c000001f42fb7f00] [c0000000000584dc] .eeh_event_handler+0x13c/0x1d0
[c000001f42fb7f90] [c00000000002099c] .kernel_thread+0x54/0x70
Instruction dump:
480000a8 60000000 ebff0000 7fbfe800 419e0098 2fbf0000 419e005c e9229eb0
80090008 2f800000 419e004c ebdf01d0 <e81e0070> 7fbf0000 3160ffff
7d2b0110
Anton
^ permalink raw reply
* Re: [RFC] powerpc: set_dma_ops for pci hotplug
From: Hiroo Matsumoto @ 2012-04-13 0:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4F867083.2090200@jp.fujitsu.com>
Hi
I'm so sorry, but there is a better way than this way with
pcibios_enable_device() for issue.
I will write another code soon, so please wait.
Regards.
Hiroo MATSUMOTO
> Hi
>
>
> I'm trying to use PCI Express Hot Plug on powerpc platform.
> But PCI driver returns error when hotplug.
> Error log is as below.
> http://www.spinics.net/lists/linux-pci/msg14534.html
>
> Some of PCI driver needs dma_ops.
> On x86 platform, dma_ops is getting from external variable.
> On powerpc platform, dma_ops is getting from archdata.dma_ops in struct
> device.
> There is a problem that archdata.dma_ops is set only when boot with
> pcibios_setup_bus_devices but not set when hotplug.
> So when hotplug, PCI driver's probe will return error.
>
> I add code of checking and setting dma_ops in pcibios_enable_device.
> It is called from pci_enable_device_xxx in PCI driver's probe before
> checking dma_ops.
> And PCI driver works good when hotplug.
>
>
> Regards.
>
> Hiroo MATSUMOTO
>
^ permalink raw reply
* Re: [PATCH v5 00/21] EEH reorganization
From: Anton Blanchard @ 2012-04-13 2:03 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <20120413073931.0c36169b@kryten>
Hi,
> I just hit this on mainline from today (3.4.0-rc2-00065-gf549e08).
> Haven't had a chance to narrow it down yet.
Looking closer, it was caused by an EEH error at boot. It looks like
the Mellanox infiniband card gets an error when probed by their
firmware tool (mstmread), but only if the kernel driver is not loaded.
I see this EEH error back on 3.0, so it's not new.
The question now is why we oops in the EEH code on mainline.
Anton
------------[ cut here ]------------
WARNING: at arch/powerpc/platforms/pseries/eeh.c:492
Modules linked in:
NIP: c000000000056cc4 LR: c000000000056cc0 CTR: c00000000051dd60
REGS: c000001f3953f6a0 TRAP: 0700 Not tainted (3.4.0-rc2-00065-gf549e08-dirty)
MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28004482 XER: 0000000f
SOFTE: 0
CFAR: c00000000074ea30
TASK = c000001f39685040[19058] 'mstmread' THREAD: c000001f3953c000 CPU: 38
GPR00: c000000000056cc0 c000001f3953f920 c000000000bd3a28 0000000000000021
GPR04: 0000000000000000 ffffffffffffffff 00000000000323f7 0000000000000000
GPR08: 000000006365203c c000000000b10a20 0000000000020000 c000000000a74cc0
GPR12: 0000000024004422 c00000000eda8500 000000003a58582e 00000000583a5858
GPR16: 000000002f585858 0000000069636573 000000002f646576 0000000010003b48
GPR20: 00000fffc7a3d17c 0000000000000058 0000000000000004 c000001f3953fb90
GPR24: 0000000000000000 0000000000000000 c000000000c77088 c000003e6fffeee8
GPR28: c000000000d82680 0000000000000000 c000000000c770d0 0000000000000000
NIP [c000000000056cc4] .eeh_dn_check_failure+0x304/0x320
LR [c000000000056cc0] .eeh_dn_check_failure+0x300/0x320
Call Trace:
[c000001f3953f920] [c000000000056cc0] .eeh_dn_check_failure+0x300/0x320 (unreliable)
[c000001f3953f9d0] [c00000000002717c] .rtas_read_config+0x13c/0x1b0
[c000001f3953fa70] [c0000000003d543c] .pci_user_read_config_dword+0xcc/0x150
[c000001f3953fb20] [c0000000003e19d8] .pci_read_config+0xe8/0x2a0
[c000001f3953fc00] [c00000000022d330] .read+0x130/0x210
[c000001f3953fce0] [c0000000001a723c] .vfs_read+0xec/0x1e0
[c000001f3953fd80] [c0000000001a73ec] .SyS_pread64+0xbc/0xd0
[c000001f3953fe30] [c000000000009780] syscall_exit+0x0/0x7c
Instruction dump:
7f83e378 48001909 60000000 2fbf0000 419e002c e89f00d8 2fa40000 409e0008
e89f0098 e8629fb8 486f7d39 60000000 <0fe00000> 3b200001 4bfffdb4 e8829fa8
---[ end trace a6e6d788c9869e00 ]---
EEH: Detected PCI bus error on device 0006:01:00.0
EEH: This PCI device has failed 1 times in the last hour:
EEH: Bus location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0
EEH: Device location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0
EEH: of node=/pci@800000020000203/pci1014,415@0
EEH: PCI device/vendor: 673c15b3
EEH: PCI cmd/status register: 00100140
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Michael Neuling @ 2012-04-13 2:30 UTC (permalink / raw)
To: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman
Cc: linux-next, ppc-dev, LKML
In-Reply-To: <20120411165835.415e546374a54ea94669b0c6@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Some (not all) of my PowerPC boot tests have failed like this after
> getting into user mode (this one was just after udev started, but others
> are after other processes getting going):
>
> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> Faulting instruction address: 0xc0000000001b7f40
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in: ehea
> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 00c0000003f9d550, DSISR: 40000000
> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> Call Trace:
> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> Instruction dump:
> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
> ---[ end trace 366fe6c7ced3bfb0 ]---
>
> This did not happen yesterday. Just wondering if anyone can think of
> anything obvious. Full console log at
> http://ozlabs.org/~sfr/next-20120411.log.bz2
I managed to bisect this down using pseries_defconfig with next-20120412
to this patch:
commit 85bbc003b24335e253a392f6a9874103b77abb36
Author: Jiri Slaby <jslaby@suse.cz>
Date: Mon Apr 2 13:54:22 2012 +0200
TTY: HVC, use tty from tty_port
The driver already used refcounting. So we just switch it to tty_port
helpers. And switch to tty_port->lock for tty.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
otherwise git barfs) fixes the problem on next-20120412.
I'm assuming we got the ref count changes wrong somewhere in the patch
but the tty code is beyond me. Jiri, can you take a look?
Mikey
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Stephen Rothwell @ 2012-04-13 2:57 UTC (permalink / raw)
To: Michael Neuling; +Cc: Greg Kroah-Hartman, linux-next, ppc-dev, Jiri Slaby, LKML
In-Reply-To: <16710.1334284211@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi all,
On Fri, 13 Apr 2012 12:30:11 +1000 Michael Neuling <mikey@neuling.org> wrote:
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
>
> commit 85bbc003b24335e253a392f6a9874103b77abb36
> Author: Jiri Slaby <jslaby@suse.cz>
> Date: Mon Apr 2 13:54:22 2012 +0200
>
> TTY: HVC, use tty from tty_port
Thanks for that, Mikey.
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.
I will revert those commits form linux-next today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Thang Q. Nguyen @ 2012-04-13 3:29 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: devicetree-discuss, linux-kernel, Rob Herring, linux-ide,
Paul Mackerras, Jeff Garzik, linuxppc-dev
In-Reply-To: <4F8417DB.3040502@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]
Hi,
Two SATA device nodes in bluestone.dts uses the same structure as SATA node
in the canyonlands.dts. All boards having SATA DWC currently use this
structure. So, changing it will need to change all corresponding device
tree. The current sata_dwc_460ex.c agrees with this structure.
I want to give more information for SATA controller on Maui:
- There are 2 SATA controllers on Maui, each has its own register set. But
they use the same DMA registers for processing DMA transfer.
- For DMA transfer, each SATA controller will use its own DMA channel in
the DMA registers.
- DMA controller driver must be supported and enabled in order to issue
SATA DMA transfer.
I agree that declaring the same DMA register information in 2 device nodes
can cause confliction but I think the driver can handle it. In case this
approach is not accepted, I will add only 1 SATA port to the bluestone.dts
and another port will be considered later.
For the APM confidential information from my email, it is added
automatically by the APM system. I have submitted a ticket for asking IT
not adding it into my email and it is in-progress. I will continue to
submit patches after the ticket is processed.
Regards,
Thang Nguyen -
On Tue, Apr 10, 2012 at 6:22 PM, Sergei Shtylyov <sshtylyov@mvista.com>wrote:
> Hello.
>
>
> On 10-04-2012 7:46, Thang Nguyen wrote:
>
> Hi Sergei,
>> Thanks for your review.
>>
>
> On Maui, there are 2 separate SATA controllers but they share the same
>> AHBDMA controller. Each SATA controller is assigned a fixed DMA channel on
>> the AHBDMA (channel 0 is assigned to SATA controller 0 and channel 1 is
>> assigned to SATA controller 1).
>> For the 460EX, there is only 1 SATA controller and it uses channel 0 for
>> transferring data.
>>
>
> In my opinion, in the case of Maui, we can use the same DMA information in
>> 2 device nodes as they use the same DMA controller. And in another CPU, if
>> they use different DMA controller, the corresponding information will also
>> be different.
>>
>
> No, either the DMA controller should be a separate device node, or both
> ports and DMA controller should be packed into the single device node. The
> way you're doing it is incorrect because it creates memory resource
> conflict between devices when they are instantiated as platfrom devices.
>
>
> Regards,
>> Thang Nguyen -
>> -----Original Message-----
>> From: Sergei Shtylyov [mailto:sshtylyov@mvista.com]
>> Sent: Monday, April 09, 2012 5:13 PM
>> To: Thang Q. Nguyen
>> Cc: Benjamin Herrenschmidt; Paul Mackerras; Jeff Garzik; Grant Likely; Rob
>> Herring; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
>> linux-ide@vger.kernel.org; devicetree-discuss@lists.**ozlabs.org<devicetree-discuss@lists.ozlabs.org>
>> Subject: Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change
>> filename from sata_dwc_460ex.c to sata_dwc_4xx.c
>>
>
> Hello.
>>
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>>
>
> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
>>>
>> [...]
>>
>
> diff --git a/arch/powerpc/boot/dts/**bluestone.dts
>>>
>> b/arch/powerpc/boot/dts/**bluestone.dts
>>
>>> index cfa23bf..803fda6 100644
>>> --- a/arch/powerpc/boot/dts/**bluestone.dts
>>> +++ b/arch/powerpc/boot/dts/**bluestone.dts
>>> @@ -155,6 +155,27 @@
>>> /*RXDE*/ 0x5 0x4>;
>>> };
>>>
>>> + /* SATA DWC devices */
>>> + SATA0: sata@bffd1000 {
>>> + compatible = "amcc,sata-apm821xx";
>>> + reg =<4 0xbffd1000 0x800 /* SATA0 */
>>> + 4 0xbffd0800 0x400>; /* AHBDMA */
>>> + dma-channel=<0>;
>>> + interrupt-parent =<&UIC0>;
>>> + interrupts =<26 4 /* SATA0 */
>>> + 25 4>; /* AHBDMA */
>>> + };
>>> +
>>> + SATA1: sata@bffd1800 {
>>> + compatible = "amcc,sata-apm821xx";
>>> + reg =<4 0xbffd1800 0x800 /* SATA1 */
>>> + 4 0xbffd0800 0x400>; /* AHBDMA */
>>> + dma-channel=<1>;
>>> + interrupt-parent =<&UIC0>;
>>> + interrupts =<27 4 /* SATA1 */
>>> + 25 4>; /* AHBDMA */
>>> + };
>>> +
>>>
>>
> So, this is dual SATA controller, not dual port SATA controller?
>> BTW, it's wrong to have the same AHBDMA resource in two device nodes I
>> think.
>>
>
> MBR, Sergei
>>
>
> Can you get rid of the following? It looks stupid when you post to the
> maliing list.
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
>> is for the sole use of the intended recipient(s) and contains information
>> that is confidential and proprietary to AppliedMicro Corporation or its
>> subsidiaries.
>> It is to be used solely for the purpose of furthering the parties'
>> business relationship.
>> All unauthorized review, use, disclosure or distribution is prohibited.
>> If you are not the intended recipient, please contact the sender by reply
>> e-mail
>> and destroy all copies of the original message.
>>
>
> WBR, Sergei
>
--
*Thang Q. Nguyen **|** Staff SW Eng.*
C: +849.7684.7607 | O: +848.3770.0640
F: +848.3770.0641 | tqnguyen@apm.com
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 10323 bytes --]
^ permalink raw reply
* RE: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Thang Nguyen @ 2012-04-13 7:18 UTC (permalink / raw)
To: Jeff Garzik, Sergei Shtylyov
Cc: Phong Vo, devicetree-discuss, linux-kernel, Rob Herring,
linux-ide, Paul Mackerras, linuxppc-dev
In-Reply-To: <4F873573.10406@pobox.com>
Thanks Jeff and Sergei,
As your suggestion, I will separate the patch into smaller patches and
support more features on the SATA DWC driver. The patches I intend to do
on the SATA DWC are as below:
- Support hardreset: currently the hardreset is not supported. This
causes sometime the SATA driver does cause kernel crash because of
not-determined state.
- Let device tree specified DMA channel: currently only channel 0 is
supported (number of channel is set to 1). If device tree not specified
DMA channel, channel 0 will be used as default.
- Support ATAPI.
- Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
for QC completion: transfer completion and DMA transfer completion
interrupt. The current code wait for both 2 interrupts occur before
calling qc_complete. This will make out-of-sync state when an interrupt
lost or when errors occur. The change will process DMA register when DMA
transfer complete interrupt occur and call qc_issue when command
completion interrupt occur.
- Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
- Support Port Multiplier.
- Support 2 SATA ports on Maui.
Regards,
Thang Nguyen-
-----Original Message-----
From: Jeff Garzik [mailto:jgpobox@gmail.com] On Behalf Of Jeff Garzik
Sent: Friday, April 13, 2012 3:05 AM
To: Sergei Shtylyov
Cc: Thang Q. Nguyen; Benjamin Herrenschmidt; Paul Mackerras; Grant Likely;
Rob Herring; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
linux-ide@vger.kernel.org; devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change
filename from sata_dwc_460ex.c to sata_dwc_4xx.c
On 04/03/2012 07:56 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>
>> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
>> ---
>> Changes for v2:
>> - Use git rename feature to change the driver to the newname and for
>> easier review.
>
>> arch/powerpc/boot/dts/bluestone.dts | 21 +
>> drivers/ata/Makefile | 2 +-
>> drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} | 1371
>> ++++++++++++++--------
>> 3 files changed, 904 insertions(+), 490 deletions(-)
>> rename drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} (56%)
>
> You submitted a magapatch doing several things at once (some even
> needlessly) and even in two areas of the kernel. This needs proper
> splitting/description.
Agreed...
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Jiri Slaby @ 2012-04-13 8:02 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <16710.1334284211@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]
On 04/13/2012 04:30 AM, Michael Neuling wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Some (not all) of my PowerPC boot tests have failed like this after
>> getting into user mode (this one was just after udev started, but others
>> are after other processes getting going):
>>
>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>> Faulting instruction address: 0xc0000000001b7f40
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=32 NUMA pSeries
>> Modules linked in: ehea
>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
>> SOFTE: 1
>> CFAR: 000000000000562c
>> DAR: 00c0000003f9d550, DSISR: 40000000
>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>> Call Trace:
>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>> Instruction dump:
>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>
>> This did not happen yesterday. Just wondering if anyone can think of
>> anything obvious. Full console log at
>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
>
> commit 85bbc003b24335e253a392f6a9874103b77abb36
> Author: Jiri Slaby <jslaby@suse.cz>
> Date: Mon Apr 2 13:54:22 2012 +0200
>
> TTY: HVC, use tty from tty_port
>
> The driver already used refcounting. So we just switch it to tty_port
> helpers. And switch to tty_port->lock for tty.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.
>
> I'm assuming we got the ref count changes wrong somewhere in the patch
> but the tty code is beyond me. Jiri, can you take a look?
Yeah, I see. I forgot to remove a couple of tty reference drops. The
reference is dropped by tty_port_tty_set in open/close/hangup now. Does
the attached patch help?
thanks,
--
js
suse labs
[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1157 bytes --]
>From cc51efe721f5aa184e119c52c661a1faf865e492 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/tty/hvc/hvc_console.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..260d4f2 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -338,7 +338,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +392,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +431,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* Re: linux-next: boot failures with next-20120411
From: Jiri Slaby @ 2012-04-13 8:04 UTC (permalink / raw)
To: Jiri Slaby
Cc: Stephen Rothwell, Michael Neuling, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <4F87DD92.4090601@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]
On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> On 04/13/2012 04:30 AM, Michael Neuling wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Some (not all) of my PowerPC boot tests have failed like this after
>>> getting into user mode (this one was just after udev started, but others
>>> are after other processes getting going):
>>>
>>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>>> Faulting instruction address: 0xc0000000001b7f40
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in: ehea
>>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
>>> SOFTE: 1
>>> CFAR: 000000000000562c
>>> DAR: 00c0000003f9d550, DSISR: 40000000
>>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
>>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
>>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
>>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
>>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
>>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
>>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
>>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
>>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>>> Call Trace:
>>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>>> Instruction dump:
>>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
>>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
>>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>>
>>> This did not happen yesterday. Just wondering if anyone can think of
>>> anything obvious. Full console log at
>>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>>
>> I managed to bisect this down using pseries_defconfig with next-20120412
>> to this patch:
>>
>> commit 85bbc003b24335e253a392f6a9874103b77abb36
>> Author: Jiri Slaby <jslaby@suse.cz>
>> Date: Mon Apr 2 13:54:22 2012 +0200
>>
>> TTY: HVC, use tty from tty_port
>>
>> The driver already used refcounting. So we just switch it to tty_port
>> helpers. And switch to tty_port->lock for tty.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
>> otherwise git barfs) fixes the problem on next-20120412.
>>
>> I'm assuming we got the ref count changes wrong somewhere in the patch
>> but the tty code is beyond me. Jiri, can you take a look?
>
> Yeah, I see. I forgot to remove a couple of tty reference drops. The
> reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> the attached patch help?
And the patch is incomplete. Now we have a leak. This one should work.
> thanks,
--
js
suse labs
[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]
>From 7a55e2976cb5a47e499a6db335ad30ecac2e621c Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* Re: linux-next: boot failures with next-20120411
From: Michael Neuling @ 2012-04-13 8:09 UTC (permalink / raw)
To: Jiri Slaby
Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <4F87DE23.9010907@suse.cz>
Jiri Slaby <jslaby@suse.cz> wrote:
> On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> > On 04/13/2012 04:30 AM, Michael Neuling wrote:
> >> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Some (not all) of my PowerPC boot tests have failed like this after
> >>> getting into user mode (this one was just after udev started, but others
> >>> are after other processes getting going):
> >>>
> >>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> >>> Faulting instruction address: 0xc0000000001b7f40
> >>> Oops: Kernel access of bad area, sig: 11 [#1]
> >>> SMP NR_CPUS=32 NUMA pSeries
> >>> Modules linked in: ehea
> >>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> >>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
> >>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
> >>> SOFTE: 1
> >>> CFAR: 000000000000562c
> >>> DAR: 00c0000003f9d550, DSISR: 40000000
> >>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> >>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
> >>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
> >>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
> >>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
> >>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
> >>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
> >>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
> >>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
> >>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> >>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> >>> Call Trace:
> >>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> >>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> >>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> >>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> >>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> >>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> >>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> >>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> >>> Instruction dump:
> >>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
> >>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
> >>> ---[ end trace 366fe6c7ced3bfb0 ]---
> >>>
> >>> This did not happen yesterday. Just wondering if anyone can think of
> >>> anything obvious. Full console log at
> >>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> >>
> >> I managed to bisect this down using pseries_defconfig with next-20120412
> >> to this patch:
> >>
> >> commit 85bbc003b24335e253a392f6a9874103b77abb36
> >> Author: Jiri Slaby <jslaby@suse.cz>
> >> Date: Mon Apr 2 13:54:22 2012 +0200
> >>
> >> TTY: HVC, use tty from tty_port
> >>
> >> The driver already used refcounting. So we just switch it to tty_port
> >> helpers. And switch to tty_port->lock for tty.
> >>
> >> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> >> Cc: linuxppc-dev@lists.ozlabs.org
> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> >> otherwise git barfs) fixes the problem on next-20120412.
> >>
> >> I'm assuming we got the ref count changes wrong somewhere in the patch
> >> but the tty code is beyond me. Jiri, can you take a look?
> >
> > Yeah, I see. I forgot to remove a couple of tty reference drops. The
> > reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> > the attached patch help?
>
> And the patch is incomplete. Now we have a leak. This one should work.
Fixes the problem here.. Thanks.
Tested-by: Michael Neuling <mikey@neuling.org>
^ permalink raw reply
* [PATCH 1/1] TTY: hvc, fix TTY refcounting
From: Jiri Slaby @ 2012-04-13 8:31 UTC (permalink / raw)
To: gregkh; +Cc: Stephen Rothwell, ppc-dev, linux-kernel, jirislaby
In-Reply-To: <5050.1334304567@neuling.org>
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* userspace o/p to kernel buffer
From: Sumesh Kaana @ 2012-04-13 9:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Hi,
How do I capture all the output of user-space programs into a kernel buffer so that I can later read it using debugger ? My board doesn't have a console (no serial, no network). Any direction would be of great help.
sumesh.
[-- Attachment #2: Type: text/html, Size: 543 bytes --]
^ permalink raw reply
* RE: userspace o/p to kernel buffer
From: Jenkins, Clive @ 2012-04-13 11:15 UTC (permalink / raw)
To: Sumesh Kaana, linuxppc-dev
In-Reply-To: <BLU124-W23D62A308B2F33EC51A3D2B43B0@phx.gbl>
> How do I capture all the output of user-space programs into
> a kernel buffer so that I can later read it using debugger ?
>=A0My board doesn't have a console (no serial, no network).
Assuming you are using a shell to start your user-space
programs, you could easily redirect output to /dev/kmsg
then find it in the dmesg buffer afterwards. You may need
to increase the buffer size.
Clive
^ permalink raw reply
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Jeff Garzik @ 2012-04-13 14:20 UTC (permalink / raw)
To: Thang Nguyen
Cc: Sergei Shtylyov, Phong Vo, devicetree-discuss, linux-kernel,
Rob Herring, linux-ide, Paul Mackerras, linuxppc-dev
In-Reply-To: <3445364d6d28c2b6ae19817fe6851452@mail.gmail.com>
On 04/13/2012 03:18 AM, Thang Nguyen wrote:
> Thanks Jeff and Sergei,
>
> As your suggestion, I will separate the patch into smaller patches and
> support more features on the SATA DWC driver. The patches I intend to do
> on the SATA DWC are as below:
> - Support hardreset: currently the hardreset is not supported. This
> causes sometime the SATA driver does cause kernel crash because of
> not-determined state.
> - Let device tree specified DMA channel: currently only channel 0 is
> supported (number of channel is set to 1). If device tree not specified
> DMA channel, channel 0 will be used as default.
> - Support ATAPI.
> - Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
> for QC completion: transfer completion and DMA transfer completion
> interrupt. The current code wait for both 2 interrupts occur before
> calling qc_complete. This will make out-of-sync state when an interrupt
> lost or when errors occur. The change will process DMA register when DMA
> transfer complete interrupt occur and call qc_issue when command
> completion interrupt occur.
> - Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
> - Support Port Multiplier.
> - Support 2 SATA ports on Maui.
Sounds good, thanks for splitting up the patch into smaller pieces. The
main goal is that separate logical changes should go into separate patches.
Jeff
^ permalink raw reply
* Re: [PATCH] powerpc/e6500: add CPU_FTR_EMB_HV to CPU table
From: Kumar Gala @ 2012-04-13 15:29 UTC (permalink / raw)
To: Scott Wood; +Cc: Marcelo Tosatti, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20120411202752.GA12204@schlenkerla.am.freescale.net>
On Apr 11, 2012, at 3:27 PM, Scott Wood wrote:
> e6500 support (commit 10241842fbe900276634fee8d37ec48a7d8a762f,
> "powerpc: Add initial e6500 cpu support" and the introduction of
> CPU_FTR_EMB_HV (commit 73196cd364a2d972d73fa08da9d81ca3215bed68,
> "KVM: PPC: e500mc support") collided during merge, leaving e6500's CPU
> table entry missing CPU_FTR_EMB_HV.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Fixup patch for the KVM merge as requested by Marcelo.
>
> arch/powerpc/include/asm/cputable.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* patch "TTY: hvc, fix TTY refcounting" added to tty tree
From: gregkh @ 2012-04-13 17:54 UTC (permalink / raw)
To: jslaby, gregkh, linuxppc-dev, mikey, sfr
This is a note to let you know that I've just added the patch titled
TTY: hvc, fix TTY refcounting
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also will be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From a2f892060f174e5f90041167ca00eb9e68badcb8 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:31:32 +0200
Subject: TTY: hvc, fix TTY refcounting
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.10
^ permalink raw reply related
* P4080 target has 16G memory stability issues ...
From: Robert Sciuk @ 2012-04-13 20:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: u-boot-request
Dear list(s),
Our P4080 target board is using 2 SODIMM's on each of 2 Controllers
(4x4G DDR3), and we are seeing some memory problems (linux panics) when
beating up large amounts of memory (just under the 16G), on multiple
threads (7 or 8 CPUs).
Our DDR3 configuration is derived from the SPD dump of U-Boot, and we
are using a version based upon the 2011.09 release of U-Boot. Our
firmware memory test, limited as it is to 2G chunks, and a single CPU
shows no problem, it is only using a small test program under Linux and
using multiple cpu's that we see the problems, and we can reproduce the
problem at will, although reducing our memory speed via the RCW does
seem to ameliorate the problem somewhat.
Questions:
- is anyone using a similar configuration?
- is anyone aware of limitations in the U-Boot 2011.09R version
of the mpc8xxx/ddr/* code we need to be aware of?
- any ideas?
We've been pounding our heads on this for a while now, and I'm just
wondering if we are covering old territory here.
Cheers,
Rob.
Robert Sciuk
Senior Designer, R&D.
905.738.3741 xt 22621
^ permalink raw reply
* [PATCH] powerpc/fsl: Distribute interrupts on all CPUs by default
From: Kim Phillips @ 2012-04-13 22:26 UTC (permalink / raw)
To: linuxppc-dev
At least for crypto/IPSec, doing so provides users with a better
performance experience out of the box.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..13e7f3c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -32,6 +32,7 @@ CONFIG_HIGH_RES_TIMERS=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_KEXEC=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_FSL_LBC=y
CONFIG_PCI=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 7ed8d4c..00c49b9 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -23,6 +23,7 @@ CONFIG_P5020_DS=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_RAPIDIO=y
CONFIG_FSL_RIO=y
CONFIG_NET=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index abdcd31..608ccc6 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -45,6 +45,7 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
CONFIG_MATH_EMULATION=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_PCI=y
CONFIG_PCI_MSI=y
--
1.7.10
^ permalink raw reply related
* [PATCH 1/4] powerpc/mpic_msgr: fix compile error when SMP disabled
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0:
~/arch/powerpc/include/asm/mpic_msgr.h: In function 'mpic_msgr_set_destination':
~/arch/powerpc/include/asm/mpic_msgr.h:117:2:
error: implicit declaration of function 'get_hard_smp_processor_id'
make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/include/asm/mpic_msgr.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
index 3ec37dc..326d33c 100644
--- a/arch/powerpc/include/asm/mpic_msgr.h
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/spinlock.h>
+#include <asm/smp.h>
struct mpic_msgr {
u32 __iomem *base;
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/4] powerpc/mpic_msgr: add lock for MPIC message global variable
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-1-git-send-email-Mingkai.hu@freescale.com>
Also fix issue of accessing invalid msgr pointer issue. The local
msgr pointer in fucntion mpic_msgr_get will be accessed before
getting a valid address which will cause kernel crash.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 6e7fa38..dc1cfe3 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -27,6 +27,7 @@
static struct mpic_msgr **mpic_msgrs;
static unsigned int mpic_msgr_count;
+static DEFINE_RAW_SPINLOCK(msgrs_lock);
static inline void _mpic_msgr_mer_write(struct mpic_msgr *msgr, u32 value)
{
@@ -56,12 +57,11 @@ struct mpic_msgr *mpic_msgr_get(unsigned int reg_num)
if (reg_num >= mpic_msgr_count)
return ERR_PTR(-ENODEV);
- raw_spin_lock_irqsave(&msgr->lock, flags);
- if (mpic_msgrs[reg_num]->in_use == MSGR_FREE) {
- msgr = mpic_msgrs[reg_num];
+ raw_spin_lock_irqsave(&msgrs_lock, flags);
+ msgr = mpic_msgrs[reg_num];
+ if (msgr->in_use == MSGR_FREE)
msgr->in_use = MSGR_INUSE;
- }
- raw_spin_unlock_irqrestore(&msgr->lock, flags);
+ raw_spin_unlock_irqrestore(&msgrs_lock, flags);
return msgr;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/4] powerpc/mpic_msgr: fix offset error when setting mer register
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-2-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index dc1cfe3..483d8fa 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -228,7 +228,7 @@ static __devinit int mpic_msgr_probe(struct platform_device *dev)
reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
- msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
+ msgr->mer = (u32 *)((u8 *)msgr->base + MPIC_MSGR_MER_OFFSET);
msgr->in_use = MSGR_FREE;
msgr->num = i;
raw_spin_lock_init(&msgr->lock);
--
1.7.5.1
^ permalink raw reply related
* [PATCH 4/4] powerpc/mpc85xx: add MPIC message dts node
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-3-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 +++++
2 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
new file mode 100644
index 0000000..1cf0b77
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
@@ -0,0 +1,43 @@
+/*
+ * PQ3 MPIC Message (Group B) device tree stub [ controller @ offset 0x42400 ]
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+message@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ interrupts = <
+ 0xb4 2 0 0
+ 0xb5 2 0 0
+ 0xb6 2 0 0
+ 0xb7 2 0 0>;
+};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
index fdedf7b..71c30eb 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
@@ -53,6 +53,16 @@ timer@41100 {
3 0 3 0>;
};
+message@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ interrupts = <
+ 0xb0 2 0 0
+ 0xb1 2 0 0
+ 0xb2 2 0 0
+ 0xb3 2 0 0>;
+};
+
msi@41600 {
compatible = "fsl,mpic-msi";
reg = <0x41600 0x80>;
--
1.7.5.1
^ permalink raw reply related
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