2012/8/20 Artem Bityutskiy :
> On Mon, 2012-08-20 at 08:55 +0200, Richard Genoud wrote:
>> Hi Artem,
>> 2012/8/19 Artem Bityutskiy :
>> > Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
>> > need some more work to avoid division by 0.
>> Division by 0 is handled in the
On Mon, 2012-08-20 at 08:55 +0200, Richard Genoud wrote:
> Hi Artem,
> 2012/8/19 Artem Bityutskiy :
> > Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
> > need some more work to avoid division by 0.
> Division by 0 is handled in the get_bad_peb_limit() function, I don't
>
Hi Artem,
2012/8/19 Artem Bityutskiy :
> Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
> need some more work to avoid division by 0.
Division by 0 is handled in the get_bad_peb_limit() function, I don't
see another dangerous place.
So, I think that we can change back the
Hi Artem,
2012/8/19 Artem Bityutskiy dedeki...@gmail.com:
Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
need some more work to avoid division by 0.
Division by 0 is handled in the get_bad_peb_limit() function, I don't
see another dangerous place.
So, I think that we can
On Mon, 2012-08-20 at 08:55 +0200, Richard Genoud wrote:
Hi Artem,
2012/8/19 Artem Bityutskiy dedeki...@gmail.com:
Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
need some more work to avoid division by 0.
Division by 0 is handled in the get_bad_peb_limit() function,
2012/8/20 Artem Bityutskiy dedeki...@gmail.com:
On Mon, 2012-08-20 at 08:55 +0200, Richard Genoud wrote:
Hi Artem,
2012/8/19 Artem Bityutskiy dedeki...@gmail.com:
Yeah, I wanted to make it 1..256 but forgot, will do now. 0..256 would
need some more work to avoid division by 0.
Division by
On Sun, 2012-08-19 at 10:09 +0300, Shmulik Ladkani wrote:
> On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy
> wrote:
> > We do not have that big user-base. No one uses 0 in the tree, most use
> > the default. I never heard anyone using 0. I did not use it also. I
> > think it is OK to have
On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy wrote:
> We do not have that big user-base. No one uses 0 in the tree, most use
> the default. I never heard anyone using 0. I did not use it also. I
> think it is OK to have the lower range start from non-zero. But why it
> is 2 and not 1 - I
On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy dedeki...@gmail.com wrote:
We do not have that big user-base. No one uses 0 in the tree, most use
the default. I never heard anyone using 0. I did not use it also. I
think it is OK to have the lower range start from non-zero. But why it
is 2
On Sun, 2012-08-19 at 10:09 +0300, Shmulik Ladkani wrote:
On Thu, 16 Aug 2012 16:33:32 +0300 Artem Bityutskiy dedeki...@gmail.com
wrote:
We do not have that big user-base. No one uses 0 in the tree, most use
the default. I never heard anyone using 0. I did not use it also. I
think it is
On Thu, 2012-08-16 at 16:30 +0200, Richard Genoud wrote:
> > (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:
>
On Thu, 2012-08-16 at 16:50 +0300, Shmulik Ladkani wrote:
> 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
>
On Thu, 2012-08-16 at 16:50 +0300, Shmulik Ladkani wrote:
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
On Thu, 2012-08-16 at 16:30 +0200, Richard Genoud wrote:
(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:
2012/8/16 Shmulik Ladkani :
> On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy
> 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
On Thu, 16 Aug 2012 16:28:38 +0300 Artem Bityutskiy 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
On Thu, 2012-08-16 at 13:42 +0300, Shmulik Ladkani wrote:
>
> Does it make sense to set a zero limit? dunno.
> For testing purposes, maybe.
>
> Artem, what do you think? prohibit a zero beb limit?
We do not have that big user-base. No one uses 0 in the tree, most use
the default. I never heard
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
Hi Richard, Artem,
On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud
wrote:
> > 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
2012/8/16 Shmulik Ladkani :
> Hi Richard,
>
> Sorry for reviewing this late...
>
> On Tue, 10 Jul 2012 18:23:42 +0200 Richard Genoud
> wrote:
>> -config MTD_UBI_BEB_LIMIT
>> - int "Maximum expected bad eraseblocks per 1024 eraseblocks"
>> - default 20
>> - range 2 256
>
> I see some
Hi Richard,
Sorry for reviewing this late...
On Tue, 10 Jul 2012 18:23:42 +0200 Richard Genoud
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
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.
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
Hi Richard, Artem,
On Thu, 16 Aug 2012 12:07:01 +0200 Richard Genoud richard.gen...@gmail.com
wrote:
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
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
On Thu, 2012-08-16 at 13:42 +0300, Shmulik Ladkani wrote:
Does it make sense to set a zero limit? dunno.
For testing purposes, maybe.
Artem, what do you think? prohibit a zero beb limit?
We do not have that big user-base. No one uses 0 in the tree, most use
the default. I never heard
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
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
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
> 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
On Tue, 2012-07-10 at 18:23 +0200, Richard Genoud wrote:
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
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:
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:
32 matches
Mail list logo
