headers
jessonel | 2 Nov 2009 07:19
Picon
Favicon

JFFS2 Crash

Hello, 

I'm working with at91sam9rl64 & samsung nand flash.
The following is kernel dump when the system is starting up.
Any help?

=======================================================
JFFS2 notice: (325) check_node_data: wrong data CRC in data node at 0x00e1df64: read 0x2289e0b4,
calculated 0xe1744b6d.
Unable to handle kernel NULL pointer dereference at virtual address 0000001e
pgd = c0004000
[0000001e] *pgd=00000000
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0    Not tainted  (2.6.27 #964)
PC is at jffs2_get_inode_nodes+0xb50/0x1090
LR is at jffs2_get_inode_nodes+0xb4c/0x1090
pc : [<c010b100>]    lr : [<c010b0fc>]    psr: 60000013
sp : c3a21db0  ip : c3a21db0  fp : c3a21e14
r10: 0000053c  r9 : c392a200  r8 : 00000451
r7 : 00000000  r6 : c3a29de0  r5 : c3920000  r4 : 00000000
r3 : 00000001  r2 : c3a29e40  r1 : 00000000  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: 23a80000  DAC: 00000017
Process jffs2_gcd_mtd1 (pid: 325, stack limit = 0xc3a20268)
Stack: (0xc3a21db0 to 0xc3a22000)
1da0:                                     0000053c c3a21de4 c3920000 c3a21dc8
1dc0: c0108bb4 c3a0fc90 00000000 c3a21e3c c3995200 00000000 c3a20000 c3a0fc88
1de0: 00000800 0000053c c0108a60 c3a21e3c c3a0cec0 c3a21e94 c3995200 00000084
1e00: 00000000 c392a200 c3a21e8c c3a21e18 c010b67c c010a5c0 00000044 c3a21e5c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Blunck | 2 Nov 2009 11:05
Picon

[PATCH 26/27] BKL: Remove BKL from ubifs

BKL is only used in get_sb. It is safe to remove it.

Signed-off-by: Jan Blunck <jblunck <at> suse.de>
---
 fs/ubifs/super.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 04a0fc9..333e181 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
 <at>  <at>  -2029,8 +2029,6  <at>  <at>  static int ubifs_get_sb(struct file_system_type *fs_type, int flags,
 	struct super_block *sb;
 	int err;

-	lock_kernel();
-
 	dbg_gen("name %s, flags %#x", name, flags);

 	/*
 <at>  <at>  -2042,7 +2040,6  <at>  <at>  static int ubifs_get_sb(struct file_system_type *fs_type, int flags,
 	if (IS_ERR(ubi)) {
 		ubifs_err("cannot open \"%s\", error %d",
 			  name, (int)PTR_ERR(ubi));
-		unlock_kernel();
 		return PTR_ERR(ubi);
 	}
 	ubi_get_volume_info(ubi, &vi);
 <at>  <at>  -2080,14 +2077,12  <at>  <at>  static int ubifs_get_sb(struct file_system_type *fs_type, int flags,
 	ubi_close_volume(ubi);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Blunck | 2 Nov 2009 11:04
Picon

[PATCH 01/27] BKL: Push down BKL from do_new_mount() to the filesystems get_sb/fill_super operation

I've read through all the code formerly covered by the BKL inside
do_kern_mount() and have satisfied myself that it doesn't need the BKL
any more.

do_kern_mount() is already called without the BKL when mounting the rootfs
and in nfsctl. do_kern_mount() calls vfs_kern_mount(), which is called
from various places without BKL: simple_pin_fs(), nfs_do_clone_mount()
through nfs_follow_mountpoint(), afs_mntpt_do_automount() through
afs_mntpt_follow_link(). Both later functions are actually the filesystems
follow_link inode operation. vfs_kern_mount() is calling the specified
get_sb function and lets the filesystem do its job by calling the given
fill_super function.

Therefore I think it is safe to push down the BKL from the VFS to the
low-level filesystems get_sb/fill_super operation.

Signed-off-by: Jan Blunck <jblunck <at> suse.de>
Cc: Matthew Wilcox <matthew <at> wil.cx>
---
 fs/9p/vfs_super.c            |    9 ++++++++-
 fs/adfs/super.c              |    8 +++++++-
 fs/affs/super.c              |    9 ++++++++-
 fs/afs/super.c               |    5 +++++
 fs/autofs4/inode.c           |    4 ++++
 fs/befs/linuxvfs.c           |    4 ++++
 fs/bfs/inode.c               |    9 ++++++++-
 fs/binfmt_misc.c             |    6 +++++-
 fs/btrfs/super.c             |    8 +++++++-
 fs/cifs/cifsfs.c             |   12 ++++++++++--
 fs/coda/inode.c              |    8 +++++++-
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ben Dooks | 2 Nov 2009 19:12
Picon
Favicon

NAND: Add option to quieten off the no device found messgae

Add NAND_SCAN_SILENT_NODEV to chip->options to the user-worrying messages
'No NAND device found!!!'. This message often worries users (was three
exclamation marks really necessary?) and especially in systems such as the
Simtec Osiris where there may be optional NAND devices which are not
known until probe time.

Revised version of the original NAND_PROBE_SPECULATIVE patch after comments
by Artem Bityutskiy about adding a whole new call.

Signed-off-by: Ben Dooks <ben <at> simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux <at> simtec.co.uk>

---
 drivers/mtd/nand/nand_base.c |    3 ++-
 include/linux/mtd/nand.h     |    4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: b/drivers/mtd/nand/nand_base.c
===================================================================
--- a/drivers/mtd/nand/nand_base.c	2009-11-02 17:33:29.000000000 +0000
+++ b/drivers/mtd/nand/nand_base.c	2009-11-02 18:01:08.000000000 +0000
 <at>  <at>  -2639,7 +2639,8  <at>  <at>  int nand_scan_ident(struct mtd_info *mtd
 	type = nand_get_flash_type(mtd, chip, busw, &nand_maf_id);

 	if (IS_ERR(type)) {
-		printk(KERN_WARNING "No NAND device found!!!\n");
+		if (!(chip->options & NAND_SCAN_SILENT_NODEV))
+			printk(KERN_WARNING "No NAND device found!!!\n");
 		chip->select_chip(mtd, -1);
 		return PTR_ERR(type);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Dooks | 2 Nov 2009 19:12
Picon
Favicon

s3c2410: propogate nand options from the platform data

Update the nand information passed to the core from the platform data to
setup the initial option value, so that flags such as NAND_SCAN_SILENT_NODEV
can pass through.

Signed-off-by: Ben Dooks <ben <at> simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux <at> simtec.co.uk>

---
 arch/arm/plat-s3c/include/plat/nand.h |    2 ++
 drivers/mtd/nand/s3c2410.c            |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

Index: b/arch/arm/plat-s3c/include/plat/nand.h
===================================================================
--- a/arch/arm/plat-s3c/include/plat/nand.h	2009-11-02 17:37:01.000000000 +0000
+++ b/arch/arm/plat-s3c/include/plat/nand.h	2009-11-02 17:38:32.000000000 +0000
 <at>  <at>  -17,6 +17,7  <at>  <at> 
  *			Setting this flag will allow the kernel to
  *			look for it at boot time and also skip the NAND
  *			scan.
+ *  <at> options:		Default value to set into 'struct nand_chip' options.
  *  <at> nr_chips:		Number of chips in this set
  *  <at> nr_partitions:	Number of partitions pointed to by  <at> partitions
  *  <at> name:		Name of set (optional)
 <at>  <at>  -31,6 +32,7  <at>  <at>  struct s3c2410_nand_set {
 	unsigned int		disable_ecc:1;
 	unsigned int		flash_bbt:1;

+	unsigned int		options;
 	int			nr_chips;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 3 Nov 2009 07:23
Picon

Re: [PATCH v12 2/4]: mtdoops: Add a maximum MTD partition size

On Thu, 2009-10-29 at 13:41 +0100, Simon Kagstrom wrote:
> A configurable maximum MTD partition size for mtdoops avoids mistakes
> where the user gives e.g., a rootfs partition to mtdoops (which will
> happily erase it).
> 
> Signed-off-by: Simon Kagstrom <simon.kagstrom <at> netinsight.net>

I've amended your patch and pushed the amended version to my tree.
Please, validate.

>From 9483bcb6b097ef3078e5a8798012e06e5156e54e Mon Sep 17 00:00:00 2001
From: Simon Kagstrom <simon.kagstrom <at> netinsight.net>
Date: Tue, 3 Nov 2009 08:08:41 +0200
Subject: mtd: mtdoops: limit the maximum mtd partition size

Make the maximum mtdoops partition size to be 32MiB. Indeed, it does
not make sense to use anything larger than that anyway. This limit
makes it possible to catch stupid mistakes where the user gives e.g.,
a rootfs partition to mtdoops (which will happily erase it).

Signed-off-by: Simon Kagstrom <simon.kagstrom <at> netinsight.net>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy <at> nokia.com>
---
 drivers/mtd/mtdoops.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
index 06c5382..2493c08 100644
--- a/drivers/mtd/mtdoops.c
+++ b/drivers/mtd/mtdoops.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 3 Nov 2009 07:23
Picon

Re: [PATCH v12 3/4]: mtdoops: Make page (record) size configurable

On Thu, 2009-10-29 at 13:41 +0100, Simon Kagstrom wrote:
> The main justification for this is to allow catching long messages
> during a panic, where the top part might otherwise be lost since moving
> to the next block can require a flash erase.
> 
> Signed-off-by: Simon Kagstrom <simon.kagstrom <at> netinsight.net>
> Reviewed-by: Anders Grafstrom <anders.grafstrom <at> netinsight.net>
> ---
> ChangeLog:
>  * Rebased over "[PATCH v12 2/4]: mtdoops: Add a maximum MTD partition size"
> 
>  drivers/mtd/mtdoops.c |   75 ++++++++++++++++++++++++++++--------------------
>  1 files changed, 44 insertions(+), 31 deletions(-)

Pushed this one to my tree, on top of the previous patch which I
tweaked, thanks.

--

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 2 comments |
headers
Artem Bityutskiy | 3 Nov 2009 07:40
Picon

Re: [PATCH] MTD OneNAND OMAP2/3: allow giving partition layout as module parameter

On Thu, 2009-09-03 at 14:15 +0300, Mika Korhonen wrote:
> Add module parameter "parts" to omap2-onenand driver. Parameter format is
> the same as for cmdlinepart except mtd-id must not be specified - it
> gets prepended by the driver, i.e.: parts=<partdef>[,<partdef>]*
> 
> This allows one to repartition the OneNAND chip and is useful for flashing
> applications that do the partitioning from scratch or want to backup and
> update the partitioning.
> 
> Signed-off-by: Mika Korhonen <ext-mika.2.korhonen <at> nokia.com>
> ---
>  drivers/mtd/cmdlinepart.c   |   35 +++++++++++++++++++++++++++++------
>  drivers/mtd/onenand/omap2.c |   29 +++++++++++++++++++++++++++++
>  2 files changed, 58 insertions(+), 6 deletions(-)

This should not be onenand module parameters actually. This
re-partitioning should be done via an mtd device ioctl instead.

Could you try to introduce a new mtd ioctl?

I know the partitioning in mtd is ugly, so you may hit some challenges.
E.g., all these special cases like

#ifdef CONFIG_MTD_PARTITIONS
        /* Deregister partitions */
        del_mtd_partitions (mtd);
#endif
        /* Deregister the device */
        del_mtd_device (mtd);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Artem Bityutskiy | 3 Nov 2009 08:05
Picon

Re: [PATCH] mtd: add lock fixup for AT49BV640D and AT49BV640DT chips

On Thu, 2009-10-29 at 13:05 +0100, Hans-Christian Egtvedt wrote:
> This patch sets the MTD_POWERUP_LOCK flag for AT49BV640D and AT49BV640DT
> devices, since the devices are locked when powered up and needs to be unlocked
> before interfaced.
> 
> Quote datasheet; "At power-up and reset, all sectors have their Softlock
> protection mode enabled.".
> 
> Tested on AVR32 hardware platform with an AT49BV640D flash device.
> 
> Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt <at> atmel.com>
> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index e7563a9..6228115 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
>  <at>  <at>  -52,6 +52,7  <at>  <at> 
>  #define M50FLW080A	0x0080
>  #define M50FLW080B	0x0081
>  #define AT49BV640D	0x02de
> +#define AT49BV640DT	0x02db
>  
>  static int cfi_intelext_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
>  static int cfi_intelext_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
>  <at>  <at>  -255,6 +256,11  <at>  <at>  static void fixup_use_point(struct mtd_info *mtd, void *param)
>  	}
>  }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Kagstrom | 3 Nov 2009 08:27
Favicon

