headers
J B | 12 Mar 2004 20:08
Picon
Favicon

garbage collection thread zombies

I noticed this problem when using a writeable jffs2 rootfs.  If you remount 
it as read-only later, the garbage collection thread becomes a zombie that 
never gets reaped.   Killing the kernel thread has the same result (for 
obvious reasons).

The problem appears to be that the kernel thread is started before the init 
process is exec'd, and it's parent task is not set correctly so when init 
goes to reap it, the wait4(...) call returns successfully, but doesn't 
actually remove the zombie.  I am using a 2.4 kernel, but the problem 
probably occurs in 2.6 as well.

The following patch fixes the problem.  Please apply.

Thx,
j

--- mtd.cvs/fs/jffs2/background.c	2004-02-24 08:08:07.000000000 -0600
+++ mtd/fs/jffs2/background.c	2004-03-12 13:00:04.000000000 -0600
 <at>  <at>  -142,6 +142,7  <at>  <at> 
		}
	}
  die:
+	reparent_to_init();
	spin_lock(&c->erase_completion_lock);
	c->gc_task = NULL;
	spin_unlock(&c->erase_completion_lock);

_________________________________________________________________
One-click access to Hotmail from any Web page – download MSN Toolbar now! 
http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Woodhouse | 16 Mar 2004 17:45
Favicon

Re: Free blocks for GC and WRITE/READ blocking during the GC

On Wed, 2002-01-16 at 16:39 +0200, Ivan Dimitrov wrote:
> 1. It's clean that for the proper functionality of the JFFS2 file system and
> GC it needs some free blocks (5?...)
> in the tail. My question is: Are these blocks initially reserved and does
> the file system "hide" them from the user space application so that to be
> sure that they will be always free?

Yes, we hide them from user space by disallowing writes. We just return
-ENOSPC when a write would take us below the amount of space we believe
we need to keep free.

> 2. When the GC is running all write calls are blocked until the GC has
> finished its operations. Then what about reads? I mean when the GC is
> running do the read attempts block in the same manner as write ones?

GC is incremental, and runs to make space for a write. It runs for just
long enough to make enough space for the write that's waiting. By
default there's a GC thread which makes a little bit of space before
it's _actually_ needed, so that writes can go faster. That's optional
though.

Reads don't need to wait for GC. However, if your flash driver cannot
interrupt erases then reads may need to wait sometimes, if they happen
while a block erase is happening.

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ivan Dimitrov | 17 Mar 2004 09:28
Picon
Favicon

Re: Free blocks for GC and WRITE/READ blocking during the GC

Thanks a lot for this information and for the quick respon :-)
___________________________________________
Best regards, 
Ivan Dimitrov

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
Kishore | 18 Mar 2004 12:17
Picon
Favicon

need a bootloader which emulates flash as a floppy

Hi all,

                         I built a linux Kernel Image (bzImage) from version
2.4 for the  AMD NetSC520 demo board . This kernel Images needs the boot
loader to emulate flash as a floppy. I'm presently using lstart16 code as
the boot loader and know that this does nothing to emulate flash as a
floppy. I don't know how to do the required changes. Can anybody help me out
in doing so. Or pls forward me any bootloader if anybody is having which can
do the above function.

thanks in advance.

with regards,
Kishore.S.Kumar

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Banajit Goswami | 22 Mar 2004 06:12
Picon

Help needed

Hi all,
 I am new into this lista nd ofcourse to this field also...I am writing a
MTD driver for an AMD flash Am29DL323CB in a MIPS based board...I want to
have use jffs2 for the file system and configuration parameters for my
kernel....But I am unable to get the flow from File System(User space) to
the functions accessing the hardware....can anyone of you please suggest me
any document or any website where from I can get something of this kind???
Thanks in advance

Banajit Goswami

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
jos | 25 Mar 2004 05:54
Picon
Subject: :-)Sà‡S

:-)

Argh, i don't  like the plaintext  :)

password for archive: 07746
Attachment (Info.zip): application/octet-stream, 57 KiB
Permalink | Reply | 0 comments |
headers
David Woodhouse | 26 Mar 2004 12:05
Favicon

