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/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:32 EST