RE: NAND BBT corruption on MPC83xx
Mike: It is not a permanent damage thing. A read disturb does no permanent damage to the chip but if the read disturb event involves more bits than can be corrected by your ECC code, it can do permanent damage to the *DATA* you've stored in that block. For this reason, a good flash management system manages to at least occasionally read through *ALL* of the in-use blocks in the device so that single-bit errors can be scrubbed out (read and successfully corrected) before an adjacent bit in the block also fails (which would eventually lead to a multi-bit error that might be beyond the ability to be corrected by the ECC). As far as I know (and I'm sure the list will correct me if I'm wrong! ;-) ), neither UBI nor UBIFS nor any Linux layer provides this routine scrubbing; you have to code it up yourself, probably by accessing the device at the UBI (underlying block device/LEB) layer. Atlant -Original Message- From: linux-mtd-boun...@lists.infradead.org [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of Mike Hench Sent: Saturday, June 18, 2011 13:55 To: Scott Wood; Matthew L. Creech Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org Subject: RE: NAND BBT corruption on MPC83xx Scott Wood wrote: As for the corruption, could it be degradation from repeated reads of that one page? Read Disturb. I Did not know SLC did that. It just takes 10x as long as MLC, on the order of a million reads. Supposedly erasing the block fixes it. It is not a permanent damage thing. I was seeing ~9 hours before failure with heavy writes. ~4GByte/hour = 2M pages, total ~18 million reads before errors in that last block showed up. Cool. Now we know. Thanks. Mike Hench __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: NAND BBT corruption on MPC83xx
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood scottw...@freescale.com wrote: As for the corruption, could it be degradation from repeated reads of that one page? Could be. I think Mike's theory was that the -1 page_addr sort of wrapped around, and caused us to read in the last block on flash each time NAND_CMD_PAGEPROG was performed. So with a lot of writes happening, we could end up with a BBT that looks like this. That makes sense I guess, since set_addr() in fsl_elbc_nand.c uses page_addr to set FBAR. I don't see anything about it in the manual, but if FBAR wraps beyond the end of the chip, maybe the bits that don't make sense are simply ignored. (In which case we should probably add a check in set_addr() to prevent anything like this in the future) In theory I should be able to prove it out by running 2 devices in parallel - one with that block of code still there, and one with it removed. If the former device sees bit-flips in the BBT and the latter one doesn't, we'll be sure of the culprit. I'll try this and come back with the results. Thanks! -- Matthew L. Creech ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] powerpc: add support for MPIC message register API
On Sat, 18 Jun 2011 08:58:53 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-06-17 at 11:58 -0500, Scott Wood wrote: When did this change from considered an internal implementation issue, and not really an interface to all new interfaces? Interesting blurb... that's not everybody's opinion and I would argue that supporting AMP kernels isn't something we want to do with closed source crap. I'm not advocating closed source crap, just that if something is policy (as opposed to opinion), it'd be nice if the documentation actually matched. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi/fsl_spi: fix CPM spi driver
This patch fixes the freescale spi driver for CPM. Without this
patch SPI on CPM failed because cpm_muram_alloc_fixed tries to
allocate muram in an preserved area. The error reported was:
mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram
mpc8xxx_spi: probe of f0011a80.spi failed with error -12
Now the driver uses of_iomap to get access to this area
similar to i2c driver driver in the i2c-cpm.c which has a
similar device tree node. This is tested on a MPC8247 with CPM2.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Grant Likely grant.lik...@secretlab.ca
cc: spi-devel-gene...@lists.sourceforge.net
---
This was the same problem reported and discussed on ppc-dev for CPM1:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085739.html
drivers/spi/spi_fsl_spi.c | 28 +++-
1 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi_fsl_spi.c b/drivers/spi/spi_fsl_spi.c
index 7963c9b..ca57edf 100644
--- a/drivers/spi/spi_fsl_spi.c
+++ b/drivers/spi/spi_fsl_spi.c
@@ -684,7 +684,7 @@ static unsigned long fsl_spi_cpm_get_pram(struct
mpc8xxx_spi *mspi)
struct device_node *np = dev-of_node;
const u32 *iprop;
int size;
- unsigned long spi_base_ofs;
+ void __iomem *spi_base;
unsigned long pram_ofs = -ENOMEM;
/* Can't use of_address_to_resource(), QE muram isn't at 0. */
@@ -702,33 +702,27 @@ static unsigned long fsl_spi_cpm_get_pram(struct
mpc8xxx_spi *mspi)
return pram_ofs;
}
- /* CPM1 and CPM2 pram must be at a fixed addr. */
- if (!iprop || size != sizeof(*iprop) * 4)
- return -ENOMEM;
-
- spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
- if (IS_ERR_VALUE(spi_base_ofs))
- return -ENOMEM;
+ spi_base = of_iomap(np, 1);
+ if (spi_base == NULL)
+ return -EINVAL;
if (mspi-flags SPI_CPM2) {
pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
- if (!IS_ERR_VALUE(pram_ofs)) {
- u16 __iomem *spi_base = cpm_muram_addr(spi_base_ofs);
-
- out_be16(spi_base, pram_ofs);
- }
+ out_be16(spi_base, pram_ofs);
} else {
- struct spi_pram __iomem *pram = cpm_muram_addr(spi_base_ofs);
+ struct spi_pram __iomem *pram = spi_base;
u16 rpbase = in_be16(pram-rpbase);
/* Microcode relocation patch applied? */
if (rpbase)
pram_ofs = rpbase;
- else
- return spi_base_ofs;
+ else {
+ pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
+ out_be16(spi_base, pram_ofs);
+ }
}
- cpm_muram_free(spi_base_ofs);
+ iounmap(spi_base);
return pram_ofs;
}
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] perf_events: Enable idle state tracing for pseries (ppc64)
On Friday 17 June 2011 09:54 AM, Benjamin Herrenschmidt wrote: On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote: Hi, Please find below a patch, which has perf_events added for pseries (ppc64) platform in order to emit the trace required for perf timechart. It essentially enables perf timechart for pseries platfrom to analyse power savings events like cpuidle states. Unless I'm mistaken, you added traces to dedicated CPU idle sleep but not shared processor. Any reason ? Yes, the traces were added only to dedicated CPU idle sleep and not for shared processor. This was added only for RFC purpose, and looking for comments from trace implementation point of view. This can be easily extended to the latter too. Also I don't really know that tracing stuff but what's the point of having start/end _and trace_cpu_idle if you're going to always start end around a single occurence of trace_cpu_idle ? power_start/end are the APIs that were used initially and they are going to be deprecated in the upcoming kernel releases. trace_cpu_idle call is going to replace power start/end routines. To maintain backward compatibility and uniformity, both the routines have been used. (ref:https://lkml.org/lkml/2010/11/14/60) Wouldn't there be a way to start/end and then trace the snooze and subsequent cede within the same start/end section or that makes no sense ? We wanted to find the residency time of both Snooze as well as cede separately. Knowing this will help us tweak our cpuidle code. So, both have been captured separately. Also would there be any interest in doing the tracing more generically in idle.c ? Yes, this tracing is already implemented for Intel platform. This would be a part of cpuidle framework. Going further, once the power cpuidle framework is ported and ready, we will extend this trace there as well. (ref:https://lkml.org/lkml/2011/6/7/375) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Regards, Deepthi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] perf_events: Enable idle state tracing for pseries (ppc64)
On Mon, 2011-06-20 at 22:48 +0530, deepthi wrote: On Friday 17 June 2011 09:54 AM, Benjamin Herrenschmidt wrote: On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote: Hi, Please find below a patch, which has perf_events added for pseries (ppc64) platform in order to emit the trace required for perf timechart. It essentially enables perf timechart for pseries platfrom to analyse power savings events like cpuidle states. Unless I'm mistaken, you added traces to dedicated CPU idle sleep but not shared processor. Any reason ? Yes, the traces were added only to dedicated CPU idle sleep and not for shared processor. This was added only for RFC purpose, and looking for comments from trace implementation point of view. This can be easily extended to the latter too. Please do both. Also I don't really know that tracing stuff but what's the point of having start/end _and trace_cpu_idle if you're going to always start end around a single occurence of trace_cpu_idle ? power_start/end are the APIs that were used initially and they are going to be deprecated in the upcoming kernel releases. trace_cpu_idle call is going to replace power start/end routines. To maintain backward compatibility and uniformity, both the routines have been used. (ref:https://lkml.org/lkml/2010/11/14/60ref:https://lkml.org/lkml/2010/11/14/60) Backward compatible with what ? Userspace ? Do we care in that specific case since it's a new feature ? Wouldn't there be a way to start/end and then trace the snooze and subsequent cede within the same start/end section or that makes no sense ? We wanted to find the residency time of both Snooze as well as cede separately. Knowing this will help us tweak our cpuidle code. So, both have been captured separately. Also would there be any interest in doing the tracing more generically in idle.c ? Yes, this tracing is already implemented for Intel platform. This would be a part of cpuidle framework. Going further, once the power cpuidle framework is ported and ready, we will extend this trace there as well. (ref:https://lkml.org/lkml/2011/6/7/375) So do we need to apply this patch at all since the cpuidle stuff is happening too ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH V1 1/7] cpuidle: create bootparam cpuidle.off=1
On 06/17/2011 09:59 AM, Benjamin Herrenschmidt wrote:
On Tue, 2011-06-07 at 21:59 +0530, Trinabh Gupta wrote:
From: Len Brownlen.br...@intel.com
useful for disabling cpuidle to fall back
to architecture-default idle loop
cpuidle drivers and governors will fail to register.
on x86 they'll say so:
intel_idle: intel_idle yielding to (null)
ACPI: acpi_idle yielding to (null)
Signed-off-by: Len Brownlen.br...@intel.com
---
Hi Ben,
Thanks for the review.
When you carry over somebody's patch like this you need to also add your
own signed-off-by.
Ok, thanks
Have those generic changes been reviewed by whoever is in charge of that
cpuidle framework ?
These patches were posted by Len Brown himself who is ACPI, Intel Idle
cpuidle driver maintainer. He pulled in most of the patches that were
part of that series (https://lkml.org/lkml/2011/4/2/8)
in 3.0-rc1, but these few patches are still out there. These changes
(removal of pm_idle) have already been agreed upon as they were
initially reported by Peter Zijlstra himself
(http://lkml.org/lkml/2009/8/28/43).
Thanks
-Trinabh
Cheers,
Ben.
Documentation/kernel-parameters.txt |3 +++
drivers/cpuidle/cpuidle.c | 10 ++
drivers/cpuidle/cpuidle.h |1 +
drivers/cpuidle/driver.c|3 +++
drivers/cpuidle/governor.c |3 +++
5 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index d9a203b..5697faf 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -546,6 +546,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
/proc/pid/coredump_filter.
See also Documentation/filesystems/proc.txt.
+ cpuidle.off=1 [CPU_IDLE]
+ disable the cpuidle sub-system
+
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
Format:
first_slot,last_slot,port,enum_bit[,debug]
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 406be83..a171b9e 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -28,6 +28,12 @@ LIST_HEAD(cpuidle_detected_devices);
static void (*pm_idle_old)(void);
static int enabled_devices;
+static int off __read_mostly;
+
+int cpuidle_disabled(void)
+{
+ return off;
+}
#if defined(CONFIG_ARCH_HAS_CPU_IDLE_WAIT)
static void cpuidle_kick_cpus(void)
@@ -397,6 +403,9 @@ static int __init cpuidle_init(void)
{
int ret;
+ if (cpuidle_disabled())
+ return -ENODEV;
+
pm_idle_old = pm_idle;
ret = cpuidle_add_class_sysfs(cpu_sysdev_class);
@@ -408,4 +417,5 @@ static int __init cpuidle_init(void)
return 0;
}
+module_param(off, int, 0444);
core_initcall(cpuidle_init);
diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
index 33e50d5..38c3fd8 100644
--- a/drivers/cpuidle/cpuidle.h
+++ b/drivers/cpuidle/cpuidle.h
@@ -13,6 +13,7 @@ extern struct list_head cpuidle_governors;
extern struct list_head cpuidle_detected_devices;
extern struct mutex cpuidle_lock;
extern spinlock_t cpuidle_driver_lock;
+extern int cpuidle_disabled(void);
/* idle loop */
extern void cpuidle_install_idle_handler(void);
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 33e3189..284d7af 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -50,6 +50,9 @@ int cpuidle_register_driver(struct cpuidle_driver *drv)
if (!drv)
return -EINVAL;
+ if (cpuidle_disabled())
+ return -ENODEV;
+
spin_lock(cpuidle_driver_lock);
if (cpuidle_curr_driver) {
spin_unlock(cpuidle_driver_lock);
diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c
index 724c164..ea2f8e7 100644
--- a/drivers/cpuidle/governor.c
+++ b/drivers/cpuidle/governor.c
@@ -81,6 +81,9 @@ int cpuidle_register_governor(struct cpuidle_governor *gov)
if (!gov || !gov-select)
return -EINVAL;
+ if (cpuidle_disabled())
+ return -ENODEV;
+
mutex_lock(cpuidle_lock);
if (__cpuidle_find_governor(gov-name) == NULL) {
ret = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
