[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1204181452410.8114@eristoteles.iwoars.net>
Date: Wed, 18 Apr 2012 14:55:05 +0200 (CEST)
From: Joel Reardon <joel@...mbassador.com>
To: Al Viro <viro@...IV.linux.org.uk>
cc: Artem Bityutskiy <dedekind1@...il.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: mtdchar kernel oops
Perhaps Artem can shed some light on this, I'm working on a branch he's
prepared. But if its not happening at your end then perhaps something's up
on mine; the oops log is rather bizzare. I'll remake it from scratch and
see what happens.
Cheers,
Joel
On Mon, 16 Apr 2012, Al Viro wrote:
> On Mon, Apr 16, 2012 at 02:37:06PM +0200, Joel Reardon wrote:
> > The troubled asm pair corresponds to this line:
> > this_cpu_add(mnt->mnt_pcp->mnt_count, n) in the inline mnt_add_count().
> > So I suppose that perhaps either mnt is bad, or mnt_pcp is bad.
> >
> > I'm using nandsim to simulate the mtd device. Steps are simple, load the
> > modules:
> > nand_ecc nand nand_ids mtd mtd_blkdevs mtdblock mtdchar
> > nandsim first_id_byte=0x20 second_id_byte=0xa5 third_id_byte=0x00 fourth_id_byte=0x15 parts=0xa40 rptwear=1000
> >
> > then `ubiformat /dev/mtd0` does the oops.
>
> Not here:
>
> root@...zy:~# modprobe nandsim first_id_byte=0x20 second_id_byte=0xa5 third_id_byte=0x00 fourth_id_byte=0x15 parts=0xa40 rptwear=1000
> ubiformat: mtd0 (nand), size 343932928 bytes (328.0 MiB), 2624 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
> libscan: scanning eraseblock 2623 -- 100 % complete
> ubiformat: 2624 eraseblocks are supposedly empty
> ubiformat: formatting eraseblock 2623 -- 100 % complete
> root@...zy:~# uname -a
> Linux dizzy 3.4.0-rc2+ #4 SMP Mon Apr 16 15:04:25 EDT 2012 x86_64 GNU/Linux
>
> and no oopsen in sight...
>
>
> > > Could you add printk into mtdchar_open(), dumping mnt and count values
> > > right after simple_pin_fs() call?
> > >
> >
> > It oopses before it returns from the simple_pin_fs call, so that won't be
> > possible...
>
> Wha...? You mean, that happens on the _first_ simple_pin_fs() call?
> But that makes no damn sense whatsoever - we just do vfs_kern_mount(),
> get a vfsmount from it (and not an ERR_PTR(), at that), then store
> it into mnt and do mntget(mnt) followed by mntput(mnt). If that really
> happens when simple_pin_fs() gets called with mnt == NULL and count == 0,
> we have much bigger problem on hands...
>
> Please, slap such printks before and after simple_pin_fs() in mtdchar_open()
> and before and after simple_release_fs() in mtdchar_close(). And verify that
> you have commit c65390f4dd49755863f6d772ec538ee4757c08d7 in your tree.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists