headers
David Woodhouse | 1 Dec 2007 10:28
Favicon

Re: dynamic mtd_blktrans_dev not fully init'd under UBI?

On Fri, 2007-11-30 at 14:58 -0600, catboat <at> texas.net wrote:
> In the newest git, I see a mutex named "lock" instead, but 
> I don't think it's initialized either. See the function 
> mtdblock_add_mtd() in drivers/mtd/mtdblock.c. The struct
> mtd_blktrans_dev is just kzalloc'd leaving the mutex lock
> all zeroes. 

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 74d9d30..839eed8 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
 <at>  <at>  -248,9 +248,9  <at>  <at>  int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
 		return -EBUSY;
 	}

-	mutex_init(&new->lock);
 	list_add_tail(&new->list, &tr->devs);
  added:
+	mutex_init(&new->lock);
 	if (!tr->writesect)
 		new->readonly = 1;

--

-- 
dwmw2

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 1 comment |
headers
catboat | 1 Dec 2007 18:00

Re: dynamic mtd_blktrans_dev not fully init'd under UBI?


Thanks David. 

Quoting David Woodhouse <dwmw2 <at> infradead.org>:

> On Fri, 2007-11-30 at 14:58 -0600, catboat <at> texas.net wrote:
> > In the newest git, I see a mutex named "lock" instead, but 
> > I don't think it's initialized either. See the function 
> > mtdblock_add_mtd() in drivers/mtd/mtdblock.c. The struct
> > mtd_blktrans_dev is just kzalloc'd leaving the mutex lock
> > all zeroes. 
> 
> diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> index 74d9d30..839eed8 100644
> --- a/drivers/mtd/mtd_blkdevs.c
> +++ b/drivers/mtd/mtd_blkdevs.c
>  <at>  <at>  -248,9 +248,9  <at>  <at>  int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
>  		return -EBUSY;
>  	}
>  
> -	mutex_init(&new->lock);
>  	list_add_tail(&new->list, &tr->devs);
>   added:
> +	mutex_init(&new->lock);
>  	if (!tr->writesect)
>  		new->readonly = 1;
>  
> 
> -- 
> dwmw2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 Dec 2007 21:14
Picon
Gravatar

[PATCH] Freezer: Fix JFFS2 garbage collector freezing issue (was: Re: JFFS2 garbage collection threads not freezing?)

On Friday, 30 of November 2007, Pete MacKay wrote:
> We've ported from 2.6.18 to 2.6.24-rc3 on a pxa270-based machine and can
> no longer enter 'standby' or 'mem' states.  I've stripped down the kernel
> and talked with the freezer maintainer and we believe the jffs2 garbage
> collection threads may not be calling try_to_freeze() or marking
> themselves properly.  (We have two mounted jffs2 file systems - mtd2 and
> mtd3).  The following is some cleaned-up output:
> 
> Freezing remaining freezable tasks ...
> Freezing of tasks failed after 20.00 seconds (2 tasks refusing to freeze):
>   task                PC stack   pid father
> init          D c0244b90     0     1      0
> kthreadd      S c0244b90     0     2      0
> ksoftirqd/0   S c0244b90     0     3      2
> events/0      S c0244b90     0     4      2
> khelper       S c0244b90     0     5      2
> kblockd/0     S c0244b90     0    51      2
> ksuspend_usbd D c0244b90     0    59      2
> khubd         D c0244b90     0    64      2
> kseriod       D c0244b90     0    67      2
> pdflush       D c0244b90     0    90      2
> pdflush       D c0244b90     0    91      2
> kswapd0       D c0244b90     0    92      2
> aio/0         S c0244b90     0    93      2
> mtdblockd     S c0244b90     0   192      2
> udevd         D c0244b90     0   619      1
> jffs2_gcd_mtd R running      0  1533      2
> jffs2_gcd_mtd R running      0  1598      2
> syslogd       D c0244b90     0  2248      1
> klogd         D c0244b90     0  2250      1
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kyungmin Park | 3 Dec 2007 05:33
Favicon

