On Fri, 2013-03-01 at 15:29 +0100, Richard Genoud wrote:
> > Unfortunately I have no additional information why it happened, but
> anyway is it really necessary to runs ubiformat+ubimkvol for such
> cases? Or is it possible to recover data?
> I honestly don't know, but I'm sure Artem has some idea
On Fri, 2013-03-01 at 15:29 +0100, Richard Genoud wrote:
Unfortunately I have no additional information why it happened, but
anyway is it really necessary to runs ubiformat+ubimkvol for such
cases? Or is it possible to recover data?
I honestly don't know, but I'm sure Artem has some idea on
2013/3/1 Velykokhatko, Sergey :
> Hi Richard,
>
>>And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's
>>possible, via the ubiattach call ( get the master branchof of
>>git://git.infradead.org/mtd-utils.git ) cf
Best regards,
Sergey
-Ursprüngliche Nachricht-
Von: Richard Genoud [mailto:richard.gen...@gmail.com]
Gesendet: Freitag, 1. März 2013 13:10
An: Velykokhatko, Sergey
Cc: Brian Norris; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com
Betr
2013/3/1 Velykokhatko, Sergey :
> Hi Richard,
>
> Thanks a lot for your explanations. Now at least I understand your logic. And
> it seems to be reasonable. Your start point that all bad blocks for flash
> chip could be placed in single MTD. This is really worst worst case, but...
>
On Fri, 1 Mar 2013, Richard Genoud wrote:
From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB)
valid blocks out
of every 2,048 total available blocks. This means the devices may have
blocks that are
invalid when they are shipped. An invalid block is
gey
Cc: Brian Norris; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?
2013/3/1 Velykokhatko, Sergey :
> Hi Brian,
>
> Thanks for your answer. Ok, I have nothing against that my interpretation of
2013/3/1 Velykokhatko, Sergey :
> Hi Brian,
>
> Thanks for your answer. Ok, I have nothing against that my interpretation of
> mtd_get_device_size() purpose is wrong. But what you mean under: "Because
> your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of your
> total size, or
@gmail.com]
Gesendet: Freitag, 1. März 2013 09:11
An: Brian Norris
Cc: Velykokhatko, Sergey; linux-...@lists.infradead.org;
linux-kernel@vger.kernel.org; artem.bityuts...@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?
2013/2/28 Brian Norris :
> + Richard
>
> On Thu, Feb
29.4M 0% /run
-Ursprüngliche Nachricht-
Von: Brian Norris [mailto:computersforpe...@gmail.com]
Gesendet: Donnerstag, 28. Februar 2013 18:25
An: Velykokhatko, Sergey
Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com; Richard Genoud
-Ursprüngliche Nachricht-
Von: Brian Norris [mailto:computersforpe...@gmail.com]
Gesendet: Donnerstag, 28. Februar 2013 18:25
An: Velykokhatko, Sergey
Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com; Richard Genoud
Betreff: Re: Bug in mtd_get_device_size
]
Gesendet: Freitag, 1. März 2013 09:11
An: Brian Norris
Cc: Velykokhatko, Sergey; linux-...@lists.infradead.org;
linux-kernel@vger.kernel.org; artem.bityuts...@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?
2013/2/28 Brian Norris computersforpe...@gmail.com:
+ Richard
On Thu, Feb 28, 2013
2013/3/1 Velykokhatko, Sergey sergey.velykokha...@mcc-med.de:
Hi Brian,
Thanks for your answer. Ok, I have nothing against that my interpretation of
mtd_get_device_size() purpose is wrong. But what you mean under: Because
your BEB_LIMIT=100, you are reserving 100*size/1024 (that is 9.8% of
Norris; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com
Betreff: Re: Bug in mtd_get_device_size()?
2013/3/1 Velykokhatko, Sergey sergey.velykokha...@mcc-med.de:
Hi Brian,
Thanks for your answer. Ok, I have nothing against that my interpretation
On Fri, 1 Mar 2013, Richard Genoud wrote:
From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB)
valid blocks out
of every 2,048 total available blocks. This means the devices may have
blocks that are
invalid when they are shipped. An invalid block is
2013/3/1 Velykokhatko, Sergey sergey.velykokha...@mcc-med.de:
Hi Richard,
Thanks a lot for your explanations. Now at least I understand your logic. And
it seems to be reasonable. Your start point that all bad blocks for flash
chip could be placed in single MTD. This is really worst worst
,
Sergey
-Ursprüngliche Nachricht-
Von: Richard Genoud [mailto:richard.gen...@gmail.com]
Gesendet: Freitag, 1. März 2013 13:10
An: Velykokhatko, Sergey
Cc: Brian Norris; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org;
artem.bityuts...@linux.intel.com
Betreff: Re: Bug
2013/3/1 Velykokhatko, Sergey sergey.velykokha...@mcc-med.de:
Hi Richard,
And if you want to tweak the BEB_LIMIT for each of your UBI partition, it's
possible, via the ubiattach call ( get the master branchof of
git://git.infradead.org/mtd-utils.git ) cf
+ Richard
On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey
wrote:
> I got today such case:
>
> * Kernel 3.8
>
> * We are using M29F2G16 NAND chip with 4096 blocks, each has 128k
>
> * Configured with CONFIG_MTD_UBI_BEB_LIMIT=100
This is your problem. See below for more
+ Richard
On Thu, Feb 28, 2013 at 4:30 AM, Velykokhatko, Sergey
sergey.velykokha...@mcc-med.de wrote:
I got today such case:
* Kernel 3.8
* We are using M29F2G16 NAND chip with 4096 blocks, each has 128k
* Configured with CONFIG_MTD_UBI_BEB_LIMIT=100
This is your
20 matches
Mail list logo