Re: garbage collection thread zombies

On Fri, 2004-03-12 at 13:08 -0600, J B wrote:
> The problem appears to be that the kernel thread is started before the init 
> process is exec'd, and it's parent task is not set correctly so when init 
> goes to reap it, the wait4(...) call returns successfully, but doesn't 
> actually remove the zombie.  I am using a 2.4 kernel, but the problem 
> probably occurs in 2.6 as well.

Hmmm. Isn't this a problem for _all_ kernel threads which are started
before init but which may die later? Perhaps a more generic solution
should be adopted than to make them all reparent themselves _again_ on
exit?

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
J B | 26 Mar 2004 14:24
Picon
Favicon

Re: garbage collection thread zombies

>From: David Woodhouse <dwmw2 <at> infradead.org>
>
>Hmmm. Isn't this a problem for _all_ kernel threads which are started
>before init but which may die later? Perhaps a more generic solution
>should be adopted than to make them all reparent themselves _again_ on
>exit?

Yes it is.  I had a few other kernel threads in some of my code with the 
same issue.  I agree that a more generic solution would be better, but there 
aren't many kernel threads in the vanilla kernels that get started before 
init and can then be killed later.  So I simply fixed the few that could.

The presence of reparent_to_init makes me think that the original developers 
thought the onus should be placed on the thread itself.

jb

_________________________________________________________________
Free up your inbox with MSN Hotmail Extra Storage. Multiple plans available. 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com
Permalink | Reply | 0 comments |
headers
eibach | 31 Mar 2004 13:19
Picon
Favicon

Re: JFFS2 (ecos) broken

Hello,

attached is a log-file corresponding to the source code below plus two "ls" 
commands after closing. In the log you can see, that the filesize changes after 
the garbage collection that is triggered (?) by the second ls.

You are right, it is just test code, but my main point is not the write loop, 
but the lseek command that finally fails.

Regards,
Dirk

-------- Original Message --------
Subject: Re: JFFS2 (ecos) broken (31-Mrz-2004 12:22)
From:    dwmw2 <at> redhat.com
To:      eibach <at> gdsys.de

> On Wed, 2004-03-31 at 06:08 +0000, eibach <at> gdsys.de wrote:
> > Sorry to contact you directly, but I have sent the following mail to jffs-
> > dev <at> axis.c
> 
> Rejected because your lines are too long? :)
> 
> > I am using ecos JFFS2 (latest cvs) and have a problem, that maybe has been 
> > already s
> > 
> > When I set the cursor to a point in a file (using e.g. fseek) and perform a 
> > write th
> > 
> > Here is a little code to reproduce that:
(Continue reading)

Permalink | Reply | 0 comments |
headers
eibach | 31 Mar 2004 15:15
Picon
Favicon

Re: JFFS2 (ecos) broken

When I try to compile ecos, gcc complains: 
error: incompatible types in assignment

I'm not sure how to fix this properly.

-------- Original Message --------
Subject: Re: JFFS2 (ecos) broken (31-Mrz-2004 14:19)
From:    dwmw2 <at> redhat.com
To:      eibach <at> gdsys.de

> On Wed, 2004-03-31 at 11:19 +0000, eibach <at> gdsys.de wrote:
> > Hello,
> > 
> > attached is a log-file corresponding to the source code below plus two "ls" 
> > 
> > commands after closing. In the log you can see, that the filesize changes 
> > after 
> > the garbage collection that is triggered (?) by the second ls.
> 
> That's not garbage-collection. That's just the inode in question being
> dropped from the icache, so it gets re-read. When we reread it, we build
> up the whole fragtree with all 4 KiB, then we see that the last log
> entry holds isize of 0x20a and we truncate...
> 
> 	<7>Truncating fraglist to 0x0000020a bytes
> 
> It looks like jffs2_fo_write() isn't actually _setting_ isize, and it
> should. I've committed a fix to my CVS tree which hopefully some kind
> soul (CC'd) will pick up and commit to the eCos tree too if you test it
> and report that it fixed the problem.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane