lkml.org 
[lkml]   [2003]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: reiserfs oops [2.5.65]
    Dave Jones <davej@codemonkey.org.uk> wrote:
    >
    > There's lots of "slab error in cache_alloc_debugcheck_after()"
    > warnings. cache reiser_inode_cache memory after object was overwritten
    >
    > Some call traces.
    > check_poison_obj <- kmem_cache_alloc <- reierfs_alloc_inode <-
    > reiserfs_alloc_inode <- alloc_inode <- get_new_inode <-
    > reiserfs_init_locked <- reiserfs_find_actor <- reiserfs_iget <-
    > reiserfs_find_actor <- reiserfs_init_locked_inode <- reiserfs_lookup <-
    > real_lookup <- do_lookup <- link_path_walk <- kmem_cache_alloc <-
    > __user_walk <- vfs_lstat <- sys_lstat64 <- syscall_call
    >
    > Slab corruption: start=c70c7044, expend=c70c7213 problemat=c70c7044
    > Last user: [<c0280dcb>](reiserfs_alloc_inode+0x1b/0x30)
    > Data: (lots of hex)

    Alas, the "(lots of hex)" is important - it lets us determine which member of
    struct reiserfs_inode was actually altered.

    > I'll give that box a run of memtest to rule out memory corruption
    > problems. I'll also hook up a serial terminal tonight to catch tomorrow
    > nights 'activity' in full 8-)

    Good, thanks.

    It would be nice if we had a more robust way of capturing all this info,
    especially the oops-while-running-X lossage. Dump-to-floppy or something.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.021 / U:212.520 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site