Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/8/15 Artem Bityutskiy : > On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote: >> + /* we are using here the whole MTD device size and not >> + * the MTD partition size because the maximum number of >> + * bad blocks is a percentage of the whole device and >> + * the bad blocks are not fairly disposed on a flash >> + * device >> + */ > > Would you please use proper kernel-style comments instead, to be > consistent with the rest of the UBI code? I've amended this one, but > wanted to note for future. ok, sorry for that. > > I've re-based your patch against the latest UBI. I've also tried to > improve the Kconfig help message as well. Below is the patch I ended up > with. > > > From cb14c6c5455443cbe960a36e77b3fcd0e5bc7152 Mon Sep 17 00:00:00 2001 > From: Richard Genoud > Date: Tue, 10 Jul 2012 18:23:41 +0200 > Subject: [PATCH 2/2] UBI: use the whole MTD device size to get bad_peb_limit > > On NAND flash devices, UBI reserves some physical erase blocks (PEB) for > bad block handling. Today, the number of reserved PEB can only be set as a > percentage of the total number of PEB in each MTD partition. For example, for > a > NAND flash with 128KiB PEB, 2 MTD partition of 20MiB (mtd0) and 100MiB (mtd1) > and 2% reserved PEB: > - the UBI device on mtd0 will have 2 PEB reserved > - the UBI device on mtd1 will have 16 PEB reserved > > The problem with this behaviour is that NAND flash manufacturers give a > minimum number of valid block (NVB) during the endurance life of the > device, e.g.: > > Parameter SymbolMinMaxUnit Notes > -- > Valid block number NVB 10041024 Blocks 1 > Note: > 1. Invalid blocks are block that contain one or more bad bits beyond > ECC. The device may contain bad blocks upon shipment. Additional bad > blocks may develop over time; however, the total number of available > blocks will not drop below NVB during the endurance life of the device. > > From this number we can deduce the maximum number of bad PEB that a device > will > contain during its endurance life: a 128MiB NAND flash (1024 PEB) will not > have > less than 20 bad blocks during the flash endurance life. > > But the manufacturer doesn't tell where those bad block will appear. He > doesn't > say either if they will be equally disposed on the whole device (and I'm > pretty > sure they won't). So, according to the datasheets, we should reserve the > maximum number of bad PEB for each UBI device (worst case scenario: 20 bad > blocks appears on the smallest MTD partition). > > So this patch make UBI use the whole MTD device size to calculate the maximum > bad expected eraseblocks. > > The Kconfig option is in per1024 blocks, thus it can have a default value of > 20 > which is *very* common for NAND devices. > > Signed-off-by: Richard Genoud > Signed-off-by: Artem Bityutskiy > --- > drivers/mtd/ubi/Kconfig | 27 +-- > drivers/mtd/ubi/build.c | 21 ++--- > 2 files changed, 39 insertions(+), 9 deletions(-) > > diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig > index b2f4f0f..98bda6c 100644 > --- a/drivers/mtd/ubi/Kconfig > +++ b/drivers/mtd/ubi/Kconfig > @@ -28,14 +28,29 @@ config MTD_UBI_WL_THRESHOLD > to 128 or 256, although it does not have to be power of 2). > > config MTD_UBI_BEB_LIMIT > - int "Percentage of maximum expected bad eraseblocks" > - default 2 > - range 0 25 > + int "Maximum expected bad eraseblock count per 1024 eraseblocks" > + default 20 > + range 2 256 > help > This option specifies the maximum bad physical eraseblocks UBI > - expects on the UBI device (percents of total number of physical > - eraseblocks on this MTD partition). If the underlying flash does not > - admit of bad eraseblocks (e.g. NOR flash), this value is ignored. > + expects on the MTD device (per 1024 eraseblocks). If the underlying > + flash does not admit of bad eraseblocks (e.g. NOR flash), this value > + is ignored. > + > + NAND datasheets often specify the minimum and maximum NVM (Number of > + Valid Blocks) for the flashes' endurance lifetime. The maximum > + expected bad eraseblocks per 1024 eraseblocks then can be calculated > + as "1024 * (1 - MinNVB / MaxNVB)", which gives 20 for most NANDs > + (MaxNVB is basically the total count of eraseblo
Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/8/15 Artem Bityutskiy dedeki...@gmail.com: On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote: + /* we are using here the whole MTD device size and not + * the MTD partition size because the maximum number of + * bad blocks is a percentage of the whole device and + * the bad blocks are not fairly disposed on a flash + * device + */ Would you please use proper kernel-style comments instead, to be consistent with the rest of the UBI code? I've amended this one, but wanted to note for future. ok, sorry for that. I've re-based your patch against the latest UBI. I've also tried to improve the Kconfig help message as well. Below is the patch I ended up with. From cb14c6c5455443cbe960a36e77b3fcd0e5bc7152 Mon Sep 17 00:00:00 2001 From: Richard Genoud richard.gen...@gmail.com Date: Tue, 10 Jul 2012 18:23:41 +0200 Subject: [PATCH 2/2] UBI: use the whole MTD device size to get bad_peb_limit On NAND flash devices, UBI reserves some physical erase blocks (PEB) for bad block handling. Today, the number of reserved PEB can only be set as a percentage of the total number of PEB in each MTD partition. For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB (mtd0) and 100MiB (mtd1) and 2% reserved PEB: - the UBI device on mtd0 will have 2 PEB reserved - the UBI device on mtd1 will have 16 PEB reserved The problem with this behaviour is that NAND flash manufacturers give a minimum number of valid block (NVB) during the endurance life of the device, e.g.: Parameter SymbolMinMaxUnit Notes -- Valid block number NVB 10041024 Blocks 1 Note: 1. Invalid blocks are block that contain one or more bad bits beyond ECC. The device may contain bad blocks upon shipment. Additional bad blocks may develop over time; however, the total number of available blocks will not drop below NVB during the endurance life of the device. From this number we can deduce the maximum number of bad PEB that a device will contain during its endurance life: a 128MiB NAND flash (1024 PEB) will not have less than 20 bad blocks during the flash endurance life. But the manufacturer doesn't tell where those bad block will appear. He doesn't say either if they will be equally disposed on the whole device (and I'm pretty sure they won't). So, according to the datasheets, we should reserve the maximum number of bad PEB for each UBI device (worst case scenario: 20 bad blocks appears on the smallest MTD partition). So this patch make UBI use the whole MTD device size to calculate the maximum bad expected eraseblocks. The Kconfig option is in per1024 blocks, thus it can have a default value of 20 which is *very* common for NAND devices. Signed-off-by: Richard Genoud richard.gen...@gmail.com Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com --- drivers/mtd/ubi/Kconfig | 27 +-- drivers/mtd/ubi/build.c | 21 ++--- 2 files changed, 39 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index b2f4f0f..98bda6c 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -28,14 +28,29 @@ config MTD_UBI_WL_THRESHOLD to 128 or 256, although it does not have to be power of 2). config MTD_UBI_BEB_LIMIT - int Percentage of maximum expected bad eraseblocks - default 2 - range 0 25 + int Maximum expected bad eraseblock count per 1024 eraseblocks + default 20 + range 2 256 help This option specifies the maximum bad physical eraseblocks UBI - expects on the UBI device (percents of total number of physical - eraseblocks on this MTD partition). If the underlying flash does not - admit of bad eraseblocks (e.g. NOR flash), this value is ignored. + expects on the MTD device (per 1024 eraseblocks). If the underlying + flash does not admit of bad eraseblocks (e.g. NOR flash), this value + is ignored. + + NAND datasheets often specify the minimum and maximum NVM (Number of + Valid Blocks) for the flashes' endurance lifetime. The maximum + expected bad eraseblocks per 1024 eraseblocks then can be calculated + as 1024 * (1 - MinNVB / MaxNVB), which gives 20 for most NANDs + (MaxNVB is basically the total count of eraseblocks on the chip). + + To put it differently, if this value is 20, UBI will try to reserve + about 1.9% of physical eraseblocks for bad blocks handling. And that + will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD + partition UBI attaches. This means that if you have, say, if a NAND I don't quite
Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com:
Hi Richard,
Sorry for reviewing this late...
On Tue, 10 Jul 2012 18:23:42 +0200 Richard Genoud richard.gen...@gmail.com
wrote:
-config MTD_UBI_BEB_LIMIT
- int Maximum expected bad eraseblocks per 1024 eraseblocks
- default 20
- range 2 256
I see some benefit keeping the config.
For the simplest systems (those having one ubi device) that need a limit
*other* than the default (20 per 1024), they can simply set the config
to their chosen value, as they were used to.
With you approach, these system MUST pass the limit parameter via the
ioctl / module-parameter.
That's right.
We can add a kernel config option to change the max_beb_per1024
default value (actually, this is almost the patch I send first).
But I see something disturbing with that:
It means that an ubi_attach call from userspace, without specifying
max_beb_per1024, won't have the same result, depending of the default
config value the kernel has been compiled with.
(Or maybe this behavior is acceptable).
+static int get_bad_peb_limit(const struct ubi_device *ubi, int
max_beb_per1024)
+{
+ int device_peb_count;
+ uint64_t device_size;
+ int beb_limit = 0;
+
+ /* this has already been checked in ioctl */
+ if (max_beb_per1024 = 0)
+ goto out;
Can you explain how 'max_beb_per1024 = 0' may happen?
It seems that all of your calls to 'ubi_attach_mtd_dev' pass a positive
max_beb_per1024 value (the default is always set). See your
'ubi_mtd_param_parse' and 'ctrl_cdev_ioctl'. Am I missing something?
Actually it can. But it's because I made a mistake:
p-max_beb_per1024 = bytes_str_to_int(tokens[2]);
= I didn't check the return value of this. It can fail, and if it
does the return value is 0.
I'm going to change that.
Also, since max_beb_per1024 is always set, how one may specify a zero
limit?
You can't.
Do you think we need that ?
0 should be kept for default value, not to break user-space.
But we can use another value for 0, like 1024 or 2048.
(but honestly, I think this will add complexity for an unlikely configuration.)
Regards,
Shmulik
Regards,
Richard.
--
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com:
Hi Artem, Richard,
On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com
wrote:
1. Invalid blocks are block that contain one or more bad bits beyond
ECC.
I would remove this one sentence from the log, it is misleading; invalid
blocks are not necessarily related to ECC.
I agree (even if this sentence is from a nand datasheet !)
if (CONFIG_MTD_UBI_BEB_LIMIT 0) {
- int percent = CONFIG_MTD_UBI_BEB_LIMIT;
- int limit = mult_frac(ubi-peb_count, percent, 100);
+ int per1024 = CONFIG_MTD_UBI_BEB_LIMIT;
+ int limit, device_pebs;
+ uint64_t device_size;
+
+ /*
+ * Here we are using size of the entire flash chip and
+ * not just the MTD partition size because the maximum
+ * number of bad eraseblocks is a percentage of the
+ * whole device and bad eraseblocks are not fairly
+ * distributed over the flash chip. So the worst case
+ * is that all the bad eraseblocks of the chip are in
+ * the MTD partition we are attaching (ubi-mtd).
+ */
+ device_size = mtd_get_device_size(ubi-mtd);
+ device_pebs = mtd_div_by_eb(device_size, ubi-mtd);
+ limit = mult_frac(device_pebs, per1024, 1024);
/* Round it up */
- if (mult_frac(limit, 100, percent) ubi-peb_count)
+ if (mult_frac(limit, 1024, per1024) ubi-peb_count)
Oops... should be:
+ if (mult_frac(limit, 1024, per1024) device_pebs)
Regards,
Shmulik
Ok, I'll change that, may be in a separate patch, as it's a bug fix.
I'll add your signoff.
thanks !
--
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com: Hi, One more thing... On Wed, 15 Aug 2012 18:08:51 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: config MTD_UBI_BEB_LIMIT - int Percentage of maximum expected bad eraseblocks - default 2 - range 0 25 + int Maximum expected bad eraseblock count per 1024 eraseblocks + default 20 + range 2 256 Those defconfigs that explicilty set an original LIMIT should be adjusted as well, as the units have changed, no? you mean that it should be between 0 and 256 ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter
2012/8/16 Shmulik Ladkani shmulik.ladk...@gmail.com: On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: On Thu, 2012-08-16 at 11:57 +0300, Shmulik Ladkani wrote: For the simplest systems (those having one ubi device) that need a limit *other* than the default (20 per 1024), they can simply set the config to their chosen value, as they were used to. With you approach, these system MUST pass the limit parameter via the ioctl / module-parameter. Yeah, when you change the default, you usually need to do an extra step. It does not feel too bad, and I would not keep additional configuration option for a hypothetical user. If someone suffers, we can add an option to change the default. But I'd start without it. So, I think it is OK to remove this. Yes, but the main drawback I was referring to is those platforms already setting MTD_UBI_BEB_RESERVE other than the default, by means of kernel configuration. (there's one platform known to do so in its defconfig, that's sam9_l9260_defconfig, which uses 3% instead of the standard 2%). I found the board: https://www.olimex.com/dev/sam9-L9260.html and the nand datasheet: http://www.rockbox.org/wiki/pub/Main/LyrePrototype/K9xxG08UXM.pdf page 11, we can see that the max_bad_bebper1024 is 25 (100 for 4096) These platforms must now change their usermode code to either pass a module parameter during the insmod or change their attach ioctl of their application. We force these systems to change their usermode because we changed ubi's default BEB limit to be 20/1024 _hardcoded_ (instead of kernel configurable as previously was). Is this ok? well, I don't know, Artem, you're the maintainer :) I made a quick patch on this, if you decide to apply it. Richard -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] splitting UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter
Artem, Here are the 2 patches you requested in place of [PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter I made some changes to correct some things that Shmulik pointed out: * max_beb_per1024 is now an unsigned. * ubi_mtd_param_parse can fail on kstrtouint error. Richard Genoud (2): UBI: replace MTD_UBI_BEB_LIMIT with module parameter UBI: add ioctl for max_beb_per1024 arch/arm/configs/sam9_l9260_defconfig |1 - drivers/mtd/ubi/Kconfig | 26 - drivers/mtd/ubi/build.c | 93 ++--- drivers/mtd/ubi/cdev.c| 10 +++- drivers/mtd/ubi/ubi.h |6 ++- include/mtd/ubi-user.h| 19 ++- 6 files changed, 95 insertions(+), 60 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] UBI: add ioctl for max_beb_per1024
This patch provides the possibility to adjust the maximum expected number of
bad blocks per 1024 blocks (max_beb_per1024) for each mtd device from
UBI_IOCATT ioctl.
The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
We already could adjust that via a kernel parameter, now we can also use
UBI_IOCATT ioctl:
struct ubi_attach_req {
__s32 ubi_num;
__s32 mtd_num;
__s32 vid_hdr_offset;
__u8 max_beb_per1024;
__s8 padding[11];
};
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/mtd/ubi/cdev.c |9 -
include/mtd/ubi-user.h | 19 ++-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/ubi/cdev.c b/drivers/mtd/ubi/cdev.c
index e0027e7..d268b42 100644
--- a/drivers/mtd/ubi/cdev.c
+++ b/drivers/mtd/ubi/cdev.c
@@ -1006,12 +1006,19 @@ static long ctrl_cdev_ioctl(struct file *file, unsigned
int cmd,
}
/*
+* For compatibility with older user-space tools,
+* a zero value should be treated like a default value
+*/
+ if (!req.max_beb_per1024)
+ req.max_beb_per1024 = MTD_UBI_DEFAULT_BEB_LIMIT;
+
+ /*
* Note, further request verification is done by
* 'ubi_attach_mtd_dev()'.
*/
mutex_lock(ubi_devices_mutex);
err = ubi_attach_mtd_dev(mtd, req.ubi_num, req.vid_hdr_offset,
-MTD_UBI_DEFAULT_BEB_LIMIT);
+req.max_beb_per1024);
mutex_unlock(ubi_devices_mutex);
if (err 0)
put_mtd_device(mtd);
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index 8787349..77cd0d1 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -222,6 +222,7 @@ enum {
* @ubi_num: UBI device number to create
* @mtd_num: MTD device number to attach
* @vid_hdr_offset: VID header offset (use defaults if %0)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
* @padding: reserved for future, not used, has to be zeroed
*
* This data structure is used to specify MTD device UBI has to attach and the
@@ -245,12 +246,28 @@ enum {
* be 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes
* aligned, which is OK, as UBI is clever enough to realize this is 4th
* sub-page of the first page and add needed padding.
+ *
+ * The @max_beb_per1024 is the maximum bad eraseblocks UBI expects on the ubi
+ * device per 1024 eraseblocks.
+ * This value is often given in an other form in the NAND datasheet (min NVB
+ * i.e. minimal number of valid blocks). The maximum expected bad eraseblocks
+ * per 1024 is then:
+ * 1024 * (1 - MinNVB / MaxNVB)
+ * Which gives 20 for most NAND devices.
+ * This limit is used in order to derive amount of eraseblock UBI reserves for
+ * handling new bad blocks.
+ * If the device has more bad eraseblocks than this limit, UBI does not reserve
+ * any physical eraseblocks for new bad eraseblocks, but attempts to use
+ * available eraseblocks (if any).
+ * The accepted range is 0-255. If 0 is given, the default value
+ * MTD_UBI_DEFAULT_BEB_LIMIT will be used for compatibility.
*/
struct ubi_attach_req {
__s32 ubi_num;
__s32 mtd_num;
__s32 vid_hdr_offset;
- __s8 padding[12];
+ __u8 max_beb_per1024;
+ __s8 padding[11];
};
/**
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] UBI: replace MTD_UBI_BEB_LIMIT with module parameter
This patch provides the possibility to adjust the maximum expected number of
bad blocks per 1024 blocks (max_beb_per1024) for each mtd device.
The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
Now, we can adjust that via a kernel parameter:
ubi.mtd=name|num|path[,vid_hdr_offs[,max_beb_per1024]]
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
arch/arm/configs/sam9_l9260_defconfig |1 -
drivers/mtd/ubi/Kconfig | 26 -
drivers/mtd/ubi/build.c | 93 ++---
drivers/mtd/ubi/cdev.c|3 +-
drivers/mtd/ubi/ubi.h |6 ++-
5 files changed, 70 insertions(+), 59 deletions(-)
diff --git a/arch/arm/configs/sam9_l9260_defconfig
b/arch/arm/configs/sam9_l9260_defconfig
index d11fea5..47dd71a 100644
--- a/arch/arm/configs/sam9_l9260_defconfig
+++ b/arch/arm/configs/sam9_l9260_defconfig
@@ -39,7 +39,6 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_ATMEL=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_UBI=y
-CONFIG_MTD_UBI_BEB_LIMIT=30
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index f326877..7a57cc0 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -27,32 +27,6 @@ config MTD_UBI_WL_THRESHOLD
life-cycle less than 1, the threshold should be lessened (e.g.,
to 128 or 256, although it does not have to be power of 2).
-config MTD_UBI_BEB_LIMIT
- int Maximum expected bad eraseblock count per 1024 eraseblocks
- default 20
- range 2 256
- help
- This option specifies the maximum bad physical eraseblocks UBI
- expects on the MTD device (per 1024 eraseblocks). If the underlying
- flash does not admit of bad eraseblocks (e.g. NOR flash), this value
- is ignored.
-
- NAND datasheets often specify the minimum and maximum NVM (Number of
- Valid Blocks) for the flashes' endurance lifetime. The maximum
- expected bad eraseblocks per 1024 eraseblocks then can be calculated
- as 1024 * (1 - MinNVB / MaxNVB), which gives 20 for most NANDs
- (MaxNVB is basically the total count of eraseblocks on the chip).
-
- To put it differently, if this value is 20, UBI will try to reserve
- about 1.9% of physical eraseblocks for bad blocks handling. And that
- will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD
- partition UBI attaches. This means that if you have, say, a NAND
- flash chip admits maximum 40 bad eraseblocks, and it is split on two
- MTD partitions of the same size, UBI will reserve 40 eraseblocks when
- attaching a partition.
-
- Leave the default value if unsure.
-
config MTD_UBI_GLUEBI
tristate MTD devices emulation driver (gluebi)
help
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 738772c..65edbc0 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -46,6 +46,8 @@
/* Maximum length of the 'mtd=' parameter */
#define MTD_PARAM_LEN_MAX 64
+#define MTD_PARAM_NB_MAX 3
+
#ifdef CONFIG_MTD_UBI_MODULE
#define ubi_is_module() 1
#else
@@ -57,10 +59,12 @@
* @name: MTD character device node path, MTD device name, or MTD device number
*string
* @vid_hdr_offs: VID header offset
+ * @max_beb_per1024: maximum expected number of bad blocks per 1024 erase
blocks
*/
struct mtd_dev_param {
char name[MTD_PARAM_LEN_MAX];
int vid_hdr_offs;
+ unsigned int max_beb_per1024;
};
/* Numbers of elements set in the @mtd_dev_param array */
@@ -565,9 +569,37 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
}
}
+static int get_bad_peb_limit(const struct ubi_device *ubi,
+unsigned int max_beb_per1024)
+{
+ int device_pebs;
+ uint64_t device_size;
+ int limit = 0;
+
+ /*
+* Here we are using size of the entire flash chip and
+* not just the MTD partition size because the maximum
+* number of bad eraseblocks is a percentage of the
+* whole device and bad eraseblocks are not fairly
+* distributed over the flash chip. So the worst case
+* is that all the bad eraseblocks of the chip are in
+* the MTD partition we are attaching (ubi-mtd).
+*/
+ device_size = mtd_get_device_size(ubi-mtd);
+ device_pebs = mtd_div_by_eb(device_size, ubi-mtd);
+ limit = mult_frac(device_pebs, max_beb_per1024, 1024);
+
+ /* Round it up */
+ if (mult_frac(limit, 1024, max_beb_per1024) device_pebs)
+ limit += 1;
+
+ return limit;
+}
+
/**
* io_init - initialize I/O sub-system for a given UBI device.
* @ubi: UBI device description object
+ * @max_beb_per1024: maximum expected number of bad PEB per 1024 PEB
*
* If @ubi-vid_hdr_offset or @ubi
[PATCH] UBI: use a config value for default BEB limit
This patch provides the possibility to adjust the default value for maximum expected number of bad blocks per 1024 blocks from kernel configuration. sam9_l9260_defconfig has been adjusted as well. The nand device used by this card has a NVB of 3996/4096 ie a MAX_BEB_LIMIT of 25/1024 Signed-off-by: Richard Genoud richard.gen...@gmail.com --- arch/arm/configs/sam9_l9260_defconfig |1 + drivers/mtd/ubi/Kconfig | 29 + drivers/mtd/ubi/ubi.h |2 +- 3 files changed, 31 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/sam9_l9260_defconfig b/arch/arm/configs/sam9_l9260_defconfig index 47dd71a..2c20c9e 100644 --- a/arch/arm/configs/sam9_l9260_defconfig +++ b/arch/arm/configs/sam9_l9260_defconfig @@ -39,6 +39,7 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_NAND_PLATFORM=y CONFIG_MTD_UBI=y +CONFIG_MTD_UBI_DEFAULT_BEB_LIMIT=25 CONFIG_MTD_UBI_GLUEBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index 7a57cc0..30e8370 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -27,6 +27,35 @@ config MTD_UBI_WL_THRESHOLD life-cycle less than 1, the threshold should be lessened (e.g., to 128 or 256, although it does not have to be power of 2). +config MTD_UBI_DEFAULT_BEB_LIMIT + int Maximum expected bad eraseblock count per 1024 eraseblocks + default 20 + range 0 256 + help + This option specifies the default value for maximum bad physical + eraseblocks UBI expects on the MTD device (per 1024 eraseblocks). + It will be used when the maximum bad PEB value is null in the + UBI_IOCATT ioctl (e.g. when calling ubiattach) or in the kernel + parameter ubi.mtd. + If the underlying flash does not admit of bad eraseblocks + (e.g. NOR flash), this value is ignored. + + NAND datasheets often specify the minimum and maximum NVM (Number of + Valid Blocks) for the flashes' endurance lifetime. The maximum + expected bad eraseblocks per 1024 eraseblocks then can be calculated + as 1024 * (1 - MinNVB / MaxNVB), which gives 20 for most NANDs + (MaxNVB is basically the total count of eraseblocks on the chip). + + To put it differently, if this value is 20, UBI will try to reserve + about 1.9% of physical eraseblocks for bad blocks handling. And that + will be 1.9% of eraseblocks on the entire NAND chip, not just the MTD + partition UBI attaches. This means that if you have, say, a NAND + flash chip that admits a maximum 40 bad eraseblocks, and it is split + on two MTD partitions of the same size, UBI will reserve 40 + eraseblocks when attaching a partition. + + Leave the default value if unsure. + config MTD_UBI_GLUEBI tristate MTD devices emulation driver (gluebi) help diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index f926343..39a1e7e 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -51,7 +51,7 @@ #define UBI_NAME_STR ubi /* Default number of maximum expected bad blocks per 1024 eraseblocks */ -#define MTD_UBI_DEFAULT_BEB_LIMIT 20 +#define MTD_UBI_DEFAULT_BEB_LIMIT CONFIG_MTD_UBI_DEFAULT_BEB_LIMIT /* Normal UBI messages */ #define ubi_msg(fmt, ...) printk(KERN_NOTICE UBI: fmt \n, ##__VA_ARGS__) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] trivial: pinctrl core: remove extraneous code lines
In function pinctrl_get_locked, pointer p is returned on error, and also
return on no_error.
So, we just return it with no error test.
It's pretty the same in function pinctrl_lookup_state_locked: state is
returned in every case, so we drop the error test and just return state.
Signed-off-by: Richard Genoud
---
drivers/pinctrl/core.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index fb7f3be..7365d46 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -657,11 +657,7 @@ static struct pinctrl *pinctrl_get_locked(struct device
*dev)
if (p != NULL)
return ERR_PTR(-EBUSY);
- p = create_pinctrl(dev);
- if (IS_ERR(p))
- return p;
-
- return p;
+ return create_pinctrl(dev);
}
/**
@@ -738,10 +734,8 @@ static struct pinctrl_state
*pinctrl_lookup_state_locked(struct pinctrl *p,
dev_dbg(p->dev, "using pinctrl dummy state (%s)\n",
name);
state = create_state(p, name);
- if (IS_ERR(state))
- return state;
} else {
- return ERR_PTR(-ENODEV);
+ state = ERR_PTR(-ENODEV);
}
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Pinctrl header: trivial: declare struct device
As struct device is used as a function argument, it should at least be declared (device.h is not included). Signed-off-by: Richard Genoud --- include/linux/pinctrl/consumer.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h index 6dd96fb..e9b7f43 100644 --- a/include/linux/pinctrl/consumer.h +++ b/include/linux/pinctrl/consumer.h @@ -20,6 +20,7 @@ /* This struct is private to the core and should be regarded as a cookie */ struct pinctrl; struct pinctrl_state; +struct device; #ifdef CONFIG_PINCTRL -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Pinctrl header: trivial: declare struct device
As struct device is used as a function argument, it should at least be declared (device.h is not included). Signed-off-by: Richard Genoud richard.gen...@gmail.com --- include/linux/pinctrl/consumer.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h index 6dd96fb..e9b7f43 100644 --- a/include/linux/pinctrl/consumer.h +++ b/include/linux/pinctrl/consumer.h @@ -20,6 +20,7 @@ /* This struct is private to the core and should be regarded as a cookie */ struct pinctrl; struct pinctrl_state; +struct device; #ifdef CONFIG_PINCTRL -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] trivial: pinctrl core: remove extraneous code lines
In function pinctrl_get_locked, pointer p is returned on error, and also
return on no_error.
So, we just return it with no error test.
It's pretty the same in function pinctrl_lookup_state_locked: state is
returned in every case, so we drop the error test and just return state.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/pinctrl/core.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index fb7f3be..7365d46 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -657,11 +657,7 @@ static struct pinctrl *pinctrl_get_locked(struct device
*dev)
if (p != NULL)
return ERR_PTR(-EBUSY);
- p = create_pinctrl(dev);
- if (IS_ERR(p))
- return p;
-
- return p;
+ return create_pinctrl(dev);
}
/**
@@ -738,10 +734,8 @@ static struct pinctrl_state
*pinctrl_lookup_state_locked(struct pinctrl *p,
dev_dbg(p-dev, using pinctrl dummy state (%s)\n,
name);
state = create_state(p, name);
- if (IS_ERR(state))
- return state;
} else {
- return ERR_PTR(-ENODEV);
+ state = ERR_PTR(-ENODEV);
}
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/7/18 Artem Bityutskiy : > On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote: >> >> The Kconfig option is in per1024 blocks, thus it can have a default >> value of 20 which is *very* common for NAND devices. > > Why do you prefer per1024? I'd make it centi-percent instead, wouldn't > that be more human-friendly. It is just %*100. If I am a user, it is > easy for me to calculate % and multiply that by 100. This per1024 thing > would make me scratch my head... All the NAND devices I've seen are a multiple of 1024 erase blocks, so I thought it'll be easier for the humans to use per1024... here are 2 random datasheets : page 14: http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NAND%20Flash/6691NANDXXX%20A%20128Mb_256Mb_528%20byte_or_264%20word_page_3V_SLC_90nm.pdf 2048 blocks 40BEB max => 20per1024 1024 blocks 20BEB max => 20per1024 page 24: http://www.hynix.com/datasheet/pdf/flash/HY27(U_S)S(08_16)121M(Rev0.6).pdf 4096 blocks 80BEB max => 20per1024 If we express the default exact value of 20 per1024 blocks in percent, that would be 1.953125% (event in per-thousand, we'll have 19.53125). => the value have to be rounded to floor or ceiling and that will make the user unsure about the effective number of bad blocks used for bad block handling. (even if we say that the default value 20 per-thousand block will be used, as the NAND devices have a number of blocks multiple of 1024, for a 4096 blocks device, we'll have 81.92 reserved blocks, rounded to 82 => we loose 2 blocks for each mtd partition.) So the per1024 thing was really to stick to the device layout and to be easier for users (IMHO) Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
2012/7/18 Artem Bityutskiy dedeki...@gmail.com: On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote: The Kconfig option is in per1024 blocks, thus it can have a default value of 20 which is *very* common for NAND devices. Why do you prefer per1024? I'd make it centi-percent instead, wouldn't that be more human-friendly. It is just %*100. If I am a user, it is easy for me to calculate % and multiply that by 100. This per1024 thing would make me scratch my head... All the NAND devices I've seen are a multiple of 1024 erase blocks, so I thought it'll be easier for the humans to use per1024... here are 2 random datasheets : page 14: http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NAND%20Flash/6691NANDXXX%20A%20128Mb_256Mb_528%20byte_or_264%20word_page_3V_SLC_90nm.pdf 2048 blocks 40BEB max = 20per1024 1024 blocks 20BEB max = 20per1024 page 24: http://www.hynix.com/datasheet/pdf/flash/HY27(U_S)S(08_16)121M(Rev0.6).pdf 4096 blocks 80BEB max = 20per1024 If we express the default exact value of 20 per1024 blocks in percent, that would be 1.953125% (event in per-thousand, we'll have 19.53125). = the value have to be rounded to floor or ceiling and that will make the user unsure about the effective number of bad blocks used for bad block handling. (even if we say that the default value 20 per-thousand block will be used, as the NAND devices have a number of blocks multiple of 1024, for a 4096 blocks device, we'll have 81.92 reserved blocks, rounded to 82 = we loose 2 blocks for each mtd partition.) So the per1024 thing was really to stick to the device layout and to be easier for users (IMHO) Richard. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] mtd_is_partition: struct mtd_info should be const
struct mtd_info is not modified by mtd_is_partition so it should be a
const.
Signed-off-by: Richard Genoud
---
drivers/mtd/mtdpart.c |2 +-
include/linux/mtd/partitions.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index d518e4d..8500584 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -744,7 +744,7 @@ int parse_mtd_partitions(struct mtd_info *master, const
char **types,
return ret;
}
-int mtd_is_partition(struct mtd_info *mtd)
+int mtd_is_partition(const struct mtd_info *mtd)
{
struct mtd_part *part;
int ispart = 0;
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 2475228..02a5115 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -79,7 +79,7 @@ struct mtd_part_parser {
extern int register_mtd_parser(struct mtd_part_parser *parser);
extern int deregister_mtd_parser(struct mtd_part_parser *parser);
-int mtd_is_partition(struct mtd_info *mtd);
+int mtd_is_partition(const struct mtd_info *mtd);
int mtd_add_partition(struct mtd_info *master, char *name,
long long offset, long long length);
int mtd_del_partition(struct mtd_info *master, int partno);
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
bad block handling.
Today, the number of reserved PEB can only be set as a percentage of the
total number of PEB in each MTD partition.
For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB
(mtd0) and 100MiB (mtd1) and 2% reserved PEB:
- the UBI device on mtd0 will have 2 PEB reserved
- the UBI device on mtd1 will have 16 PEB reserved
The problem with this behaviour is that NAND flash manufacturers give a
minimum number of valid block (NVB) during the endurance life of the
device.
E.G.:
Parameter SymbolMinMaxUnit Notes
--
Valid block number NVB 10041024 Blocks 1
Note:
1. Invalid blocks are block that contain one or more bad bits beyond
ECC. The device may contain bad blocks upon shipment. Additional bad
blocks may develop over time; however, the total number of available
blocks will not drop below NVB during the endurance life of the device.
>From this number we can deduce the maximum number of bad PEB that a
device will contain during its endurance life :
A 128MiB NAND flash (1024 PEB) will not have less than 20 bad blocks
during the flash endurance life.
BUT, the manufacturer doesn't tell where those bad block will appear. He
doesn't say either if they will be equally disposed on the whole device
(and I'm pretty sure they won't).
So, according to the datasheets, we should reserve the maximum number of
bad PEB for each UBI device.
(Worst case scenario: 20 bad blocks appears on the smallest MTD
partition.)
So this patch make UBI use the whole MTD device size to calculate the
Maximum bad expected eraseblocks.
The Kconfig option is in per1024 blocks, thus it can have a default
value of 20 which is *very* common for NAND devices.
Signed-off-by: Richard Genoud
---
drivers/mtd/ubi/Kconfig | 14 ++
drivers/mtd/ubi/build.c | 17 ++---
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 145cda2..b77ffe1 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -28,15 +28,21 @@ config MTD_UBI_WL_THRESHOLD
to 128 or 256, although it does not have to be power of 2).
config MTD_UBI_BEB_LIMIT
- int "Percentage of maximum expected bad eraseblocks"
- default 2
- range 0 25
+ int "Maximum expected bad eraseblocks per 1024 eraseblocks"
+ default 20
+ range 2 256
help
If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI
reserves some amount of physical eraseblocks to handle new bad
eraseblocks.
This option specifies the maximum bad eraseblocks UBI expects on the
- ubi device (percents of total number of flash eraseblocks).
+ ubi device per 1024 eraseblocks.
+ This value is often given in an other form in the NAND datasheet
+ (min NVB i.e. minimal number of valid blocks). The maximum expected
+ bad eraseblocks per 1024 is then:
+ 1024 * (1 - MinNVB / MaxNVB)
+ Which gives 20 for most NAND devices.
+
This limit is used in order to derive amount of eraseblock UBI
reserves for handling new bad blocks.
If the device has more bad eraseblocks than this limit, UBI does not
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 62cc6ce..87b39c2 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -610,12 +611,22 @@ static int io_init(struct ubi_device *ubi)
if (mtd_can_have_bb(ubi->mtd)) {
ubi->bad_allowed = 1;
if (CONFIG_MTD_UBI_BEB_LIMIT > 0) {
- int percent = CONFIG_MTD_UBI_BEB_LIMIT;
+ int per1024 = CONFIG_MTD_UBI_BEB_LIMIT;
+ int device_peb_count;
+ uint64_t device_size;
int beb_limit;
- beb_limit = mult_frac(ubi->peb_count, percent, 100);
+ /* we are using here the whole MTD device size and not
+* the MTD partition size because the maximum number of
+* bad blocks is a percentage of the whole device and
+* the bad blocks are not fairly disposed on a flash
+* device
+*/
+ device_size = mtd_get_device_size(ubi->mtd);
+ device_peb_count = mtd_div_by_eb(device_size, ubi->mtd);
+ beb_limit = mult_frac(device_peb_count, per1024, 1024);
/* round it up */
- if (mult_frac(beb_limit, 100, percent) < ubi->peb_count)
+
[PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter
This patch provides the possibility to adjust the "maximum expected number of
bad blocks per 1024 blocks" (max_beb_per1024) for each mtd device.
The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
Now, we can adjust that via a kernel parameter:
ubi.mtd=[,[,max_beb_per1024]]
and via UBI_IOCATT ioctl which is now:
struct ubi_attach_req {
__s32 ubi_num;
__s32 mtd_num;
__s32 vid_hdr_offset;
__u8 max_beb_per1024;
__s8 padding[11];
};
Signed-off-by: Richard Genoud
---
drivers/mtd/ubi/Kconfig | 25 --
drivers/mtd/ubi/build.c | 82 +++---
drivers/mtd/ubi/cdev.c |9 -
drivers/mtd/ubi/ubi.h |6 +++-
include/mtd/ubi-user.h | 19 ++-
5 files changed, 86 insertions(+), 55 deletions(-)
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index b77ffe1..7a57cc0 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -27,31 +27,6 @@ config MTD_UBI_WL_THRESHOLD
life-cycle less than 1, the threshold should be lessened (e.g.,
to 128 or 256, although it does not have to be power of 2).
-config MTD_UBI_BEB_LIMIT
- int "Maximum expected bad eraseblocks per 1024 eraseblocks"
- default 20
- range 2 256
- help
- If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI
- reserves some amount of physical eraseblocks to handle new bad
- eraseblocks.
- This option specifies the maximum bad eraseblocks UBI expects on the
- ubi device per 1024 eraseblocks.
- This value is often given in an other form in the NAND datasheet
- (min NVB i.e. minimal number of valid blocks). The maximum expected
- bad eraseblocks per 1024 is then:
- 1024 * (1 - MinNVB / MaxNVB)
- Which gives 20 for most NAND devices.
-
- This limit is used in order to derive amount of eraseblock UBI
- reserves for handling new bad blocks.
- If the device has more bad eraseblocks than this limit, UBI does not
- reserve any physical eraseblocks for new bad eraseblocks, but
- attempts to use available eraseblocks (if any).
- If the underlying flash does not admit of bad eraseblocks (e.g. NOR
- flash), this value is ignored.
- Leave the default value if unsure.
-
config MTD_UBI_GLUEBI
tristate "MTD devices emulation driver (gluebi)"
help
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 87b39c2..76358e9 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -46,6 +46,8 @@
/* Maximum length of the 'mtd=' parameter */
#define MTD_PARAM_LEN_MAX 64
+#define MTD_PARAM_NB_MAX 3
+
#ifdef CONFIG_MTD_UBI_MODULE
#define ubi_is_module() 1
#else
@@ -57,10 +59,12 @@
* @name: MTD character device node path, MTD device name, or MTD device number
*string
* @vid_hdr_offs: VID header offset
+ * @max_beb_per1024: maximum expected number of bad blocks per 1024 erase
blocks
*/
struct mtd_dev_param {
char name[MTD_PARAM_LEN_MAX];
int vid_hdr_offs;
+ int max_beb_per1024;
};
/* Numbers of elements set in the @mtd_dev_param array */
@@ -565,9 +569,37 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
}
}
+static int get_bad_peb_limit(const struct ubi_device *ubi, int max_beb_per1024)
+{
+ int device_peb_count;
+ uint64_t device_size;
+ int beb_limit = 0;
+
+ /* this has already been checked in ioctl */
+ if (max_beb_per1024 <= 0)
+ goto out;
+
+ /* we are using here the whole MTD device size and not
+* the MTD partition size because the maximum number of
+* bad blocks is a percentage of the whole device and
+* the bad blocks are not fairly disposed on a flash
+* device
+*/
+ device_size = mtd_get_device_size(ubi->mtd);
+ device_peb_count = mtd_div_by_eb(device_size, ubi->mtd);
+ beb_limit = mult_frac(device_peb_count, max_beb_per1024, 1024);
+ /* round it up */
+ if (mult_frac(beb_limit, 1024, max_beb_per1024) < ubi->peb_count)
+ beb_limit++;
+
+out:
+ return beb_limit;
+}
+
/**
* io_init - initialize I/O sub-system for a given UBI device.
* @ubi: UBI device description object
+ * @max_beb_per1024: maximum expected number of bad PEB per 1024 PEB
*
* If @ubi->vid_hdr_offset or @ubi->leb_start is zero, default offsets are
* assumed:
@@ -580,7 +612,7 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
* This function returns zero in case of success and a negative error code in
* case of failure.
*/
-static int io_init(struct ubi_device *ubi)
+static int io_init(struct ubi_device *ubi, int max_beb_per1024)
{
if (ubi->mtd->numeraseregions != 0) {
/*
@@ -6
[PATCH] ubiattach: introduce max_beb_per1024 in UBI_IOCATT
The ioctl UBI_IOCATT has been extended with max_beb_per1024 parameter.
This parameter is used for adjusting the "maximum expected number of
bad blocks per 1024 blocks" for each mtd device.
The number of physical erase blocks (PEB) that UBI will reserve for bad
block handling is now:
whole_flash_chipset__PEB_number * max_beb_per1024 / 1024
This means that for a 4096 PEB NAND device with 3 MTD partitions:
mtd0: 512 PEB
mtd1: 1536 PEB
mtd2: 2048 PEB
the commands:
ubiattach -m 0 -d 0 -b 20 /dev/ubi_ctrl
ubiattach -m 1 -d 1 -b 20 /dev/ubi_ctrl
ubiattach -m 2 -d 2 -b 20 /dev/ubi_ctrl
will attach mtdx to UBIx and reserve:
80 PEB for bad block handling on UBI0
80 PEB for bad block handling on UBI1
80 PEB for bad block handling on UBI2
=> for the whole device, 240 PEB will be reserved for bad block
handling.
This may seems a waste of space, but as far as the bad blocks can appear
every where on a flash device, in the worst case scenario they can
all appear in one MTD partition.
So the maximum number of expected erase blocks given by the NAND
manufacturer should be reserve on each MTD partition.
Signed-off-by: Richard Genoud
---
include/mtd/ubi-user.h | 20 -
tests/fs-tests/integrity/integck.c |1 +
ubi-utils/include/libubi.h |2 +
ubi-utils/libubi.c |2 +
ubi-utils/ubiattach.c | 41 +---
5 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index 296efae..5f77906 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -235,6 +235,7 @@ enum {
* @ubi_num: UBI device number to create
* @mtd_num: MTD device number to attach
* @vid_hdr_offset: VID header offset (use defaults if %0)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
* @padding: reserved for future, not used, has to be zeroed
*
* This data structure is used to specify MTD device UBI has to attach and the
@@ -258,12 +259,29 @@ enum {
* be 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes
* aligned, which is OK, as UBI is clever enough to realize this is 4th
* sub-page of the first page and add needed padding.
+ *
+ * The @max_beb_per1024 is the maximum bad eraseblocks UBI expects on the ubi
+ * device per 1024 eraseblocks.
+ * This value is often given in an other form in the NAND datasheet (min NVB
+ * i.e. minimal number of valid blocks). The maximum expected bad eraseblocks
+ * per 1024 is then:
+ * 1024 * (1 - MinNVB / MaxNVB)
+ * Which gives 20 for most NAND devices.
+ * This limit is used in order to derive amount of eraseblock UBI reserves for
+ * handling new bad blocks.
+ * If the device has more bad eraseblocks than this limit, UBI does not reserve
+ * any physical eraseblocks for new bad eraseblocks, but attempts to use
+ * available eraseblocks (if any).
+ * The accepted range is 0-255. If 0 is given, the default kernel value
+ * MTD_UBI_DEFAULT_BEB_LIMIT will be used for compatibility with previous
+ * versions.
*/
struct ubi_attach_req {
int32_t ubi_num;
int32_t mtd_num;
int32_t vid_hdr_offset;
- int8_t padding[12];
+ int8_t max_beb_per1024;
+ int8_t padding[11];
};
/**
diff --git a/tests/fs-tests/integrity/integck.c
b/tests/fs-tests/integrity/integck.c
index 30322cd..f12dfac 100644
--- a/tests/fs-tests/integrity/integck.c
+++ b/tests/fs-tests/integrity/integck.c
@@ -3152,6 +3152,7 @@ static int reattach(void)
req.mtd_num = args.mtdn;
req.vid_hdr_offset = 0;
req.mtd_dev_node = NULL;
+ req.max_beb_per1024 = 0;
err = ubi_attach(libubi, "/dev/ubi_ctrl", );
if (err)
diff --git a/ubi-utils/include/libubi.h b/ubi-utils/include/libubi.h
index dc03d02..1eadff8 100644
--- a/ubi-utils/include/libubi.h
+++ b/ubi-utils/include/libubi.h
@@ -50,6 +50,7 @@ typedef void * libubi_t;
* @mtd_dev_node: path to MTD device node to attach
* @vid_hdr_offset: VID header offset (%0 means default offset and this is what
* most of the users want)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
*/
struct ubi_attach_request
{
@@ -57,6 +58,7 @@ struct ubi_attach_request
int mtd_num;
const char *mtd_dev_node;
int vid_hdr_offset;
+ unsigned char max_beb_per1024;
};
/**
diff --git a/ubi-utils/libubi.c b/ubi-utils/libubi.c
index c898e36..d3c333d 100644
--- a/ubi-utils/libubi.c
+++ b/ubi-utils/libubi.c
@@ -719,6 +719,7 @@ int ubi_attach_mtd(libubi_t desc, const char *node,
r.ubi_num = req->dev_num;
r.mtd_num = req->mtd_num;
r.vid_hdr_offset = req->vid_hdr_offset;
+ r.max_beb_per1024 = req->max_beb_per1024;
ret = do_attach(node, );
if (ret == 0)
@@ -780,6 +781,7 @@ int ubi_attach(libubi_t desc, const char *node, struct
ubi_attach_request *req)
memse
[PATCH 2/4] MTD parts: introduce mtd_get_device_size()
mtd_get_device_size() returns the size of the whole MTD device, that is
the mtd_info master size.
This is used by UBI to calculate the maximum number of bad blocks (MBB)
on a MTD device.
Signed-off-by: Richard Genoud
---
drivers/mtd/mtdpart.c | 14 ++
include/linux/mtd/partitions.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 8500584..d12f583 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -760,3 +760,17 @@ int mtd_is_partition(const struct mtd_info *mtd)
return ispart;
}
EXPORT_SYMBOL_GPL(mtd_is_partition);
+
+/* returns the size of an MTD device */
+uint64_t mtd_get_device_size(const struct mtd_info *mtd)
+{
+ struct mtd_part *part;
+
+ if (!mtd_is_partition(mtd))
+ return mtd->size;
+
+ part = PART(mtd);
+
+ return part->master->size;
+}
+EXPORT_SYMBOL_GPL(mtd_get_device_size);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 02a5115..1f8d24b 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -83,5 +83,6 @@ int mtd_is_partition(const struct mtd_info *mtd);
int mtd_add_partition(struct mtd_info *master, char *name,
long long offset, long long length);
int mtd_del_partition(struct mtd_info *master, int partno);
+uint64_t mtd_get_device_size(const struct mtd_info *mtd);
#endif
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] UBI: Use the whole NAND device to calculate max bad block number
Hi, This patch serie applies on top of Shmulik Ladkani's patch serie: "[PATCH 0/5] ubi: Fix bad PEBs reserve caclulation" (and on mtd-artem git tree) The goal here is to make UBI reserve a number of PEB for bad block dependant of the whole NAND chipset size, and not of the MTD partition size. As explained in patch 3/4, the NAND manufacturers only tell how many bad blocks there will be in the worst case on a NAND device, but not that these blocks will be equally disposed on the flash. I.E. if a NAND flash admits at max 40 bad blocks, and is cutted in two equal MTD partitions, it doesn't mean that there will be at max only 20 bad blocks per partition. The 40 BEBs could be all on the first partition. So, for each MTD partition, UBI should reserved the maximum expected number of bad erase blocks. Patches 1/2/3 are making that happend with a kernel option MTD_UBI_BEB_LIMIT Then, patch 4 replace this option with user-space parameters (kernel parameter and a UBI_IOCATT ioctl) The patch on mtd-utils follows the serie. Richard Genoud (4): mtd_is_partition: struct mtd_info should be const MTD parts: introduce mtd_get_device_size() UBI: use the whole MTD device size to get bad_peb_limit UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter drivers/mtd/mtdpart.c | 16 - drivers/mtd/ubi/Kconfig| 19 -- drivers/mtd/ubi/build.c| 73 ++- drivers/mtd/ubi/cdev.c |9 - drivers/mtd/ubi/ubi.h |6 +++- include/linux/mtd/partitions.h |3 +- include/mtd/ubi-user.h | 19 ++- 7 files changed, 104 insertions(+), 41 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] UBI: Use the whole NAND device to calculate max bad block number
Hi, This patch serie applies on top of Shmulik Ladkani's patch serie: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation (and on mtd-artem git tree) The goal here is to make UBI reserve a number of PEB for bad block dependant of the whole NAND chipset size, and not of the MTD partition size. As explained in patch 3/4, the NAND manufacturers only tell how many bad blocks there will be in the worst case on a NAND device, but not that these blocks will be equally disposed on the flash. I.E. if a NAND flash admits at max 40 bad blocks, and is cutted in two equal MTD partitions, it doesn't mean that there will be at max only 20 bad blocks per partition. The 40 BEBs could be all on the first partition. So, for each MTD partition, UBI should reserved the maximum expected number of bad erase blocks. Patches 1/2/3 are making that happend with a kernel option MTD_UBI_BEB_LIMIT Then, patch 4 replace this option with user-space parameters (kernel parameter and a UBI_IOCATT ioctl) The patch on mtd-utils follows the serie. Richard Genoud (4): mtd_is_partition: struct mtd_info should be const MTD parts: introduce mtd_get_device_size() UBI: use the whole MTD device size to get bad_peb_limit UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter drivers/mtd/mtdpart.c | 16 - drivers/mtd/ubi/Kconfig| 19 -- drivers/mtd/ubi/build.c| 73 ++- drivers/mtd/ubi/cdev.c |9 - drivers/mtd/ubi/ubi.h |6 +++- include/linux/mtd/partitions.h |3 +- include/mtd/ubi-user.h | 19 ++- 7 files changed, 104 insertions(+), 41 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] MTD parts: introduce mtd_get_device_size()
mtd_get_device_size() returns the size of the whole MTD device, that is
the mtd_info master size.
This is used by UBI to calculate the maximum number of bad blocks (MBB)
on a MTD device.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/mtd/mtdpart.c | 14 ++
include/linux/mtd/partitions.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 8500584..d12f583 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -760,3 +760,17 @@ int mtd_is_partition(const struct mtd_info *mtd)
return ispart;
}
EXPORT_SYMBOL_GPL(mtd_is_partition);
+
+/* returns the size of an MTD device */
+uint64_t mtd_get_device_size(const struct mtd_info *mtd)
+{
+ struct mtd_part *part;
+
+ if (!mtd_is_partition(mtd))
+ return mtd-size;
+
+ part = PART(mtd);
+
+ return part-master-size;
+}
+EXPORT_SYMBOL_GPL(mtd_get_device_size);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 02a5115..1f8d24b 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -83,5 +83,6 @@ int mtd_is_partition(const struct mtd_info *mtd);
int mtd_add_partition(struct mtd_info *master, char *name,
long long offset, long long length);
int mtd_del_partition(struct mtd_info *master, int partno);
+uint64_t mtd_get_device_size(const struct mtd_info *mtd);
#endif
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ubiattach: introduce max_beb_per1024 in UBI_IOCATT
The ioctl UBI_IOCATT has been extended with max_beb_per1024 parameter.
This parameter is used for adjusting the maximum expected number of
bad blocks per 1024 blocks for each mtd device.
The number of physical erase blocks (PEB) that UBI will reserve for bad
block handling is now:
whole_flash_chipset__PEB_number * max_beb_per1024 / 1024
This means that for a 4096 PEB NAND device with 3 MTD partitions:
mtd0: 512 PEB
mtd1: 1536 PEB
mtd2: 2048 PEB
the commands:
ubiattach -m 0 -d 0 -b 20 /dev/ubi_ctrl
ubiattach -m 1 -d 1 -b 20 /dev/ubi_ctrl
ubiattach -m 2 -d 2 -b 20 /dev/ubi_ctrl
will attach mtdx to UBIx and reserve:
80 PEB for bad block handling on UBI0
80 PEB for bad block handling on UBI1
80 PEB for bad block handling on UBI2
= for the whole device, 240 PEB will be reserved for bad block
handling.
This may seems a waste of space, but as far as the bad blocks can appear
every where on a flash device, in the worst case scenario they can
all appear in one MTD partition.
So the maximum number of expected erase blocks given by the NAND
manufacturer should be reserve on each MTD partition.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
include/mtd/ubi-user.h | 20 -
tests/fs-tests/integrity/integck.c |1 +
ubi-utils/include/libubi.h |2 +
ubi-utils/libubi.c |2 +
ubi-utils/ubiattach.c | 41 +---
5 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index 296efae..5f77906 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -235,6 +235,7 @@ enum {
* @ubi_num: UBI device number to create
* @mtd_num: MTD device number to attach
* @vid_hdr_offset: VID header offset (use defaults if %0)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
* @padding: reserved for future, not used, has to be zeroed
*
* This data structure is used to specify MTD device UBI has to attach and the
@@ -258,12 +259,29 @@ enum {
* be 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes
* aligned, which is OK, as UBI is clever enough to realize this is 4th
* sub-page of the first page and add needed padding.
+ *
+ * The @max_beb_per1024 is the maximum bad eraseblocks UBI expects on the ubi
+ * device per 1024 eraseblocks.
+ * This value is often given in an other form in the NAND datasheet (min NVB
+ * i.e. minimal number of valid blocks). The maximum expected bad eraseblocks
+ * per 1024 is then:
+ * 1024 * (1 - MinNVB / MaxNVB)
+ * Which gives 20 for most NAND devices.
+ * This limit is used in order to derive amount of eraseblock UBI reserves for
+ * handling new bad blocks.
+ * If the device has more bad eraseblocks than this limit, UBI does not reserve
+ * any physical eraseblocks for new bad eraseblocks, but attempts to use
+ * available eraseblocks (if any).
+ * The accepted range is 0-255. If 0 is given, the default kernel value
+ * MTD_UBI_DEFAULT_BEB_LIMIT will be used for compatibility with previous
+ * versions.
*/
struct ubi_attach_req {
int32_t ubi_num;
int32_t mtd_num;
int32_t vid_hdr_offset;
- int8_t padding[12];
+ int8_t max_beb_per1024;
+ int8_t padding[11];
};
/**
diff --git a/tests/fs-tests/integrity/integck.c
b/tests/fs-tests/integrity/integck.c
index 30322cd..f12dfac 100644
--- a/tests/fs-tests/integrity/integck.c
+++ b/tests/fs-tests/integrity/integck.c
@@ -3152,6 +3152,7 @@ static int reattach(void)
req.mtd_num = args.mtdn;
req.vid_hdr_offset = 0;
req.mtd_dev_node = NULL;
+ req.max_beb_per1024 = 0;
err = ubi_attach(libubi, /dev/ubi_ctrl, req);
if (err)
diff --git a/ubi-utils/include/libubi.h b/ubi-utils/include/libubi.h
index dc03d02..1eadff8 100644
--- a/ubi-utils/include/libubi.h
+++ b/ubi-utils/include/libubi.h
@@ -50,6 +50,7 @@ typedef void * libubi_t;
* @mtd_dev_node: path to MTD device node to attach
* @vid_hdr_offset: VID header offset (%0 means default offset and this is what
* most of the users want)
+ * @max_beb_per1024: Maximum expected bad eraseblocks per 1024 eraseblocks
*/
struct ubi_attach_request
{
@@ -57,6 +58,7 @@ struct ubi_attach_request
int mtd_num;
const char *mtd_dev_node;
int vid_hdr_offset;
+ unsigned char max_beb_per1024;
};
/**
diff --git a/ubi-utils/libubi.c b/ubi-utils/libubi.c
index c898e36..d3c333d 100644
--- a/ubi-utils/libubi.c
+++ b/ubi-utils/libubi.c
@@ -719,6 +719,7 @@ int ubi_attach_mtd(libubi_t desc, const char *node,
r.ubi_num = req-dev_num;
r.mtd_num = req-mtd_num;
r.vid_hdr_offset = req-vid_hdr_offset;
+ r.max_beb_per1024 = req-max_beb_per1024;
ret = do_attach(node, r);
if (ret == 0)
@@ -780,6 +781,7 @@ int ubi_attach(libubi_t desc, const char *node, struct
ubi_attach_request *req)
memset(r, 0, sizeof(struct
[PATCH 4/4] UBI: replace MTD_UBI_BEB_LIMIT with user-space parameter
This patch provides the possibility to adjust the maximum expected number of
bad blocks per 1024 blocks (max_beb_per1024) for each mtd device.
The majority of NAND devices have their max_beb_per1024 equal to 20, but
sometimes it's more.
Now, we can adjust that via a kernel parameter:
ubi.mtd=name|num|path[,vid_hdr_offs[,max_beb_per1024]]
and via UBI_IOCATT ioctl which is now:
struct ubi_attach_req {
__s32 ubi_num;
__s32 mtd_num;
__s32 vid_hdr_offset;
__u8 max_beb_per1024;
__s8 padding[11];
};
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/mtd/ubi/Kconfig | 25 --
drivers/mtd/ubi/build.c | 82 +++---
drivers/mtd/ubi/cdev.c |9 -
drivers/mtd/ubi/ubi.h |6 +++-
include/mtd/ubi-user.h | 19 ++-
5 files changed, 86 insertions(+), 55 deletions(-)
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index b77ffe1..7a57cc0 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -27,31 +27,6 @@ config MTD_UBI_WL_THRESHOLD
life-cycle less than 1, the threshold should be lessened (e.g.,
to 128 or 256, although it does not have to be power of 2).
-config MTD_UBI_BEB_LIMIT
- int Maximum expected bad eraseblocks per 1024 eraseblocks
- default 20
- range 2 256
- help
- If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI
- reserves some amount of physical eraseblocks to handle new bad
- eraseblocks.
- This option specifies the maximum bad eraseblocks UBI expects on the
- ubi device per 1024 eraseblocks.
- This value is often given in an other form in the NAND datasheet
- (min NVB i.e. minimal number of valid blocks). The maximum expected
- bad eraseblocks per 1024 is then:
- 1024 * (1 - MinNVB / MaxNVB)
- Which gives 20 for most NAND devices.
-
- This limit is used in order to derive amount of eraseblock UBI
- reserves for handling new bad blocks.
- If the device has more bad eraseblocks than this limit, UBI does not
- reserve any physical eraseblocks for new bad eraseblocks, but
- attempts to use available eraseblocks (if any).
- If the underlying flash does not admit of bad eraseblocks (e.g. NOR
- flash), this value is ignored.
- Leave the default value if unsure.
-
config MTD_UBI_GLUEBI
tristate MTD devices emulation driver (gluebi)
help
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 87b39c2..76358e9 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -46,6 +46,8 @@
/* Maximum length of the 'mtd=' parameter */
#define MTD_PARAM_LEN_MAX 64
+#define MTD_PARAM_NB_MAX 3
+
#ifdef CONFIG_MTD_UBI_MODULE
#define ubi_is_module() 1
#else
@@ -57,10 +59,12 @@
* @name: MTD character device node path, MTD device name, or MTD device number
*string
* @vid_hdr_offs: VID header offset
+ * @max_beb_per1024: maximum expected number of bad blocks per 1024 erase
blocks
*/
struct mtd_dev_param {
char name[MTD_PARAM_LEN_MAX];
int vid_hdr_offs;
+ int max_beb_per1024;
};
/* Numbers of elements set in the @mtd_dev_param array */
@@ -565,9 +569,37 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
}
}
+static int get_bad_peb_limit(const struct ubi_device *ubi, int max_beb_per1024)
+{
+ int device_peb_count;
+ uint64_t device_size;
+ int beb_limit = 0;
+
+ /* this has already been checked in ioctl */
+ if (max_beb_per1024 = 0)
+ goto out;
+
+ /* we are using here the whole MTD device size and not
+* the MTD partition size because the maximum number of
+* bad blocks is a percentage of the whole device and
+* the bad blocks are not fairly disposed on a flash
+* device
+*/
+ device_size = mtd_get_device_size(ubi-mtd);
+ device_peb_count = mtd_div_by_eb(device_size, ubi-mtd);
+ beb_limit = mult_frac(device_peb_count, max_beb_per1024, 1024);
+ /* round it up */
+ if (mult_frac(beb_limit, 1024, max_beb_per1024) ubi-peb_count)
+ beb_limit++;
+
+out:
+ return beb_limit;
+}
+
/**
* io_init - initialize I/O sub-system for a given UBI device.
* @ubi: UBI device description object
+ * @max_beb_per1024: maximum expected number of bad PEB per 1024 PEB
*
* If @ubi-vid_hdr_offset or @ubi-leb_start is zero, default offsets are
* assumed:
@@ -580,7 +612,7 @@ void ubi_free_internal_volumes(struct ubi_device *ubi)
* This function returns zero in case of success and a negative error code in
* case of failure.
*/
-static int io_init(struct ubi_device *ubi)
+static int io_init(struct ubi_device *ubi, int max_beb_per1024)
{
if (ubi-mtd-numeraseregions != 0) {
/*
@@ -610,26 +642,7 @@ static int
[PATCH 3/4] UBI: use the whole MTD device size to get bad_peb_limit
On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
bad block handling.
Today, the number of reserved PEB can only be set as a percentage of the
total number of PEB in each MTD partition.
For example, for a NAND flash with 128KiB PEB, 2 MTD partition of 20MiB
(mtd0) and 100MiB (mtd1) and 2% reserved PEB:
- the UBI device on mtd0 will have 2 PEB reserved
- the UBI device on mtd1 will have 16 PEB reserved
The problem with this behaviour is that NAND flash manufacturers give a
minimum number of valid block (NVB) during the endurance life of the
device.
E.G.:
Parameter SymbolMinMaxUnit Notes
--
Valid block number NVB 10041024 Blocks 1
Note:
1. Invalid blocks are block that contain one or more bad bits beyond
ECC. The device may contain bad blocks upon shipment. Additional bad
blocks may develop over time; however, the total number of available
blocks will not drop below NVB during the endurance life of the device.
From this number we can deduce the maximum number of bad PEB that a
device will contain during its endurance life :
A 128MiB NAND flash (1024 PEB) will not have less than 20 bad blocks
during the flash endurance life.
BUT, the manufacturer doesn't tell where those bad block will appear. He
doesn't say either if they will be equally disposed on the whole device
(and I'm pretty sure they won't).
So, according to the datasheets, we should reserve the maximum number of
bad PEB for each UBI device.
(Worst case scenario: 20 bad blocks appears on the smallest MTD
partition.)
So this patch make UBI use the whole MTD device size to calculate the
Maximum bad expected eraseblocks.
The Kconfig option is in per1024 blocks, thus it can have a default
value of 20 which is *very* common for NAND devices.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/mtd/ubi/Kconfig | 14 ++
drivers/mtd/ubi/build.c | 17 ++---
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 145cda2..b77ffe1 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -28,15 +28,21 @@ config MTD_UBI_WL_THRESHOLD
to 128 or 256, although it does not have to be power of 2).
config MTD_UBI_BEB_LIMIT
- int Percentage of maximum expected bad eraseblocks
- default 2
- range 0 25
+ int Maximum expected bad eraseblocks per 1024 eraseblocks
+ default 20
+ range 2 256
help
If the MTD device admits of bad eraseblocks (e.g. NAND flash), UBI
reserves some amount of physical eraseblocks to handle new bad
eraseblocks.
This option specifies the maximum bad eraseblocks UBI expects on the
- ubi device (percents of total number of flash eraseblocks).
+ ubi device per 1024 eraseblocks.
+ This value is often given in an other form in the NAND datasheet
+ (min NVB i.e. minimal number of valid blocks). The maximum expected
+ bad eraseblocks per 1024 is then:
+ 1024 * (1 - MinNVB / MaxNVB)
+ Which gives 20 for most NAND devices.
+
This limit is used in order to derive amount of eraseblock UBI
reserves for handling new bad blocks.
If the device has more bad eraseblocks than this limit, UBI does not
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 62cc6ce..87b39c2 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -36,6 +36,7 @@
#include linux/namei.h
#include linux/stat.h
#include linux/miscdevice.h
+#include linux/mtd/partitions.h
#include linux/log2.h
#include linux/kthread.h
#include linux/kernel.h
@@ -610,12 +611,22 @@ static int io_init(struct ubi_device *ubi)
if (mtd_can_have_bb(ubi-mtd)) {
ubi-bad_allowed = 1;
if (CONFIG_MTD_UBI_BEB_LIMIT 0) {
- int percent = CONFIG_MTD_UBI_BEB_LIMIT;
+ int per1024 = CONFIG_MTD_UBI_BEB_LIMIT;
+ int device_peb_count;
+ uint64_t device_size;
int beb_limit;
- beb_limit = mult_frac(ubi-peb_count, percent, 100);
+ /* we are using here the whole MTD device size and not
+* the MTD partition size because the maximum number of
+* bad blocks is a percentage of the whole device and
+* the bad blocks are not fairly disposed on a flash
+* device
+*/
+ device_size = mtd_get_device_size(ubi-mtd);
+ device_peb_count = mtd_div_by_eb(device_size, ubi-mtd);
+ beb_limit = mult_frac(device_peb_count, per1024, 1024);
/* round it up
[PATCH 1/4] mtd_is_partition: struct mtd_info should be const
struct mtd_info is not modified by mtd_is_partition so it should be a
const.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/mtd/mtdpart.c |2 +-
include/linux/mtd/partitions.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index d518e4d..8500584 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -744,7 +744,7 @@ int parse_mtd_partitions(struct mtd_info *master, const
char **types,
return ret;
}
-int mtd_is_partition(struct mtd_info *mtd)
+int mtd_is_partition(const struct mtd_info *mtd)
{
struct mtd_part *part;
int ispart = 0;
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 2475228..02a5115 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -79,7 +79,7 @@ struct mtd_part_parser {
extern int register_mtd_parser(struct mtd_part_parser *parser);
extern int deregister_mtd_parser(struct mtd_part_parser *parser);
-int mtd_is_partition(struct mtd_info *mtd);
+int mtd_is_partition(const struct mtd_info *mtd);
int mtd_add_partition(struct mtd_info *master, char *name,
long long offset, long long length);
int mtd_del_partition(struct mtd_info *master, int partno);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling
2012/7/4 Shmulik Ladkani :
> diff --git a/drivers/mtd/ubi/misc.c b/drivers/mtd/ubi/misc.c
> index f6a7d7a..e9dcb83 100644
> --- a/drivers/mtd/ubi/misc.c
> +++ b/drivers/mtd/ubi/misc.c
> @@ -98,10 +98,18 @@ int ubi_check_volume(struct ubi_device *ubi, int vol_id)
> */
> void ubi_calculate_reserved(struct ubi_device *ubi)
> {
> - ubi->beb_rsvd_level = ubi->good_peb_count/100;
> - ubi->beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;
> - if (ubi->beb_rsvd_level < MIN_RESEVED_PEBS)
> - ubi->beb_rsvd_level = MIN_RESEVED_PEBS;
> + /*
> +* Calculate the actual number of PEBs currently needed to be reserved
> +* for future bad eraseblock handling.
> +*/
> + ubi->beb_rsvd_level = ubi->bad_peb_limit - ubi->bad_peb_count;
> + if (ubi->beb_rsvd_level < 0) {
> + ubi->beb_rsvd_level = 0;
> + ubi_warn("number of bad PEBs (%d) is above the expected limit
> "
> +"(%d), not reserving any PEBs for bad PEB handling, "
> +"will use available PEBs (if any)",
> +ubi->bad_peb_count, ubi->bad_peb_limit);
> + }
> }
is it ok for beb_rsvd_level to be in the range [0..x[ instead of [2..x[ ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani : > Many thanks for testing. > > Could you please verify the crash only occurs with the patch? > > Can you provide the vmlinux matching this oops, so I may analyze the > exact null dereferencing point? > It seems to be somewhere in ubi_wl_init, however the patch seems not to > affect these parts of ubi... Hi ! I can't reproduce it... Maybe the problem was between the chair and the keyboard. Anyway, if I ran into it again, I'll let you know. Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani shmulik.ladk...@gmail.com: Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Hi ! I can't reproduce it... Maybe the problem was between the chair and the keyboard. Anyway, if I ran into it again, I'll let you know. Richard. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling
2012/7/4 Shmulik Ladkani shmulik.ladk...@gmail.com:
diff --git a/drivers/mtd/ubi/misc.c b/drivers/mtd/ubi/misc.c
index f6a7d7a..e9dcb83 100644
--- a/drivers/mtd/ubi/misc.c
+++ b/drivers/mtd/ubi/misc.c
@@ -98,10 +98,18 @@ int ubi_check_volume(struct ubi_device *ubi, int vol_id)
*/
void ubi_calculate_reserved(struct ubi_device *ubi)
{
- ubi-beb_rsvd_level = ubi-good_peb_count/100;
- ubi-beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;
- if (ubi-beb_rsvd_level MIN_RESEVED_PEBS)
- ubi-beb_rsvd_level = MIN_RESEVED_PEBS;
+ /*
+* Calculate the actual number of PEBs currently needed to be reserved
+* for future bad eraseblock handling.
+*/
+ ubi-beb_rsvd_level = ubi-bad_peb_limit - ubi-bad_peb_count;
+ if (ubi-beb_rsvd_level 0) {
+ ubi-beb_rsvd_level = 0;
+ ubi_warn(number of bad PEBs (%d) is above the expected limit
+(%d), not reserving any PEBs for bad PEB handling,
+will use available PEBs (if any),
+ubi-bad_peb_count, ubi-bad_peb_limit);
+ }
}
is it ok for beb_rsvd_level to be in the range [0..x[ instead of [2..x[ ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani : > Many thanks for testing. > > Could you please verify the crash only occurs with the patch? > > Can you provide the vmlinux matching this oops, so I may analyze the > exact null dereferencing point? > It seems to be somewhere in ubi_wl_init, however the patch seems not to > affect these parts of ubi... > > Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? I'll do that on monday. Nice week-end ! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
2012/7/7 Shmulik Ladkani shmulik.ladk...@gmail.com: Many thanks for testing. Could you please verify the crash only occurs with the patch? Can you provide the vmlinux matching this oops, so I may analyze the exact null dereferencing point? It seems to be somewhere in ubi_wl_init, however the patch seems not to affect these parts of ubi... Also, what's your CONFIG_MTD_UBI_BEB_LIMIT? I'll do that on monday. Nice week-end ! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I didn't test without your patch, but anyway something is wrong there. # flash_erase /dev/mtd1 0 1980 Erasing 128 Kibyte @ f76 -- 100 % complete # ubiattach /dev/ubi_ctrl -m1 [ 35.671875] UBI: attaching mtd1 to ubi0 [ 35.671875] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_ainf_peb) 48 [ 35.679687] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_wl_entry) 20 [ 35.687500] UBI DBG (pid 419): io_init: min_io_size 2048 [ 35.695312] UBI DBG (pid 419): io_init: max_write_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: hdrs_min_io_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: ec_hdr_alsize2048 [ 35.710937] UBI DBG (pid 419): io_init: vid_hdr_alsize 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_offset 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_aloffset 2048 [ 35.726562] UBI DBG (pid 419): io_init: vid_hdr_shift0 [ 35.734375] UBI DBG (pid 419): io_init: leb_start4096 [ 35.742187] UBI DBG (pid 419): io_init: max_erroneous198 [ 35.742187] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 35.75] UBI: logical eraseblock size:126976 bytes [ 35.757812] UBI: smallest flash I/O unit:2048 [ 35.757812] UBI: VID header offset: 2048 (aligned 2048) [ 35.765625] UBI: data offset:4096 [ 36.210937] UBI DBG (pid 419): scan_all: scanning is finished [ 36.218750] UBI: empty MTD device detected [ 36.226562] UBI: max. sequence number: 0 [ 36.226562] UBI: create volume table (copy #1) [ 36.242187] UBI: create volume table (copy #2) [ 36.257812] Unable to handle kernel NULL pointer dereference at virtual address [ 36.265625] pgd = c752 [ 36.265625] [] *pgd=27bb7831, *pte=, *ppte= [ 36.273437] Internal error: Oops: 17 [#1] ARM [ 36.273437] CPU: 0Not tainted (3.5.0-rc5+ #14) [ 36.273437] PC is at ubi_wl_init+0x138/0x36c [ 36.273437] LR is at schedule_erase+0x50/0x64 [ 36.273437] pc : []lr : []psr: 6013 [ 36.273437] sp : c7501ee8 ip : 8000 fp : [ 36.273437] r10: c753fef8 r9 : c0361364 r8 : ffe0 [ 36.273437] r7 : c7537020 r6 : c7537034 r5 : c7538280 r4 : c7bd3540 [ 36.273437] r3 : r2 : c7bd3938 r1 : c75382c0 r0 : [ 36.273437] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.273437] Control: 0005317f Table: 2752 DAC: 0015 [ 36.273437] Process ubiattach (pid: 419, stack limit = 0xc7500270) [ 36.273437] Stack: (0xc7501ee8 to 0xc7502000) [ 36.273437] 1ee0: c7537020 c7bd3540 c7537020 c7bd3540 [ 36.273437] 1f00: c757caa0 c0009388 c750 c019800c c7bd3540 [ 36.273437] 1f20: c018d79c c757caa0 becdaaf8 c757caa0 40186f40 0003 [ 36.273437] 1f40: c0009388 c018dccc 0001 [ 36.273437] 1f60: becdaaf8 0003 40186f40 c0076890 c7ba4dc0 0003 40186f40 c7ba4dc0 [ 36.273437] 1f80: becdaaf8 c0076900 0003 becdaaf8 becdaaf8 40186f40 0003 [ 36.273437] 1fa0: 0036 c00091e0 becdaaf8 40186f40 0003 40186f40 becdaaf8 [ 36.273437] 1fc0: becdaaf8 40186f40 0003 0036 0002 becdadb4 0001 [ 36.273437] 1fe0: b6f39ec4 becdaab0 98c8 b6f39f08 6010 0003 [ 36.273437] [] (ubi_wl_init+0x138/0x36c) from [] (ubi_attach+0x74/0xbc) [ 36.273437] [] (ubi_attach+0x74/0xbc) from [] (ubi_attach_mtd_dev+0x1dc/0x4bc) [ 36.273437] [] (ubi_attach_mtd_dev+0x1dc/0x4bc) from [] (ctrl_cdev_ioctl+0xd4/0x164) [ 36.273437] [] (ctrl_cdev_ioctl+0xd4/0x164) from [] (do_vfs_ioctl+0x270/0x2ac) [ 36.273437] [] (do_vfs_ioctl+0x270/0x2ac) from [] (sys_ioctl+0x34/0x54) [ 36.273437] [] (sys_ioctl+0x34/0x54) from [] (ret_fast_syscall+0x0/0x2c) [ 36.273437] Code: e1a01005 e593 ebfb44ff ea74 (e5983020) [ 36.281250] ---[ end trace f540180ccfcbf7f6 ]--- Segmentation fault 2012/7/4 Shmulik Ladkani : > On Wed, 04 Jul 2012 10:35:42 +0200 Richard Weinberger wrote: >> Has this patch set an impact on UBI fastmap? > > Not sure yet. Maybe. Need to medidate on this :-) > >> ...wondering why I'm CC'd. :-) > > Heads-up. > As this is a bit delicate, you may review if the parts modified relate > to your fastmap work. > > Regards, > Shmulik -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation
I've got an oops... this is my dev-kernel in 3.5-rc5 + some work to be able to boot on my board NB: If I use ubi_format it's ok. the mtd1 device has 1984 PEB the 4 last are UBI reserved + BBT I didn't test without your patch, but anyway something is wrong there. # flash_erase /dev/mtd1 0 1980 Erasing 128 Kibyte @ f76 -- 100 % complete # ubiattach /dev/ubi_ctrl -m1 [ 35.671875] UBI: attaching mtd1 to ubi0 [ 35.671875] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_ainf_peb) 48 [ 35.679687] UBI DBG (pid 419): ubi_attach_mtd_dev: sizeof(struct ubi_wl_entry) 20 [ 35.687500] UBI DBG (pid 419): io_init: min_io_size 2048 [ 35.695312] UBI DBG (pid 419): io_init: max_write_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: hdrs_min_io_size 2048 [ 35.703125] UBI DBG (pid 419): io_init: ec_hdr_alsize2048 [ 35.710937] UBI DBG (pid 419): io_init: vid_hdr_alsize 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_offset 2048 [ 35.718750] UBI DBG (pid 419): io_init: vid_hdr_aloffset 2048 [ 35.726562] UBI DBG (pid 419): io_init: vid_hdr_shift0 [ 35.734375] UBI DBG (pid 419): io_init: leb_start4096 [ 35.742187] UBI DBG (pid 419): io_init: max_erroneous198 [ 35.742187] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 35.75] UBI: logical eraseblock size:126976 bytes [ 35.757812] UBI: smallest flash I/O unit:2048 [ 35.757812] UBI: VID header offset: 2048 (aligned 2048) [ 35.765625] UBI: data offset:4096 [ 36.210937] UBI DBG (pid 419): scan_all: scanning is finished [ 36.218750] UBI: empty MTD device detected [ 36.226562] UBI: max. sequence number: 0 [ 36.226562] UBI: create volume table (copy #1) [ 36.242187] UBI: create volume table (copy #2) [ 36.257812] Unable to handle kernel NULL pointer dereference at virtual address [ 36.265625] pgd = c752 [ 36.265625] [] *pgd=27bb7831, *pte=, *ppte= [ 36.273437] Internal error: Oops: 17 [#1] ARM [ 36.273437] CPU: 0Not tainted (3.5.0-rc5+ #14) [ 36.273437] PC is at ubi_wl_init+0x138/0x36c [ 36.273437] LR is at schedule_erase+0x50/0x64 [ 36.273437] pc : [c0195a7c]lr : [c0194388]psr: 6013 [ 36.273437] sp : c7501ee8 ip : 8000 fp : [ 36.273437] r10: c753fef8 r9 : c0361364 r8 : ffe0 [ 36.273437] r7 : c7537020 r6 : c7537034 r5 : c7538280 r4 : c7bd3540 [ 36.273437] r3 : r2 : c7bd3938 r1 : c75382c0 r0 : [ 36.273437] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.273437] Control: 0005317f Table: 2752 DAC: 0015 [ 36.273437] Process ubiattach (pid: 419, stack limit = 0xc7500270) [ 36.273437] Stack: (0xc7501ee8 to 0xc7502000) [ 36.273437] 1ee0: c7537020 c7bd3540 c7537020 c7bd3540 [ 36.273437] 1f00: c757caa0 c0009388 c750 c019800c c7bd3540 [ 36.273437] 1f20: c018d79c c757caa0 becdaaf8 c757caa0 40186f40 0003 [ 36.273437] 1f40: c0009388 c018dccc 0001 [ 36.273437] 1f60: becdaaf8 0003 40186f40 c0076890 c7ba4dc0 0003 40186f40 c7ba4dc0 [ 36.273437] 1f80: becdaaf8 c0076900 0003 becdaaf8 becdaaf8 40186f40 0003 [ 36.273437] 1fa0: 0036 c00091e0 becdaaf8 40186f40 0003 40186f40 becdaaf8 [ 36.273437] 1fc0: becdaaf8 40186f40 0003 0036 0002 becdadb4 0001 [ 36.273437] 1fe0: b6f39ec4 becdaab0 98c8 b6f39f08 6010 0003 [ 36.273437] [c0195a7c] (ubi_wl_init+0x138/0x36c) from [c019800c] (ubi_attach+0x74/0xbc) [ 36.273437] [c019800c] (ubi_attach+0x74/0xbc) from [c018d79c] (ubi_attach_mtd_dev+0x1dc/0x4bc) [ 36.273437] [c018d79c] (ubi_attach_mtd_dev+0x1dc/0x4bc) from [c018dccc] (ctrl_cdev_ioctl+0xd4/0x164) [ 36.273437] [c018dccc] (ctrl_cdev_ioctl+0xd4/0x164) from [c0076890] (do_vfs_ioctl+0x270/0x2ac) [ 36.273437] [c0076890] (do_vfs_ioctl+0x270/0x2ac) from [c0076900] (sys_ioctl+0x34/0x54) [ 36.273437] [c0076900] (sys_ioctl+0x34/0x54) from [c00091e0] (ret_fast_syscall+0x0/0x2c) [ 36.273437] Code: e1a01005 e593 ebfb44ff ea74 (e5983020) [ 36.281250] ---[ end trace f540180ccfcbf7f6 ]--- Segmentation fault 2012/7/4 Shmulik Ladkani shmulik.ladk...@gmail.com: On Wed, 04 Jul 2012 10:35:42 +0200 Richard Weinberger rich...@nod.at wrote: Has this patch set an impact on UBI fastmap? Not sure yet. Maybe. Need to medidate on this :-) ...wondering why I'm CC'd. :-) Heads-up. As this is a bit delicate, you may review if the parts modified relate to your fastmap work. Regards, Shmulik -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at
