1. Support for preseeded fastmaps.
A preseeded fastmap is a fastmap created by tools such as ubinize.
That way fastmap deployment is less painful and fast attach is
available upon first boot.
2. Refine various checks.
Detect misconfigured setups better.
3. Allow a forcing a full scan.
Forcing a
1. Support for preseeded fastmaps.
A preseeded fastmap is a fastmap created by tools such as ubinize.
That way fastmap deployment is less painful and fast attach is
available upon first boot.
2. Refine various checks.
Detect misconfigured setups better.
3. Allow a forcing a full scan.
Forcing a
On Sat, 2013-09-28 at 15:55 +0200, Richard Weinberger wrote:
> this series is a collection of all pending UBI fastmap updates.
>
> Richard Genoud found issues in combination with U-Boot.
> These issues also uncovered other minor issues in some error paths.
> Only one fix is not
On Sat, 2013-09-28 at 15:55 +0200, Richard Weinberger wrote:
this series is a collection of all pending UBI fastmap updates.
Richard Genoud found issues in combination with U-Boot.
These issues also uncovered other minor issues in some error paths.
Only one fix is not really fastmap specific
this series is a collection of all pending UBI fastmap updates.
Richard Genoud found issues in combination with U-Boot.
These issues also uncovered other minor issues in some error paths.
Only one fix is not really fastmap specific and touches generic
UBI code, "UBI: simplify image sequence
this series is a collection of all pending UBI fastmap updates.
Richard Genoud found issues in combination with U-Boot.
These issues also uncovered other minor issues in some error paths.
Only one fix is not really fastmap specific and touches generic
UBI code, UBI: simplify image sequence test
On Fri, 2012-08-17 at 15:43 +0200, Richard Weinberger wrote:
> No, data is never added to a half-filled PEB.
OK.
> Fastmap does not share PEBs with other sub-systems by design.
It could in theory add own data to own PEBs.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is
Am Fri, 17 Aug 2012 16:41:24 +0300
schrieb Artem Bityutskiy :
> On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
> > Am Fri, 17 Aug 2012 16:11:55 +0300
> > schrieb Artem Bityutskiy :
> > > We do not do anything like this in UBI because UBI does not need
> > > this, it does not have
On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
> Am Fri, 17 Aug 2012 16:11:55 +0300
> schrieb Artem Bityutskiy :
> > We do not do anything like this in UBI because UBI does not need this,
> > it does not have any complex data structures on the media.
> >
> > With fastmap - I am
Am Fri, 17 Aug 2012 16:11:55 +0300
schrieb Artem Bityutskiy :
> We do not do anything like this in UBI because UBI does not need this,
> it does not have any complex data structures on the media.
>
> With fastmap - I am unsure. I think it is not a problem, because
> probably you never append more
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
One thing which
Am Fri, 17 Aug 2012 16:11:55 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
We do not do anything like this in UBI because UBI does not need this,
it does not have any complex data structures on the media.
With fastmap - I am unsure. I think it is not a problem, because
On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
Am Fri, 17 Aug 2012 16:11:55 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
We do not do anything like this in UBI because UBI does not need this,
it does not have any complex data structures on the media.
Am Fri, 17 Aug 2012 16:41:24 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Fri, 2012-08-17 at 15:33 +0200, Richard Weinberger wrote:
Am Fri, 17 Aug 2012 16:11:55 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
We do not do anything like this in UBI
On Fri, 2012-08-17 at 15:43 +0200, Richard Weinberger wrote:
No, data is never added to a half-filled PEB.
OK.
Fastmap does not share PEBs with other sub-systems by design.
It could in theory add own data to own PEBs.
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a
On Tue, 2012-08-07 at 09:29 +0200, Richard Weinberger wrote:
> Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
> > On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
> >> I think we enable fastmap only if a MTD device has more than
> >> UBI_FM_MAX_START*2 PEBs.
> >> Any comments?
> >
> >
Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
> On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
>> I think we enable fastmap only if a MTD device has more than
>> UBI_FM_MAX_START*2 PEBs.
>> Any comments?
>
> With double space one can make it power-cut tolerant, because you should
>
On Tue, 2012-08-07 at 09:29 +0200, Richard Weinberger wrote:
Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
I think we enable fastmap only if a MTD device has more than
UBI_FM_MAX_START*2 PEBs.
Any comments?
With double
Am 07.08.2012 06:21, schrieb Artem Bityutskiy:
On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
I think we enable fastmap only if a MTD device has more than
UBI_FM_MAX_START*2 PEBs.
Any comments?
With double space one can make it power-cut tolerant, because you should
be able
On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
> I think we enable fastmap only if a MTD device has more than
> UBI_FM_MAX_START*2 PEBs.
> Any comments?
With double space one can make it power-cut tolerant, because you should
be able to have either old or new fastmap at any point of
Am 02.08.2012 16:58, schrieb Artem Bityutskiy:
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
>> This is the next round of UBI fastmap updates.
>> It fixes all issues pointed out by Shmulik. :-)
>
> Hi Richard,
>
> when I try to attach mtdram (NOR
Am 02.08.2012 16:58, schrieb Artem Bityutskiy:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
Hi Richard,
when I try to attach mtdram (NOR flash), UBI fails:
Fastmap works fine
On Mon, 2012-08-06 at 19:36 +0200, Richard Weinberger wrote:
I think we enable fastmap only if a MTD device has more than
UBI_FM_MAX_START*2 PEBs.
Any comments?
With double space one can make it power-cut tolerant, because you should
be able to have either old or new fastmap at any point of
Am 05.08.2012 10:23, schrieb Shmulik Ladkani:
> On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger wrote:
>> Okay, then let's explicitly reserve a few PEBs for fastmap.
>> This should be very easy task.
>
> Need to consider what's expected when migrating from a former non-FM
> UBI system to an
Hi,
On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger wrote:
> Okay, then let's explicitly reserve a few PEBs for fastmap.
> This should be very easy task.
Need to consider what's expected when migrating from a former non-FM
UBI system to an FM enabled system, in the case where all PEBs
Hi,
On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger rich...@nod.at wrote:
Okay, then let's explicitly reserve a few PEBs for fastmap.
This should be very easy task.
Need to consider what's expected when migrating from a former non-FM
UBI system to an FM enabled system, in the case where
Am 05.08.2012 10:23, schrieb Shmulik Ladkani:
On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger rich...@nod.at wrote:
Okay, then let's explicitly reserve a few PEBs for fastmap.
This should be very easy task.
Need to consider what's expected when migrating from a former non-FM
UBI system
Am Fri, 03 Aug 2012 11:47:17 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
> >
> > If you want to test fastmap you c
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ub
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Richard,
I've
Am Fri, 03 Aug 2012 11:47:17 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can
On Thu, 2012-08-02 at 21:50 +0300, Artem Bityutskiy wrote:
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
> >
> > If you want to test fastmap you c
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
>
> If you want to test fastmap you can use my git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ub
On Thu, 2012-08-02 at 20:03 +0200, Richard Weinberger wrote:
> > If I understand correctly, fastmap size is a function of total PEBs
> > count. You should be able to calculate the maximum size precisely.
>
> It does.
> I was thinking of 2 x sizeof(fastmap) to have reserved PEBs for the
>
Am Thu, 02 Aug 2012 20:59:28 +0300
schrieb Artem Bityutskiy :
> > How much PEB should be reserved? 2 x sizeof(fastmap)?
>
> Is there any reason why it cannot be the _exact_ maximum number? Not
> more and not less.
The fastmap size is an exact number.
> If I understand correctly, fastmap size
On Thu, 2012-08-02 at 19:45 +0200, Richard Weinberger wrote:
> This should be very easy task.
Right. But unfortunately, I had to spend a lot of time writing lengthy
e-mails. You could hold your horses for a minute, ask specific questions
and find out what was my concern.
> How much PEB should be
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> > So can I interpret this the following way. Not only fastmap give no
> > guarantees that it exists after an unclean reboot, it does not even give
> > guarantees that it exists after a clean reboot.
> >
> > Unless I am confused, the fastmap
Am Thu, 02 Aug 2012 20:40:00 +0300
schrieb Artem Bityutskiy :
> Hi Tim,
>
> On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> > I'm don't understand what "UBI liability" is. Can you please
> > clarify? What breaks if the PEBs get consumed?
>
> let me try. Let's forget about bad blocks and
Hi Tim,
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
> I'm don't understand what "UBI liability" is. Can you please clarify?
> What breaks if the PEBs get consumed?
let me try. Let's forget about bad blocks and assume we are talking
about NOR flash. For simplicity.
Let's also first
Am Thu, 2 Aug 2012 10:03:04 -0700
schrieb Tim Bird :
> >> If everything goes wrong, fastmap makes sure that no fastmap is on
> >> flash.
> >> In case of a powercut we fall back to scanning mode.
> >> R/O mode is overkill IMHO.
> >
> > So can I interpret this the following way. Not only fastmap
On 08/02/2012 09:45 AM, Artem Bityutskiy wrote:
> Richard,
>
> On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
>>> This should not happen. Fastmap should _reserve_ enough of PEBs for it
>>> to operate. It should always find the PEB to write.
>>
>> What is the benefit?
>> IOW what is
Am Thu, 02 Aug 2012 19:45:30 +0300
schrieb Artem Bityutskiy :
> Richard,
>
> On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
> > > This should not happen. Fastmap should _reserve_ enough of PEBs
> > > for it to operate. It should always find the PEB to write.
> >
> > What is the
Richard,
On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
> > This should not happen. Fastmap should _reserve_ enough of PEBs for it
> > to operate. It should always find the PEB to write.
>
> What is the benefit?
> IOW what is wrong with the current approach?
Several reasons. The
Am Thu, 02 Aug 2012 19:17:47 +0300
schrieb Artem Bityutskiy :
> On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
> > Every time fastmap writes a new fastmap to the flash it tries to
> > get a new PEB and returns the old one (used for the old fastmap)
> > back to the WL sub-system.
>
On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
> Every time fastmap writes a new fastmap to the flash it tries to get a
> new PEB and returns the old one (used for the old fastmap) back to the
> WL sub-system.
OK.
> If no free PEBs are available (E.g Volume is full or the erase
Am Thu, 02 Aug 2012 18:18:48 +0300
schrieb Artem Bityutskiy :
> > Hmm, and without fastmap it works fine?
>
> Yes.
>
> > I don't see much fastmap related here.
>
> It is related to your changes in attach.c.
Okay, I'll dig into the issue.
Thanks,
//richard
--
To unsubscribe from this list:
On Thu, 2012-08-02 at 16:59 +0200, Richard Weinberger wrote:
> Am Thu, 02 Aug 2012 17:58:50 +0300
> schrieb Artem Bityutskiy :
>
> > On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > > This is the next round of UBI fastmap updates.
> > > It fixes
Am Thu, 02 Aug 2012 17:58:50 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
>
> Hi Richard,
>
> when I try to att
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
Hi Richard,
when I try to attach mtdram (NOR flash), UBI fails:
[ 7106.353791] UBI assert failed in ubi_io_is_bad at 623 (pi
Am Thu, 02 Aug 2012 17:29:01 +0300
schrieb Artem Bityutskiy :
> On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
> > > If I understand correctly, it can be only because of a bug. If I
> > > am correct, could you please add a 'dump_stack()' to improve the
> > > error report?
> > >
> >
On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
> > If I understand correctly, it can be only because of a bug. If I am
> > correct, could you please add a 'dump_stack()' to improve the error
> > report?
> >
>
> This can happen if all PEBs are used and fastmap is unable to find (or
Artem,
Am Thu, 02 Aug 2012 17:12:27 +0300
schrieb Artem Bityutskiy :
> On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> > This is the next round of UBI fastmap updates.
> > It fixes all issues pointed out by Shmulik. :-)
>
> I see the following error
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
> It fixes all issues pointed out by Shmulik. :-)
I see the following errors when rung UBI tests on nandsim:
[ 3698.041511] UBI error: __wl_get_peb: no free eraseblocks
[ 3698.
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
I see the following errors when rung UBI tests on nandsim:
[ 3698.041511] UBI error: __wl_get_peb: no free eraseblocks
[ 3698.041781] UBI
Artem,
Am Thu, 02 Aug 2012 17:12:27 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
I see the following errors when
On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
If I understand correctly, it can be only because of a bug. If I am
correct, could you please add a 'dump_stack()' to improve the error
report?
This can happen if all PEBs are used and fastmap is unable to find (or
produce)
Am Thu, 02 Aug 2012 17:29:01 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
If I understand correctly, it can be only because of a bug. If I
am correct, could you please add a 'dump_stack()' to improve the
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
Hi Richard,
when I try to attach mtdram (NOR flash), UBI fails:
[ 7106.353791] UBI assert failed in ubi_io_is_bad at 623 (pid 5411
Am Thu, 02 Aug 2012 17:58:50 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
Hi Richard,
when I try to attach
On Thu, 2012-08-02 at 16:59 +0200, Richard Weinberger wrote:
Am Thu, 02 Aug 2012 17:58:50 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues
Am Thu, 02 Aug 2012 18:18:48 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
Hmm, and without fastmap it works fine?
Yes.
I don't see much fastmap related here.
It is related to your changes in attach.c.
Okay, I'll dig into the issue.
Thanks,
//richard
--
To
On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
Every time fastmap writes a new fastmap to the flash it tries to get a
new PEB and returns the old one (used for the old fastmap) back to the
WL sub-system.
OK.
If no free PEBs are available (E.g Volume is full or the erase worker
Am Thu, 02 Aug 2012 19:17:47 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
On Thu, 2012-08-02 at 16:51 +0200, Richard Weinberger wrote:
Every time fastmap writes a new fastmap to the flash it tries to
get a new PEB and returns the old one (used for the old fastmap)
back
Richard,
On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
This should not happen. Fastmap should _reserve_ enough of PEBs for it
to operate. It should always find the PEB to write.
What is the benefit?
IOW what is wrong with the current approach?
Several reasons. The main is:
Am Thu, 02 Aug 2012 19:45:30 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
Richard,
On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
This should not happen. Fastmap should _reserve_ enough of PEBs
for it to operate. It should always find the PEB to write.
On 08/02/2012 09:45 AM, Artem Bityutskiy wrote:
Richard,
On Thu, 2012-08-02 at 18:32 +0200, Richard Weinberger wrote:
This should not happen. Fastmap should _reserve_ enough of PEBs for it
to operate. It should always find the PEB to write.
What is the benefit?
IOW what is wrong with the
Am Thu, 2 Aug 2012 10:03:04 -0700
schrieb Tim Bird tim.b...@am.sony.com:
If everything goes wrong, fastmap makes sure that no fastmap is on
flash.
In case of a powercut we fall back to scanning mode.
R/O mode is overkill IMHO.
So can I interpret this the following way. Not only
Hi Tim,
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
I'm don't understand what UBI liability is. Can you please clarify?
What breaks if the PEBs get consumed?
let me try. Let's forget about bad blocks and assume we are talking
about NOR flash. For simplicity.
Let's also first forget
Am Thu, 02 Aug 2012 20:40:00 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
Hi Tim,
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
I'm don't understand what UBI liability is. Can you please
clarify? What breaks if the PEBs get consumed?
let me try. Let's forget
On Thu, 2012-08-02 at 10:03 -0700, Tim Bird wrote:
So can I interpret this the following way. Not only fastmap give no
guarantees that it exists after an unclean reboot, it does not even give
guarantees that it exists after a clean reboot.
Unless I am confused, the fastmap design is
On Thu, 2012-08-02 at 19:45 +0200, Richard Weinberger wrote:
This should be very easy task.
Right. But unfortunately, I had to spend a lot of time writing lengthy
e-mails. You could hold your horses for a minute, ask specific questions
and find out what was my concern.
How much PEB should be
Am Thu, 02 Aug 2012 20:59:28 +0300
schrieb Artem Bityutskiy artem.bityuts...@linux.intel.com:
How much PEB should be reserved? 2 x sizeof(fastmap)?
Is there any reason why it cannot be the _exact_ maximum number? Not
more and not less.
The fastmap size is an exact number.
If I
On Thu, 2012-08-02 at 20:03 +0200, Richard Weinberger wrote:
If I understand correctly, fastmap size is a function of total PEBs
count. You should be able to calculate the maximum size precisely.
It does.
I was thinking of 2 x sizeof(fastmap) to have reserved PEBs for the
currently used
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Richard, would
On Thu, 2012-08-02 at 21:50 +0300, Artem Bityutskiy wrote:
On Mon, 2012-07-09 at 14:18 +0200, Richard Weinberger wrote:
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Enjoy!
//richard
[PATCH 1/7] UBI: Fastmap: Fix lock imbalance in case
Am 09.07.2012 09:37, schrieb Shmulik Ladkani:
> Hi Richard,
>
> On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger wrote:
>>> + /* TODO: in the new locking scheme, produce_free_peb is
>>> +* called under wl_lock taken.
>>> +* so when
Hi Richard,
On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger wrote:
> > + /* TODO: in the new locking scheme, produce_free_peb is
> > +* called under wl_lock taken.
> > +* so when returning, should reacquire the lock
> > +
Hi Richard,
On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger rich...@nod.at wrote:
+ /* TODO: in the new locking scheme, produce_free_peb is
+* called under wl_lock taken.
+* so when returning, should reacquire the lock
+
Am 09.07.2012 09:37, schrieb Shmulik Ladkani:
Hi Richard,
On Sun, 08 Jul 2012 14:07:41 +0200 Richard Weinberger rich...@nod.at wrote:
+ /* TODO: in the new locking scheme, produce_free_peb is
+* called under wl_lock taken.
+* so when
This is the next round of UBI fastmap updates.
It fixes all issues pointed out by Shmulik. :-)
If you want to test fastmap you can use my git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubi2.git ubi2/v17
Enjoy!
//richard
[PATCH 1/7] UBI: Fastmap: Fix lock imbalance in case
Am 08.07.2012 14:07, schrieb Richard Weinberger:
> Hi Shmulik!
>
> Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
>> +
>> +/* TODO: if find_fastmap==1, we do not enter this block at all.
>> + * shouldn't we? shouldn't we care of compatability of unknown
>> + *
Hi Shmulik!
Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
> +
> + /* TODO: if find_fastmap==1, we do not enter this block at all.
> + * shouldn't we? shouldn't we care of compatability of unknown
> + * internal volumes OTHER than the fastmap ones, even if
> +
Hi Richard,
On Fri, 29 Jun 2012 17:14:18 +0200 Richard Weinberger wrote:
> This is the next round of UBI fastmap updates.
Please examine some TODOs (and questions) I've spotted while diffing
against "vanilla" ubi.
This patch should apply to linux-ubi at d41a140
Sorry I co
Hi Richard,
On Fri, 29 Jun 2012 17:14:18 +0200 Richard Weinberger rich...@nod.at wrote:
This is the next round of UBI fastmap updates.
Please examine some TODOs (and questions) I've spotted while diffing
against vanilla ubi.
This patch should apply to linux-ubi at d41a140
Sorry I couldn't
Hi Shmulik!
Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
+
+ /* TODO: if find_fastmap==1, we do not enter this block at all.
+ * shouldn't we? shouldn't we care of compatability of unknown
+ * internal volumes OTHER than the fastmap ones, even if
+
Am 08.07.2012 14:07, schrieb Richard Weinberger:
Hi Shmulik!
Am 08.07.2012 13:47, schrieb Shmulik Ladkani:
+
+/* TODO: if find_fastmap==1, we do not enter this block at all.
+ * shouldn't we? shouldn't we care of compatability of unknown
+ * internal
88 matches
Mail list logo