Re: [RFC][PATCH][JFFS2] JFFS2 support for NOP 1

On Nov 28, 2007 11:47 AM, Jörn Engel <joern <at> logfs.org> wrote:
> On Wed, 28 November 2007 11:08:30 +0900, Kyungmin Park wrote:
> >
> > sub-page: possible write size(?)
> > MTD usually write data with 'page size' (1KiB, 2KiB, and 4KiB) but
> > some upper layer such as UBI can write it with 'sub-page size (sector
> > size)'.
> >
> > Number Of Program (NOP): How many times flash can be programed.
> > In general SLC NAND has 4 but this value will be smaller as the
> > technology is advanced and MLC NAND has 1.
> >
> > The problem is that current JFFS2 implementation uses the NOP 2, data
> > area and oob area in NAND case. It breaks the NOP 1 limitation in MLC
> > case.
> >
> > If the description is wrong, please let me know.
>
> Sounds plausible.  And reading up on the subpage code I start to doubt
> its robustness wrt. newer SLC flashes as well.  If the NOP is lower than
> the number of ECC steps, trouble is brewing.
>
> But back to your original patch, you want JFFS2 to behave on MLC flashes
> just as it already behaves on Sibley and those dreaded STMicro NORs.
> And I claim that you should not only reach identical behaviour, but also
> share the same code.  There is no point in having two sets of "special"
> initializations with the exact same effect.
>
> Maybe add a flag MTD_OOB_WRITEABLE (or some better name) to SLC flashes
> and have the nand initializations in JFFS2 depend on those.  Without
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jörn Engel | 3 Dec 2007 16:20

Re: [PATCH] MTD: fix s3c2410 error correction

On Thu, 29 November 2007 11:10:41 -0800, Matt Reimer wrote:
> On Oct 18, 2007 5:02 PM, Matt Reimer <mattjreimer <at> gmail.com> wrote:
> > From: Matt Reimer <mreimer <at> vpop.net>
> >
> > The single-bit error correction was, well, incorrect. For determing which
> > bit to correct it was using P1' P2' P4' P8' instead of P1 P2 P4 P8, and
> > it was using P16' P32' P64' P128' P256' P512' P1024' P2048' instead of
> > P16 P32 P64 P128 P256 P512 P1024 P2048.
> 
> Is there any chance of this getting committed? It has been confirmed
> to be needed on s3c2440 and s3c2412.

Ok, I'm getting sick of this.  Even though I didn't fully review the
patch, I'll gladly take the chances of breaking something and
complaining to Matt afterwards.  Certainly beats ignoring this patch for
all eternity.

Acked-by: Joern Engel <joern <at> logfs.org>

Jörn

--

-- 
You ain't got no problem, Jules. I'm on the motherfucker. Go back in
there, chill them niggers out and wait for the Wolf, who should be
coming directly.
-- Marsellus Wallace

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 2 comments |
headers
massimo cirillo | 3 Dec 2007 17:34
Picon

[PATCH][CFI] Wrong cache invalidation bug fix

Hi,

We encountered the problem with cache invalidation in CFI driver. It
causes corruptions of data read from flash.

The problem is investigated. The original code performs cache
invalidation from "adr" to "adr + len" in do_write_buffer(). Since len
and adr could be updated in the code before invalidation - it causes
improper setting of cache invalidation regions.
The following patch fixes this problem. This patch has been verified
on our OMAP based platform.
Could you please acknowledge and commit this patch?

Thanks a lot.

Signed-off-by Massimo Cirillo <maxcir <at> gmail.com> and Giuseppe D'Eliseo
<giuseppedeliseo <at> gmail.com>

------

diff -aur a/drivers/mtd/chips/cfi_cmdset_0001.c
b/drivers/mtd/chips/cfi_cmdset_0001.c

