[PATCH] JFFS2 appears to "freeze" during erase, version 2

[Joakim Tjernlund]

On Mon, 2007-06-11 at 10:34 +0200, Joakim Tjernlund wrote:
> On Tue, 2007-06-05 at 09:51 +0200, Joakim Tjernlund wrote:
> > Here is an updated version that contains all everything in one patch. I hope
> > this one can be applied as is.
> > 
> >  Jocke
> > 
> > >From 87cd93db5895e1506a6abb0dbc891587e96d8547 Mon Sep 17 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> > Date: Tue, 5 Jun 2007 09:38:53 +0200
> > Subject: [PATCH] JFFS2 appears to "freeze" during erase
> > Radoslaw Bisewski <radbis at googlemail.com> writes:
> > With current desing erase_free_sem is locked every time the flash
> > block is being erased. For NOR flashes - ~1 second is needed to erase
> > single flash block. In the worst case scenario erase_free_sem may be
> > locked for a couple of seconds when the number of blocks is being
> > erased (e.g. after large file was removed). When erase_free_sem is
> > locked all read/write operations for given JFFS2 partition are locked
> > too - in effect from time to time access to the JFFS2 partition is
> > locked for a number of seconds. This fix makes critical section in
> > flash erasing procedure shorter - now erase_free_sem is locked around
> > erase_completion_lock spinlock only.
> > 
> > Additional bug fixes by me.
> > 
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> > ---
> [SNIP patch]
> 
> After running our boards a few days with the above patch we have seen
> a new hang during SW upgrade of the board.
> 
> A simple script that is run to do some validation of the new SW
> sometimes takes about 2 minutes to complete instead of 1 second.
> 
> FS I/O  part of that script is:
>   BOARD=`fw_printenv genBoardType | sed 's/^.*=//' | sed 's/^cu.*/cu/'`
>   TMP_FILE=/tmp/.swu_operations.log
>   echo "Some text 1" >> $TMP_FILE
>   echo "Some text 2" >> $TMP_FILE
>   echo `date` >> $TMP_FILE
>   echo "Some text 3" >> $TMP_FILE
> 
> fw_printenv is an utility that accesses(reads) the u-boots environment
> via /dev/mtd.
> /tmp is mounted as a tmpfs:
> none            /tmp            tmpfs   defaults                        0 0
> 
> This is on 2.6.20 with cfi_cmdset_0001 driver
> 
> Any ideas what is going on is most welcome.
> 
>  Jocke

looking into the /dev/mtd driver, mtdchar.c I wonder about something in
mtd_close:
	if (mtd->sync)
		mtd->sync(mtd);

Should the mtd->sync call be here? I think this might be the cause
for the long stalls we see from time to time. If an long erase is on
going, this calls won't return until all sectors are erased, me thinks.

 Jocke