* Re: [PATCH] MTD: m25p80: fix printk format warning
From: Andrew Morton @ 2006-03-28 0:20 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linux-mtd, dwmw2, linux-kernel
In-Reply-To: <20060327161402.06eaa84b.rdunlap@xenotime.net>
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> Fix printk format warning:
> drivers/mtd/devices/m25p80.c:189: warning: format '%zd' expects type 'signed size_t', but argument 6 has type 'u_int32_t'
Thanks, this is already fixed in one of the oft-sent, oft-ignored MTD
patches in -mm.
^ permalink raw reply
* [PATCH] MTD: m25p80: fix printk format warning
From: Randy.Dunlap @ 2006-03-28 0:14 UTC (permalink / raw)
To: dwmw2, akpm; +Cc: linux-mtd, lkml
From: Randy Dunlap <rdunlap@xenotime.net>
Fix printk format warning:
drivers/mtd/devices/m25p80.c:189: warning: format '%zd' expects type 'signed size_t', but argument 6 has type 'u_int32_t'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/mtd/devices/m25p80.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2616-g13.orig/drivers/mtd/devices/m25p80.c
+++ linux-2616-g13/drivers/mtd/devices/m25p80.c
@@ -186,7 +186,7 @@ static int m25p80_erase(struct mtd_info
struct m25p *flash = mtd_to_m25p(mtd);
u32 addr,len;
- DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
+ DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %d\n",
flash->spi->dev.bus_id, __FUNCTION__, "at",
(u32)instr->addr, instr->len);
---
^ permalink raw reply
* RE: jffs2 fs overload
From: igor.trevisan @ 2006-03-27 17:38 UTC (permalink / raw)
To: Selmeci, Tamas; +Cc: linux-mtd
In-Reply-To: <38F58D7B92CB20438DF49D28B572CC6F23BBED@budgw09a.ww300.siemens.net>
Hi Tamas,
thanks for your answer.
Just another one: is it possible to have a single RFS that 's mounted
read/write?
Is it enough to specify r/w on the mtdparts section of the command
line? (I'm using that way to define flash partitions).
In this way I could have three partitions: bootloader, kernel and RFS
with the rfs mounted rewritable but with the files that cannot be
changed that don't have write permission.
In this way I could avoid the overload due to having two small partitions
each one with its JFFS2 tables and structures and so on.
Is it right?
Any suggestion and comment is obviously welcome!
Thanks in advance,
Igor.
On 20 Mar 2006 at 9:30, Selmeci, Tamas wrote:
> Hello!
>
> > I'm defining the flash partitions content for my target
> > and I need a rewritable flash area.
> > So I formatted and mounted a flash partition as jffs2.
> > What I noted is that, on a 1MByte flash area I loose
> > about 600K immediately. If I use the command df I see
> > that only 30less than 400k are really available.
> > Is it possible that this is the normal overload if a
> > format my flash partition with jffs2?
> > Or am I doing something wtong?
>
> I think this is normal, JFFS2 allocates inodes (as far as I know) in
> advance like ext2 also does - in case of a very small filesystem, this
> may lead to serious capacity waste... If my assumption is wrong,
> somebody please correct me.
>
> > Is there any good guide or document that can help me
> > building a jffs2 RW flash partition?
>
> I would make a filesystem on a host PC, and then make a jffs2 from it
> (mkjffs). The image can be written with a download tool.
>
> Bye
> --
> Tamas Selmeci
>
>
--
--- BlueWind
--- Embedded Systems Design
--- Borgo Pieve 55c interno c
--- 31033 Castelfranco V.to (TV)
--- Tel.: +39 0423 723431 Fax.: +39 0423 744738
--- mailto: igor.trevisan@bluewind.it
--- http://www.bluewind.it
------------------------------------------------------------------
^ permalink raw reply
* RE: jffs2 fs overload
From: igor.trevisan @ 2006-03-27 17:37 UTC (permalink / raw)
To: Selmeci, Tamas; +Cc: linux-mtd
In-Reply-To: <38F58D7B92CB20438DF49D28B572CC6F23BBED@budgw09a.ww300.siemens.net>
Hi Tamas,
thanks for your answer.
Just another one: is it possible to have a single RFS that 's mounted
read/write?
Is it enough to specify r/w on the mtdparts secton of the command
line? (I'm using that way to define flash partition).
In this way I could have three partition: bootloader, kernel and RFS
with the rfs mounted rewritable but with the files that cannot be
changed that don't have write permission.
In this way I could avoid the overload due to having two small partition
each with its JFFS2 tables and structures and so on.
Is it right?
Any suggestion and comment is obviously welcome!
Thanks in advance,
Igor.
On 20 Mar 2006 at 9:30, Selmeci, Tamas wrote:
> Hello!
>
> > I'm defining the flash partitions content for my target
> > and I need a rewritable flash area.
> > So I formatted and mounted a flash partition as jffs2.
> > What I noted is that, on a 1MByte flash area I loose
> > about 600K immediately. If I use the command df I see
> > that only 30less than 400k are really available.
> > Is it possible that this is the normal overload if a
> > format my flash partition with jffs2?
> > Or am I doing something wtong?
>
> I think this is normal, JFFS2 allocates inodes (as far as I know) in
> advance like ext2 also does - in case of a very small filesystem, this
> may lead to serious capacity waste... If my assumption is wrong,
> somebody please correct me.
>
> > Is there any good guide or document that can help me
> > building a jffs2 RW flash partition?
>
> I would make a filesystem on a host PC, and then make a jffs2 from it
> (mkjffs). The image can be written with a download tool.
>
> Bye
> --
> Tamas Selmeci
>
>
--
--- BlueWind
--- Embedded Systems Design
--- Borgo Pieve 55c interno c
--- 31033 Castelfranco V.to (TV)
--- Tel.: +39 0423 723431 Fax.: +39 0423 744738
--- mailto: igor.trevisan@bluewind.it
--- http://www.bluewind.it
------------------------------------------------------------------
^ permalink raw reply
* Re: getting an older mkfs.jffs2
From: Josh Boyer @ 2006-03-27 14:50 UTC (permalink / raw)
To: Benjamin Sapp; +Cc: linux-mtd
In-Reply-To: <200603271446.k2REkMG3017802@godiva.ta-18.lanl.gov>
On 3/27/06, Benjamin Sapp <bsapp@lanl.gov> wrote:
> Hello,
>
> I have version 1.38 of mkfs.jffs2 on a RedHat 7 machine and it works
> perfectly. I have version 1.47 on a Fedora Core 4 machine and it does not
> work. I'd like a working version on the Fedora machine. However, copying
What doesn't work about it?
josh
^ permalink raw reply
* Re: getting an older mkfs.jffs2
From: Benjamin Sapp @ 2006-03-27 15:00 UTC (permalink / raw)
To: Josh Boyer, Benjamin Sapp; +Cc: linux-mtd
In-Reply-To: <625fc13d0603270650g1139d010me8d98fe8c1569f26@mail.gmail.co m>
I'm using it on intel to create an image for Freescale's i.MX21 arm
processor. I'm not exactly sure what is wrong. I don't even see any
warnings. All I know is when I use version 1.47 to create the ramdisk
Linux never boots. I'm using version 2.4.20 of the kernel. That's an
older kernel so I imagine there's just some sort of incompatibility.
7:50 AM 3/27/2006, Josh Boyer wrote:
>On 3/27/06, Benjamin Sapp <bsapp@lanl.gov> wrote:
> > Hello,
> >
> > I have version 1.38 of mkfs.jffs2 on a RedHat 7 machine and it works
> > perfectly. I have version 1.47 on a Fedora Core 4 machine and it does not
> > work. I'd like a working version on the Fedora machine. However, copying
>
>What doesn't work about it?
>
>josh
^ permalink raw reply
* getting an older mkfs.jffs2
From: Benjamin Sapp @ 2006-03-27 14:42 UTC (permalink / raw)
To: linux-mtd
Hello,
I have version 1.38 of mkfs.jffs2 on a RedHat 7 machine and it works
perfectly. I have version 1.47 on a Fedora Core 4 machine and it does not
work. I'd like a working version on the Fedora machine. However, copying
the binary over did not work because of library incompatibilities. Do you
know where I can find the source code that would correspond to mkfs.jffs2
version 1.38? Is there a command that would allow me to get it from the
CVS?
Thanks for any help,
Ben.
^ permalink raw reply
* Re: [2.6 patch] drivers/mtd/mtdcore.c: less PROC_FS=n #ifdef's
From: Pavel Machek @ 2006-03-27 9:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, linux-mtd, Thomas Gleixner, David Woodhouse,
linux-kernel
In-Reply-To: <20060326122504.GI4053@stusta.de>
On Ne 26-03-06 14:25:04, Adrian Bunk wrote:
> I'm surprised that kill-ifdefs-in-mtdcorec.patch in -mm that removes
> #ifdef's for the PROC_FS=n case wasn't tested with PROC_FS=n...
Sorry for that, I somehow assumed it was trivial and did not test it
properly.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
^ permalink raw reply
* [2.6 patch] drivers_mtd_maps_vmax301.c: fix off by one vmax_mtd
From: Adrian Bunk @ 2006-03-26 17:05 UTC (permalink / raw)
To: dwmw2; +Cc: Petri T. Koistinen, linux-mtd, linux-kernel
From: "Petri T. Koistinen" <petri.koistinen@iki.fi>
This patch fixes an obcious off-by-one error (vmax_mtd[] contains
two elements).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.14-rc3-git3/drivers/mtd/maps/vmax301.c 2005-05-25 13:48:53.000000000 +1000
+++ .6877.trivial/drivers/mtd/maps/vmax301.c 2005-10-04 19:29:50.000000000 +1000
@@ -182,7 +182,7 @@ int __init init_vmax301(void)
}
}
- if (!vmax_mtd[1] && !vmax_mtd[2]) {
+ if (!vmax_mtd[0] && !vmax_mtd[1]) {
iounmap((void *)iomapadr);
return -ENXIO;
}
^ permalink raw reply
* [2.6 patch] drivers/mtd/mtdcore.c: less PROC_FS=n #ifdef's
From: Adrian Bunk @ 2006-03-26 12:25 UTC (permalink / raw)
To: Andrew Morton, Pavel Machek
Cc: linux-mtd, Thomas Gleixner, David Woodhouse, linux-kernel
I'm surprised that kill-ifdefs-in-mtdcorec.patch in -mm that removes
#ifdef's for the PROC_FS=n case wasn't tested with PROC_FS=n...
<-- snip -->
...
CC drivers/mtd/mtdcore.o
drivers/mtd/mtdcore.c: In function 'init_mtd':
drivers/mtd/mtdcore.c:352: error: 'proc_mtd' undeclared (first use in this function)
drivers/mtd/mtdcore.c:352: error: (Each undeclared identifier is reported only once
drivers/mtd/mtdcore.c:352: error: for each function it appears in.)
drivers/mtd/mtdcore.c:353: error: 'mtd_read_proc' undeclared (first use in this function)
drivers/mtd/mtdcore.c: In function 'cleanup_mtd':
drivers/mtd/mtdcore.c:359: error: 'proc_mtd' undeclared (first use in this function)
make[2]: *** [drivers/mtd/mtdcore.o] Error 1
<-- snip -->
The patch below tries to do it in a correct way.
cu
Adrian
<-- snip -->
This patch reduces the number of #ifdef's for CONFIG_PROC_FS=n.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/mtd/mtdcore.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
--- linux-2.6.16-mm1-full/drivers/mtd/mtdcore.c.old 2006-03-25 23:22:06.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/mtd/mtdcore.c 2006-03-25 23:23:03.000000000 +0100
@@ -19,9 +19,7 @@
#include <linux/ioctl.h>
#include <linux/init.h>
#include <linux/mtd/compatmac.h>
-#ifdef CONFIG_PROC_FS
#include <linux/proc_fs.h>
-#endif
#include <linux/mtd/mtd.h>
@@ -296,10 +294,11 @@
EXPORT_SYMBOL(default_mtd_writev);
EXPORT_SYMBOL(default_mtd_readv);
+#ifdef CONFIG_PROC_FS
+
/*====================================================================*/
/* Support for /proc/mtd */
-#ifdef CONFIG_PROC_FS
static struct proc_dir_entry *proc_mtd;
static inline int mtd_proc_info (char *buf, int i)
@@ -344,31 +343,27 @@
return ((count < begin+len-off) ? count : begin+len-off);
}
-#endif /* CONFIG_PROC_FS */
-
/*====================================================================*/
/* Init code */
static int __init init_mtd(void)
{
-#ifdef CONFIG_PROC_FS
if ((proc_mtd = create_proc_entry( "mtd", 0, NULL )))
proc_mtd->read_proc = mtd_read_proc;
-#endif
return 0;
}
static void __exit cleanup_mtd(void)
{
-#ifdef CONFIG_PROC_FS
if (proc_mtd)
remove_proc_entry( "mtd", NULL);
-#endif
}
module_init(init_mtd);
module_exit(cleanup_mtd);
+#endif /* CONFIG_PROC_FS */
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
^ permalink raw reply
* Re: JFFS2 & NAND problem.
From: Artem B. Bityutskiy @ 2006-03-25 9:11 UTC (permalink / raw)
To: Han Chang; +Cc: linux-mtd
In-Reply-To: <BAY101-F7B62563E26F6D6318B633BCDF0@phx.gbl>
On Fri, 2006-03-24 at 10:44 -0800, Han Chang wrote:
> jffs2_get_inode_nodes(): CRC failed on node at 0x0005efd0: Read 0xffffffff,
> calc
> ulated 0x6791a538
I would suggest you to dig your drivers - do they function well?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply
* JFFS2 & NAND problem.
From: Han Chang @ 2006-03-24 18:44 UTC (permalink / raw)
To: linux-mtd
Hello,
I'm trying to get JFFS2 working on a NAND flash device. I'm having two
problems. They might be related.
1) Once I mount the JFFS2 to the device, I am able to create directory and
copy files into there. If I compare the files in the JFFS2 directory with
the original files. They are exactly match. Even if I do a "sync", and
compare them again, and they still match. But once I reboot the system and
compare the files in the JFFS2 directory with the original files, then they
are not matched any more. Anyone have seen this kind of behavior?
2) One thing I noticed when I mount the JFFS2 to the devive, there are bunch
of following CRC msgs dumped out. I have done other test on the NAND flash
and it's in good condition. I'm puzzled with these "CRC failed" msgs.
jffs2_get_inode_nodes(): CRC failed on node at 0x0005efd0: Read 0xffffffff,
calc
ulated 0x6791a538
jffs2_get_inode_nodes(): CRC failed on node at 0x0005e7d8: Read 0xffffffff,
calc
ulated 0x81c6885d
jffs2_get_inode_nodes(): CRC failed on node at 0x0004bff8: Read 0xffffffff,
calc
ulated 0xcfd1b4d3
jffs2_get_inode_nodes(): CRC failed on node at 0x00040fd4: Read 0xffffffff,
calc
ulated 0x596a66c5
jffs2_get_inode_nodes(): CRC failed on node at 0x0002d7e0: Read 0xffffffff,
calc
ulated 0xb6f7ff0d
jffs2_get_inode_nodes(): CRC failed on node at 0x00028fcc: Read 0xffffffff,
calc
ulated 0x78990f70
jffs2_get_inode_nodes(): CRC failed on node at 0x0001efcc: Read 0xffffffff,
calc
ulated 0x30a35bd1
jffs2_get_inode_nodes(): CRC failed on node at 0x0001dfe4: Read 0xffffffff,
calc
ulated 0x4f77e039
I appreciate any help!!!
Han
^ permalink raw reply
* 2.6.16 compile error with latest cvs mtd source
From: Mirco Fuchs @ 2006-03-24 7:16 UTC (permalink / raw)
To: linux-mtd
Thanks for your fast reply.
>> Hello,
>>>
>> i have a problem compiling the 2.6.16 kernel for my csb637 board. I think this
>> is an mtd related question because it works without patching the kernel
>> against the mtd source code.
>>
>> I have gcc 3.4.4 and binutils 2.16 and glibx 2.3.5.
>>
>> The first step was compiling the 2.6.16 kernel without patching against the
>> mtd cvs sources. --> The compilation was successfull.
>>
>> But patching the kernel against the head of the mtd cvs repo resulted in the
>> following warnings and errors:
>>
>> (I used the command 'patchkernel.sh -2cyv $KERNELDIR' for patching)
>Did you enable CONFIG_OBSOLETE_INTERMODULE in your .config? That was
>added in the 2.6.16 kernel because the inter_module stuff should
>really go away sometime.
>Alternatively, the MTD subsystem should also probably select that
>Kconfig option so users don't see this. But MTD needs a sync anyway.
I do not find CONFIG_OBSOLETE_INTERMODULE in my .config file, is there a
patch concering this?
Mirco
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
^ permalink raw reply
* jffs2 BUG() on mount
From: Ladislav Michl @ 2006-03-23 18:25 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <20060322194939.GA10058@orphique>
On Wed, Mar 22, 2006 at 08:49:39PM +0100, Ladislav Michl wrote:
> With more debugs enabled it ends like this:
> Skipping ino #228 already checked
> Skipping ino #229 already checked
> Skipping ino #270 already checked
> Skipping check of ino #273 with nlink zero
> [lots of skipping check of ino #xxx with nlink zero]
> Skipping check of ino #800 with nlink zero
> Skipping check of ino #801 with nlink zero
> Skipping ino #802 already checked
> Skipping check of ino #803 with nlink zero
> Checked all inodes but still 0x13364c bytes of unchecked space?
>
> Where checked_ino is 804 and highest_ino 803. ino 802 is already checked
> because userspace requested read meanwhile.
jffs2_scan_inode_node adds also inodes with zero nlink to
unchecked_space, but jffs2_garbage_collect_pass skips them. That
probably leads to above problem. After applying following patch
BUG() is no longer triggered.
Index: fs/jffs2/gc.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/gc.c,v
retrieving revision 1.159
diff -u -r1.159 gc.c
--- fs/jffs2/gc.c 18 Nov 2005 07:27:45 -0000 1.159
+++ fs/jffs2/gc.c 23 Mar 2006 17:39:00 -0000
@@ -211,12 +211,6 @@
continue;
}
- if (!ic->nlink) {
- D1(printk(KERN_DEBUG "Skipping check of ino #%d with nlink zero\n",
- ic->ino));
- spin_unlock(&c->inocache_lock);
- continue;
- }
switch(ic->state) {
case INO_STATE_CHECKEDABSENT:
case INO_STATE_PRESENT:
I'm not sure what is correct solution. With this change there are lots of
JFFS2 warning: (138) jffs2_get_inode_nodes: Eep. No valid nodes for ino #465.
JFFS2 warning: (138) jffs2_do_read_inode_internal: no data nodes found for ino #465
Returned error for crccheck of ino #465. Expect badness...
warnings. Jffs2 summary feature is disabled. I'd be very gratefull for ideas.
ladis
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Alexander Belyakov @ 2006-03-23 14:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <Pine.LNX.4.64.0603230920030.3631@localhost.localdomain>
Nicolas Pitre wrote:
> You should split your patch into pieces: mtdstrip core in one patch, and
> driver modifications in their own separate patch for each of them. But
> please post the whole serie.
>
>
> Nicolas
Sounds reasonable.
I'll split my patch in three parts, make some changes in striping core
we have already spoken about, and then post again starting three
separate threads cross referencing to each other.
Thank you,
Alexander Belyakov
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Nicolas Pitre @ 2006-03-23 14:23 UTC (permalink / raw)
To: Alexander Belyakov; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <44226CEB.70200@intel.com>
On Thu, 23 Mar 2006, Alexander Belyakov wrote:
> My question is: shall I post new reduced (mtdstripe core only) patch here
> leaving all the rest for future discussion?
You should split your patch into pieces: mtdstrip core in one patch, and
driver modifications in their own separate patch for each of them. But
please post the whole serie.
Nicolas
^ permalink raw reply
* Re: 2.6.16 compile error with latest cvs mtd source
From: Josh Boyer @ 2006-03-23 13:10 UTC (permalink / raw)
To: Mirco Fuchs; +Cc: linux-mtd
In-Reply-To: <457792036@web.de>
On 3/23/06, Mirco Fuchs <mircofuchs@web.de> wrote:
> Hello,
>
> i have a problem compiling the 2.6.16 kernel for my csb637 board. I think this
> is an mtd related question because it works without patching the kernel
> against the mtd source code.
>
> I have gcc 3.4.4 and binutils 2.16 and glibx 2.3.5.
>
> The first step was compiling the 2.6.16 kernel without patching against the
> mtd cvs sources. --> The compilation was successfull.
>
> But patching the kernel against the head of the mtd cvs repo resulted in the
> following warnings and errors:
>
> (I used the command 'patchkernel.sh -2cyv $KERNELDIR' for patching)
Did you enable CONFIG_OBSOLETE_INTERMODULE in your .config? That was
added in the 2.6.16 kernel because the inter_module stuff should
really go away sometime.
Alternatively, the MTD subsystem should also probably select that
Kconfig option so users don't see this. But MTD needs a sync anyway.
josh
^ permalink raw reply
* 2.6.16 compile error with latest cvs mtd source
From: Mirco Fuchs @ 2006-03-23 12:02 UTC (permalink / raw)
To: linux-mtd
Hello,
i have a problem compiling the 2.6.16 kernel for my csb637 board. I think this
is an mtd related question because it works without patching the kernel
against the mtd source code.
I have gcc 3.4.4 and binutils 2.16 and glibx 2.3.5.
The first step was compiling the 2.6.16 kernel without patching against the
mtd cvs sources. --> The compilation was successfull.
But patching the kernel against the head of the mtd cvs repo resulted in the
following warnings and errors:
(I used the command 'patchkernel.sh -2cyv $KERNELDIR' for patching)
...
CC drivers/mtd/mtdcore.o
CC drivers/mtd/mtdpart.o
CC drivers/mtd/mtdconcat.o
CC drivers/mtd/cmdlinepart.o
CC drivers/mtd/mtdchar.o
CC drivers/mtd/mtdblock.o
CC drivers/mtd/mtd_blkdevs.o
CC drivers/mtd/chips/chipreg.o
CC drivers/mtd/chips/cfi_probe.o
CC drivers/mtd/chips/cfi_util.o
CC drivers/mtd/chips/cfi_cmdset_0020.o
drivers/mtd/chips/cfi_cmdset_0020.c: In function `cfi_staa_init':
drivers/mtd/chips/cfi_cmdset_0020.c:1417: Warnung: »inter_module_register« ist veraltet (deklariert bei
include/linux/module.h:571)
drivers/mtd/chips/cfi_cmdset_0020.c: In function `cfi_staa_exit':
drivers/mtd/chips/cfi_cmdset_0020.c:1423: Warnung: »inter_module_unregister« ist veraltet (deklariert bei
include/linux/module.h:572)
CC drivers/mtd/chips/cfi_cmdset_0001.o
drivers/mtd/chips/cfi_cmdset_0001.c: In function `cfi_intelext_init':
drivers/mtd/chips/cfi_cmdset_0001.c:2458: Warnung: »inter_module_register« ist veraltet (deklariert bei
include/linux/module.h:571)
drivers/mtd/chips/cfi_cmdset_0001.c:2459: Warnung: »inter_module_register« ist veraltet (deklariert bei
include/linux/module.h:571)
drivers/mtd/chips/cfi_cmdset_0001.c:2460: Warnung: »inter_module_register« ist veraltet (deklariert bei
include/linux/module.h:571)
drivers/mtd/chips/cfi_cmdset_0001.c: In function `cfi_intelext_exit':
drivers/mtd/chips/cfi_cmdset_0001.c:2466: Warnung: »inter_module_unregister« ist veraltet (deklariert bei
include/linux/module.h:572)
drivers/mtd/chips/cfi_cmdset_0001.c:2467: Warnung: »inter_module_unregister« ist veraltet (deklariert bei
include/linux/module.h:572)
drivers/mtd/chips/cfi_cmdset_0001.c:2468: Warnung: »inter_module_unregister« ist veraltet (deklariert bei
include/linux/module.h:572)
CC drivers/mtd/chips/gen_probe.o
drivers/mtd/chips/gen_probe.c: In function `cfi_cmdset_unknown':
drivers/mtd/chips/gen_probe.c:210: Warnung: »inter_module_put« ist veraltet (deklariert bei
include/linux/module.h:575)
LD drivers/mtd/chips/built-in.o
LD drivers/mtd/devices/built-in.o
CC drivers/mtd/maps/physmap.o
LD drivers/mtd/maps/built-in.o
LD drivers/mtd/nand/built-in.o
LD drivers/mtd/onenand/built-in.o
LD drivers/mtd/built-in.o
...
CC lib/kref.o
CC lib/prio_tree.o
CC lib/radix-tree.o
CC lib/rbtree.o
CC lib/rwsem-spinlock.o
CC lib/sha1.o
CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `cfi_cmdset_unknown':
drivers/mtd/chips/gen_probe.c:203: undefined reference to `inter_module_get_request'
drivers/mtd/chips/gen_probe.c:210: undefined reference to `inter_module_put'
drivers/built-in.o: In function `cfi_staa_init':
drivers/mtd/chips/cfi_cmdset_0020.c:1417: undefined reference to `inter_module_register'
drivers/built-in.o: In function `cfi_intelext_init':
drivers/mtd/chips/cfi_cmdset_0001.c:2458: undefined reference to `inter_module_register'
drivers/mtd/chips/cfi_cmdset_0001.c:2459: undefined reference to `inter_module_register'
drivers/mtd/chips/cfi_cmdset_0001.c:2460: undefined reference to `inter_module_register'
make: *** [.tmp_vmlinux1] Fehler 1
Are there any suggestions?
Note: I patched the 2.6.15 kernel against the head of the mtd cvs repo which
resulted in a successfully compilation.
regards
Mirco
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Vitaly Wool @ 2006-03-23 10:10 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Alexander Belyakov, linux-mtd, Kutergin, Timofey, Korolev, Alexey
In-Reply-To: <Pine.LNX.4.64.0603221428480.3631@localhost.localdomain>
Nicolas Pitre wrote:
>>Let's look at it at the following angle. Striping is a nice concept, as well
>>as many other nice concepts that exist in the world. Are they all worth being
>>impemented in Linux MTD subsystem? :)
>>
>>
>
>Why not, if you can configure it out.
>
>
Well, the thing is it's getting more and more complicated and harder to
support...
>
>
>>OTOH, what is the rationale? Make devices operate faster. Okay, why can't this
>>be implemented as mtdconcat optimization?
>>
>>
>
>mtdconcat provides linear access to subdevices.
>
>The stripe module provides _interleaved_ access to subdevices.
>
>That is the fundamental difference.
>
>
Let's make a config option to mtdconcat switching between
interleaved/linear access. Why not?
>
>
>>What I'd also like to say is that having a lot of threads doesn't look
>>attractive to me.
>>
>>
>
>What is the problem with threads? The kernel already uses them heavily
>for many purposes because it makes things cleaner.
>
>
More threads = more overhead, more context switching, more possibilities
to decrease the system performance (wrong prio choice, prio inversion
etc.).
Adding, say, 5 more threads (which doesn't look impossible wrt to this
implementation) doesn't look good.
>
>
>>I'd rather go in for changing the whole MTD subsystem to
>>make the API asynchoronus, and then you won't need many threads. But this is a
>>rather dramatic change...
>>
>>
>
>But do you realize that any asynchronous implementation will _still_
>require kernel threads of its own to do the work anyway? That's the
>reason why there is so many kernel threads running in your kernel
>already.
>
>
Yes, but not necessarily so many of. I can even think of the following
implementation (roughly):
- erase: issue a command to erase the block from 1st chip, issue command
to erase the block from 2nd chip, wait on counting semaphore;
(this is happening in caller context)
- hrm, 2 callbacks on erase completion, increasing the semaphore counter
(1 thread needed)
Vitaly
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Alexander Belyakov @ 2006-03-23 9:39 UTC (permalink / raw)
To: dedekind; +Cc: Korolev, Alexey, linux-mtd, Kutergin, Timofey
In-Reply-To: <1143047296.29683.44.camel@sauron.oktetlabs.ru>
Artem B. Bityutskiy wrote:
> 15 files changed, 4144 insertions(+), 33 deletions(-), 2
> modifications(!)
>
> You definitely have to split your patch on several parts. Your patch has
> to only affect drivers/mtd/mtdstripe.c and include/linux/mtd/stripe.h.
> If you have to modify other subsystem, send the modification separately,
> motivate them and let the corresponding janitor to review them.
Yes I realize that patch is quite large and might be difficult to
understand. You are right here.
Striping core (including initialization calls) is contained by the
following files:
drivers/mtd/mtdstripe.c
include/linux/mtd/stripe.h
drivers/mtd/maps/mphysmap.c
drivers/mtd/Kconfig
drivers/mtd/Makefile
Applying only these files one will get interleaving functional. But will not get performance increase. I shall make some explanations on that in this message.
So in order to simplify process I suggest to forget about all changes except those 5 files mentioned above. Shall I post new reduced diff file, containing mtdstripe core only?
Now on performance issue. I shall provide an example.
Say we have 2 physically independent flash devices (striping layer has 2 worker threads) with interleaving size of 128 bytes. Write operation with 1024 bytes of data is issued. Interleaving algorithm splits data in 8 chunks and pushes them into worker thread queues. Fist chip queue get chunk 1, chunk 3, chunk 5 and chunk 7. Second chip queue get chunk 2, chunk 4, chunk 6 and chunk 8. At this point both worker threads have the same priority equal (in simple case) to priority of the caller thread. Write to flashes begins here.
Worker thread 1 puts chunk 1 to flash 1 buffer and get free time flushing data to flash. At that free time worker thread 2 should get control and write chunk 2 to flash 2. But it won't despite worker thread 1 invokes rescheduling. Since switching between two thread with equal priority has some uncertainty. And data chunks will be written in the following order:
chunk 1
chunk 3
chunk 5
chunk 7
chunk 2
chunk 4
chunk 6
chunk 8
instead of expected:
chunk 1 chunk 2
chunk 3 chunk 4
chunk 5 chunk 6
chunk 7 chunk 8
It is obvious that one will not get any performance increase in the first case.
That is not only striping problem, but also a problem of several instances of file system mounted on different flashes. These filesystems also will not work simultaneously.
So mtdstripe itself is not enough to get performance increase. Additional solution needed. And two of possible solutions presented in the original diff file.
Now as my worries explained I'd suggest to push these thread switching issues into the background and continue with mtdstripe core only.
My question is: shall I post new reduced (mtdstripe core only) patch here leaving all the rest for future discussion?
Thanks,
Alexander Belyakov
^ permalink raw reply
* Support for TrueFFS & SmartMedia DOS FAT
From: Chinmay Kale @ 2006-03-23 9:22 UTC (permalink / raw)
To: linux-mtd
Hi,
Do TrueFFS & SmartMedai DOS FAT support the linux MTD architecture ?
Please guide me in this regard.
Thanx
Chinmay
^ permalink raw reply
* Re: Re: cfi 0001
From: Tomas @ 2006-03-22 22:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-mtd
In-Reply-To: <Pine.LNX.4.64.0603211056190.3631@localhost.localdomain>
Hi,
I used a web client due to some mail problem, seem to mess up.
Nicolas Pitre <nico@cam.org> skrev den Tue, 21 Mar 2006 11:08:18 -0500
(EST):
> On Tue, 21 Mar 2006, Tomas E wrote:
>
>> Hi,
>>
>> >> Nicolas Pitre <nico@cam.org> skrev den Mon, 20 Mar 2006 11:08:19
>> -0500 (EST):
>> >> Hi,
>> >>
>> >> > On Mon, 20 Mar 2006, Tomas E wrote:
>> >> >
>> >> > > Hi,
>> >> > >
>> >> > > I have a problem with writing to a Intel Strata flash
>> >> > > and then doing a warm reset.
>> >> >
>> >> > How do you "warm reset" ?
>> >>
>> >> I use the at91rm9200 built in watchdog on a custom board, which is
>> very
>> >> convient but there is no external pin from the watchdog to make the
>> >> a reset of the flash.
>> >
>> >You mean from include/asm-arm/arch-at91rm9200/system.h:
>> >
>> >static inline void arch_reset(char mode)
>> >{
>> > /*
>> > * Perform a hardware reset with the use of the Watchdog timer.
>> > */
>> > at91_sys_write(AT91_ST_WDMR, AT91_ST_RSTEN | AT91_ST_EXTEN |
>> 1);
>> > at91_sys_write(AT91_ST_CR, AT91_ST_WDRST);
>> >}
The above works fine with the latest snapshot.
My problem is as you and others pointed out that I got a cold reset
on the chip but not on the flash. I will put a working watchdog
on the wich list.
>>
>> Sorry if my explaination was poor but no. I run my test case
>> which is to kill the watchdog deamon which will cause the watchdog
>> to expire. I checked that this code will never be executed in my case.
>
> The only answer I have for you then is to not rely on the watchdog at
> all since it cannot guarantee a reliable system recovery anyway. Use it
> only if you have read-only flash.
>
> Or, if you don't have to write to flash for the normal operation of your
> system except for some unfrequent occasions, then a simple workaround is
> simply to perform a small read of the MTD device right after the write
> has completed which will return the flash to data mode.
Yes this is my case and I have now put in this which minimize the time
when the flash is unreadable.
I was thinking that I might put in a watchdog isr that could put the flash
in read mode again and then do same as the arch_reset. But I guess that I
cannot call cfi_intelext_reboot() or similar from a isr because of
deadlock risk.
And and other problem is that it might not work if the program code for
the isr is corrupt.
>
>> The built in hardware watchdog on the at91rm9200 performs a cold reset
>> on all on chip periphials but does nothing on the external.
>
> Otherwise, if the watchdog doesn't assert a reset line to which the
> flash is connected then it is not fulfilling its purpose and you shoud
> simply not use it at all. The only exception is for the system reboot
> case where it is expected to fire only after things have been prepared
> for a clean reboot.
>
>
> Nicolas
>
>
Thank for explaining, Tomas
^ permalink raw reply
* Re: jffs2 Oops on mount
From: Ladislav Michl @ 2006-03-22 19:49 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <20060322115409.GA2242@orphique>
On Wed, Mar 22, 2006 at 12:54:09PM +0100, Ladislav Michl wrote:
> Checked all inodes but still 0x13364c bytes of unchecked space?
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
Well, this is harmless (caused by BUG() defined as (*(int *)0 = 0))
With more debugs enabled it ends like this:
Skipping ino #228 already checked
Skipping ino #229 already checked
Skipping ino #270 already checked
Skipping check of ino #273 with nlink zero
[lots of skipping check of ino #xxx with nlink zero]
Skipping check of ino #800 with nlink zero
Skipping check of ino #801 with nlink zero
Skipping ino #802 already checked
Skipping check of ino #803 with nlink zero
Checked all inodes but still 0x13364c bytes of unchecked space?
Where checked_ino is 804 and highest_ino 803. ino 802 is already checked
because userspace requested read meanwhile.
Ideas?
Thanks,
ladis
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Nicolas Pitre @ 2006-03-22 19:40 UTC (permalink / raw)
To: Vitaly Wool
Cc: Alexander Belyakov, linux-mtd, Kutergin, Timofey, Korolev, Alexey
In-Reply-To: <4421A4BF.9060406@ru.mvista.com>
On Wed, 22 Mar 2006, Vitaly Wool wrote:
> Alexander,
>
> Let's look at it at the following angle. Striping is a nice concept, as well
> as many other nice concepts that exist in the world. Are they all worth being
> impemented in Linux MTD subsystem? :)
Why not, if you can configure it out.
> OTOH, what is the rationale? Make devices operate faster. Okay, why can't this
> be implemented as mtdconcat optimization?
mtdconcat provides linear access to subdevices.
The stripe module provides _interleaved_ access to subdevices.
That is the fundamental difference.
> What I'd also like to say is that having a lot of threads doesn't look
> attractive to me.
What is the problem with threads? The kernel already uses them heavily
for many purposes because it makes things cleaner.
> I'd rather go in for changing the whole MTD subsystem to
> make the API asynchoronus, and then you won't need many threads. But this is a
> rather dramatic change...
But do you realize that any asynchronous implementation will _still_
require kernel threads of its own to do the work anyway? That's the
reason why there is so many kernel threads running in your kernel
already.
One thread per subdevice minus 1 is sufficient (note I don't know if it
is implemented that way though as I didn't look at the code).
Nicolas
^ permalink raw reply
* Re: [PATCH/RFC] Linux MTD striping middle layer
From: Vitaly Wool @ 2006-03-22 19:25 UTC (permalink / raw)
To: Alexander Belyakov
Cc: Korolev, Alexey, Nicolas Pitre, Kutergin, Timofey, linux-mtd
In-Reply-To: <442179EB.9050605@intel.com>
Alexander,
Alexander Belyakov wrote:
> as I have already said concatenation is like JBOD in the world of hard
> drives. JBOD means "just a bunch of disks". Meanwhile striping is like
> RAID level 0. As you may know JBOD and RAID0 are completely different.
> Concatenation and striping have only one common thing - each of them
> makes larger devices. That's all. All the rest are different including
> new device parameters, writing, reading, erasing routines. Note, that
> concatenation layer writes/erases/etc from the caller thread,
> meanwhile striping layer do this from several separate threads,
> splitting operations by special algorithm.
>
> Moreover the idea is different. Concatenation only purpose is to make
> larger device from several smaller devices. Striping purpose is to
> make devices operate faster.
Let's look at it at the following angle. Striping is a nice concept, as
well as many other nice concepts that exist in the world. Are they all
worth being impemented in Linux MTD subsystem? :)
OTOH, what is the rationale? Make devices operate faster. Okay, why
can't this be implemented as mtdconcat optimization?
What I'd also like to say is that having a lot of threads doesn't look
attractive to me. I'd rather go in for changing the whole MTD subsystem
to make the API asynchoronus, and then you won't need many threads. But
this is a rather dramatic change...
Vitaly
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox