Am 02.10.2014 15:42, schrieb Tanya Brokhman:
> How do you test all of your fastmap fixes? Some of them are not easy to
> reproduce (the pq saving for example). Besides heavy stability testing, I was
> testing my changes manually by
> a lot of dbg prints in the code and analyzing the logs manually
On Thu, 2014-10-02 at 16:05 +0200, Richard Weinberger wrote:
> The question is, do we really need all this values on-flash?
Good question, this is why I requested some kind of design description,
which would clearly explain the problem.
Just off-the top of my head, may be it could be enough to ke
On 10/2/2014 4:36 PM, Richard Weinberger wrote:
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Hi Richard,
Sorry it took me some time to answer, got per-occupied with some urgent staff.
On 9/28/2014 1:54 PM, Richard Weinberger wrote:
Am 28.09.2014 12:46, schrieb Tanya Brokhman:
On 9/28/2014 11
Am 02.10.2014 15:42, schrieb Tanya Brokhman:
> On 10/2/2014 4:24 PM, Richard Weinberger wrote:
>> Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Consider the case where you have a board with a fastmap enabled bootloader
and a Linux OS.
The bootloader does a fastmap attach and boots th
On 10/2/2014 4:24 PM, Richard Weinberger wrote:
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
Consider the case where you have a board with a fastmap enabled bootloader and
a Linux OS.
The bootloader does a fastmap attach and boots the kernel from UBI and the
kernel it self has the rootfs
on UB
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
> Hi Richard,
>
> Sorry it took me some time to answer, got per-occupied with some urgent staff.
>
> On 9/28/2014 1:54 PM, Richard Weinberger wrote:
>> Am 28.09.2014 12:46, schrieb Tanya Brokhman:
>>> On 9/28/2014 11:54 AM, Richard Weinberger wrote:
>>
Am 02.10.2014 14:50, schrieb Tanya Brokhman:
>> Consider the case where you have a board with a fastmap enabled bootloader
>> and a Linux OS.
>> The bootloader does a fastmap attach and boots the kernel from UBI and the
>> kernel it self has the rootfs
>> on UBI too. If you install a new kernel w
Hi Richard,
Sorry it took me some time to answer, got per-occupied with some urgent
staff.
On 9/28/2014 1:54 PM, Richard Weinberger wrote:
Am 28.09.2014 12:46, schrieb Tanya Brokhman:
On 9/28/2014 11:54 AM, Richard Weinberger wrote:
Am 28.09.2014 10:48, schrieb Tanya Brokhman:
@@ -424,6 +4
Tanya,
On Mon, Sep 29, 2014 at 07:46:34AM +0300, Tanya Brokhman wrote:
> Hi Jeremiah,
>
> On 9/28/2014 9:13 PM, Jeremiah Mahler wrote:
> >Tanya,
> >
> >On Sun, Sep 28, 2014 at 09:37:00AM +0300, Tanya Brokhman wrote:
> >>The need for performing read disturb is determined according to new
> >>stati
Hi Jeremiah,
On 9/28/2014 9:13 PM, Jeremiah Mahler wrote:
Tanya,
On Sun, Sep 28, 2014 at 09:37:00AM +0300, Tanya Brokhman wrote:
The need for performing read disturb is determined according to new
statistics collected per eraseblock:
- read counter: incremented at each read operation
Tanya,
On Sun, Sep 28, 2014 at 09:37:00AM +0300, Tanya Brokhman wrote:
> The need for performing read disturb is determined according to new
> statistics collected per eraseblock:
> - read counter: incremented at each read operation
> reset at each erase
> - last erase time stamp:
On 9/28/2014 3:11 PM, Artem Bityutskiy wrote:
On Sun, 2014-09-28 at 09:37 +0300, Tanya Brokhman wrote:
The need for performing read disturb is determined according to new
statistics collected per eraseblock:
- read counter: incremented at each read operation
reset at each erase
On Sun, 2014-09-28 at 09:37 +0300, Tanya Brokhman wrote:
> The need for performing read disturb is determined according to new
> statistics collected per eraseblock:
> - read counter: incremented at each read operation
> reset at each erase
> - last erase time stamp: updated at each
Am 28.09.2014 12:46, schrieb Tanya Brokhman:
> On 9/28/2014 11:54 AM, Richard Weinberger wrote:
>> Am 28.09.2014 10:48, schrieb Tanya Brokhman:
> @@ -424,6 +440,8 @@ struct ubi_fm_sb {
>__be32 used_blocks;
>__be32 block_loc[UBI_FM_MAX_BLOCKS];
>__be32 block_e
On 9/28/2014 11:54 AM, Richard Weinberger wrote:
Am 28.09.2014 10:48, schrieb Tanya Brokhman:
@@ -424,6 +440,8 @@ struct ubi_fm_sb {
__be32 used_blocks;
__be32 block_loc[UBI_FM_MAX_BLOCKS];
__be32 block_ec[UBI_FM_MAX_BLOCKS];
+__be32 block_rc[UBI_FM_MAX_BLOCKS];
+__b
Am 28.09.2014 10:48, schrieb Tanya Brokhman:
>>> @@ -424,6 +440,8 @@ struct ubi_fm_sb {
>>> __be32 used_blocks;
>>> __be32 block_loc[UBI_FM_MAX_BLOCKS];
>>> __be32 block_ec[UBI_FM_MAX_BLOCKS];
>>> +__be32 block_rc[UBI_FM_MAX_BLOCKS];
>>> +__be64 block_let[UBI_FM_MAX_BLOCKS
Hi Richard
On 9/28/2014 11:18 AM, Richard Weinberger wrote:
index 0431b46..5399aa2 100644
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -1,5 +1,7 @@
/*
* Copyright (c) 2012 Linutronix GmbH
+ * Copyright (c) 2014, Linux Foundation. All rights reserved.
+ *
Diffstat s
Tanya,
Am 28.09.2014 08:37, schrieb Tanya Brokhman:
> The need for performing read disturb is determined according to new
> statistics collected per eraseblock:
> - read counter: incremented at each read operation
> reset at each erase
> - last erase time stamp: updated at each era
18 matches
Mail list logo