--- a/drivers/mtd/chips/cfi_cmdset_0001.c	2007-11-20 20:15:02.000000000 +0300
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c	2007-11-29 19:42:08.000000000 +0300
 <at>  <at>  -1530,9 +1530,12  <at>  <at> 
 	int ret, wbufsize, word_gap, words;
 	const struct kvec *vec;
 	unsigned long vec_seek;
+	unsigned long initial_adr;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nicolas Pitre | 3 Dec 2007 18:12

Re: [PATCH][CFI] Wrong cache invalidation bug fix

On Mon, 3 Dec 2007, massimo cirillo wrote:

> Hi,
> 
> We encountered the problem with cache invalidation in CFI driver. It
> causes corruptions of data read from flash.
> 
> The problem is investigated. The original code performs cache
> invalidation from "adr" to "adr + len" in do_write_buffer(). Since len
> and adr could be updated in the code before invalidation - it causes
> improper setting of cache invalidation regions.
> The following patch fixes this problem. This patch has been verified
> on our OMAP based platform.
> Could you please acknowledge and commit this patch?
> 
> Thanks a lot.
> 
> Signed-off-by Massimo Cirillo <maxcir <at> gmail.com> and Giuseppe D'Eliseo
> <giuseppedeliseo <at> gmail.com>

This patch is correct.  However, to make it more obvious, please change 
the used variable in the XIP_INVAL_CACHED_RANGE() call used in the same 
function as well.

With that change you can add "Acked-by: Nicolas Pitre <nico <at> cam.org>".

Nicolas

______________________________________________________
Linux MTD discussion mailing list
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jörn Engel | 4 Dec 2007 01:08

Re: [PATCH][CFI] Wrong cache invalidation bug fix

On Mon, 3 December 2007 12:12:37 -0500, Nicolas Pitre wrote:
> 
> With that change you can add "Acked-by: Nicolas Pitre <nico <at> cam.org>".

Mine as well, if you feel so inclined.

Jörn

--

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Bartlomiej Sieka | 5 Dec 2007 00:17

Re: [PATCH][MTD] Fix incorrect interface code for x16/x32 chips

Bartlomiej Sieka wrote:
> According to "Common Flash Memory Interface Publication 100" dated December 1,
> 2001, the interface code for x16/x32 chips is 0x0005, and not 0x0004 used so
> far.
> 
> Signed-off-by: Bartlomiej Sieka <tur <at> semihalf.com>

I'd appreciate some feedback on the status of this patch.

Thanks in advance,
Bartlomiej

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 4 comments |
headers
Kyungmin Park | 5 Dec 2007 01:55

[RFC][PATCH][JFFS2] JFFS2 doesn't use OOB at MLC NAND/OneNAND

Hi,

It's the preparation patch for the MLC NAND/OneNAND flash.
The current jffs2 implementation at NAND case uses the NOP 2, cleanmarker and data each page 0. It breaks the
NOP 1 limitation in MLC flash.

With this patch, we don't write the cleanmarker at oob area.
I'm not sure it should use the cleanmarker at data area as NOR does.
Apart from the cleanmarker, there's serious POR issue, paired page at MLC.

The paired page problem is that if the some page is broken, the paired page is also broken even though it is
written correctly at previous time.
That's the reason the cleanmarker is not big issue at this time.

Now we support the NOP 1 and later we have to address this paired page issue. I'm not sure when this problem is addressed.

Any comments are welcome.

Thank you,
Kyungmin Park

Signed-off-by: Kyungmin Park <kyungmin.park <at> samsung.com>
---
diff --git a/fs/jffs2/erase.c b/fs/jffs2/erase.c
index a1db918..65d7dd7 100644
--- a/fs/jffs2/erase.c
+++ b/fs/jffs2/erase.c
 <at>  <at>  -415,6 +415,7  <at>  <at>  static void jffs2_mark_erased_block(struct jffs2_sb_info *c, struct jffs2_eraseb
 	/* Cleanmarker in oob area or no cleanmarker at all ? */
 	if (jffs2_cleanmarker_oob(c) || c->cleanmarker_size == 0) {
(Continue reading)

Permalink | Reply | 1 comment |

Gmane