[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS2 on NAND flash

Hi David,
Is there a fix in the source code about the erase_comletetion_lock you
mentioned ?


David Woodhouse <dwmw2@xxxxxxx.com on 01/31/2002 06:30:14 AM

Sent by:  owner-jffs-dev@xxxxxxx.com

To:   gleixner@xxxxxxx.de
cc:   jffs-dev@xxxxxxx.com

Subject:  Re: JFFS2 on NAND flash

( moved to jffs-dev list )

gleixner@xxxxxxx.de said:
> I know that and i was trying to put a workaround for the write cycle
> problem  into the nand driver. I think thats the correct location for
> this. Are there  other chips dealing with the same problem or is it
> related to NAND only ?

Some new ST chips have similar problems, I think. You can only write once
to any given 8-byte region before erasing it.

> My current solutiun would be: In nand.c the
> write functions checks the write attempts to a page. If there  were
> three writes already to this page, the function reads back the block
> data, erases the block and writes the block data back to the chip.

You can't do it like that. What if you lose power while the block is
but before you have written the data back again? You lose all the
information from the remainder of that erase block.

See http://mhonarc.axis.se/jffs-dev/msg01140.html

>  Is this also a problem for jffs1 ? I run jffs1 for a couple of weeks
> on my  board and had not one problem at all.

I think you get away with it on JFFS1. You don't have nodes small enough
that you'll fit ten of them in a page, and you can go for a couple of weeks

without the lack of ECC biting you.

gleixner@xxxxxxx.de said:
> > Also note that the locking in jffs2_garbage_collect_deletion_dirent()
> > is broken. We need to lock the erase_completion_lock while we go
> > the list, and drop the lock when we read the nodes.

> I'm not deep enough inside this to see the neccecary change. Could you
> please  explain more detailed ?

On completion of a block erase, we walk through all the node lists, and we
remove and free all nodes in the block which has just been erased. Anything

which walks the node lists (as this function does) must hold the
erase_completion_lock, so that the erase can't happen simultaneously.

So we must hold the erase_completion_lock while walking the lists, and
because it's a spinlock we must unlock it before calling the flash read
function. Then when we get it again the node we were looking at and the
next node in the list may both have gone and been freed - we have to start
again from the beginning.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com