lkml.org 
[lkml]   [2012]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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@dizzy:~# 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@dizzy:~# 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.
    >


    \
     
     \ /
      Last update: 2012-04-18 22:37    [W:0.024 / U:0.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site