Re: [PATCH v12 3/4]: mtdoops: Make page (record) size configurable

On Tue, 03 Nov 2009 08:23:58 +0200
Artem Bityutskiy <dedekind1 <at> gmail.com> wrote:

> On Thu, 2009-10-29 at 13:41 +0100, Simon Kagstrom wrote:
> > The main justification for this is to allow catching long messages
> > during a panic, where the top part might otherwise be lost since moving
> > to the next block can require a flash erase.
> > 
> > Signed-off-by: Simon Kagstrom <simon.kagstrom <at> netinsight.net>
> > Reviewed-by: Anders Grafstrom <anders.grafstrom <at> netinsight.net>
> > ---
> > ChangeLog:
> >  * Rebased over "[PATCH v12 2/4]: mtdoops: Add a maximum MTD partition size"
> > 
> >  drivers/mtd/mtdoops.c |   75 ++++++++++++++++++++++++++++--------------------
> >  1 files changed, 44 insertions(+), 31 deletions(-)
> 
> Pushed this one to my tree, on top of the previous patch which I
> tweaked, thanks.

Thanks! I was going to send an updated patch in, but I've had some
other work to do lately. I'll send in a new version of the final patch
before the end of the day.

I noticed a small issue in your updated patch:

> +/* Maximum MTD partition size, MiB */
> +#define MTDOOPS_MAX_MTD_SIZE 32

>  <at>  <at>  -310,6 +312,12  <at>  <at>  static void mtdoops_notify_add(struct mtd_info *mtd)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane