Although my fix is in the core JFFS files it is specific to eCos. The
problem is how jffs2_gc_fetch_page is implemented, which is located in
fs-ecos.c. The eCos port of jffs2_gc_fetch_page copies data out of FLASH
into a static buffer and returns a pointer to the static buffer. This means
what is returned is data at a given offset. However, the garbage collector
assumes that an offset needs to be applied to the value returned from
jffs2_gc_fetch_page.
A possible alternative is for jffs2_gc_fetch_page to return
gc_buffer-offset.
I haven't tried it yet. Besides this solution is a bit scary because the
returned pointer is not pointing to valid memory, but it is eCos specific.
Your thoughts? Should I investigate this alternative or post my original
patch?
----- Original Message -----
From: "Andrew Lunn" <andrew@lunn.ch>
To: "Alf Nilsson" <alf.nilsson@abem.se>
Cc: "Mark Hamilton" <mark_lee_hamilton@sbcglobal.net>; "eCos Disuss"
<ecos-discuss@ecos.sourceware.org>
Sent: Tuesday, October 05, 2004 9:44 AM
Subject: Re: [ECOS] JFFS2 fragment corruption during gc?
On Tue, Oct 05, 2004 at 06:36:36PM +0200, Alf Nilsson wrote:
Hi Mark,
I've tried your suggested solution and my test runs like a dream, well
at least almost.
There is another error present that has to do with the return of ENOSPC,
this increases the use count on a node so that the umount() function
fails.
But that is another story for the moment.
But if I'm not mistaken the gc.c file is a general JFFS2 file, so the
alterations should really be in the fs-ecos.c file instead.
That's if the Linux folks are not having the same type of problems.
Since this is a jffs2 core file i don't want to add eCos patches to
it. You need to get the jffs2 people to acknowledge the bug and fix it
in their repository.
Try again on the jffs2 mailling list. Give them enough details that
they can try to reproduce the problems on Linux. Explain what you
think is wrong and why your fix fixes it.
Andrew