On Fri, Sep 06, 2013 at 09:32:52AM -0400, Steven Rostedt wrote:
> On Thu, 5 Sep 2013 23:58:27 -0400
> Dave Jones <da...@redhat.com> wrote:
>
> > On Thu, Sep 05, 2013 at 09:51:54PM -0400, Steven Rostedt wrote:
> > > On Thu, 5 Sep 2013 21:48:59 -0400
> > > Dave Jones <da...@redhat.com> wrote:
> > >
> > > > On Thu, Sep 05, 2013 at 09:44:55PM -0400, Steven Rostedt wrote:
> > > > > On Thu, 5 Sep 2013 21:34:55 -0400
> > > > > Dave Jones <da...@redhat.com> wrote:
> > > > >
> > > > > > On Thu, Sep 05, 2013 at 09:28:34PM -0400, Steven Rostedt wrote:
> > >
> > > > > Did you change a config option, or update your gcc?
> > > >
> > > > Yeah, changed CONFIG_DEBUG_KOBJECT, which rebuilt the world.
> > >
> > > Still doesn't explain why it gave you that splat there.
> > >
> > > Do you still have that binary module, and can you show me what's at
> > > reiserfs_init_bitmap_cache+0x0 with objdump?
> >
> > I didn't, but it turns out I can recreate this. A little convoluted but..
> >
> > disable DEBUG_KOBJECT_RELEASE
> > build, install and boot into kernel
> >
> > enable DEBUG_KOBJECT_RELEASE
> > build kernel
> > install -> boom
>
> Did it report failing on the same function as before?
Yes.
> > 00000000000028b0 <reiserfs_init_bitmap_cache>:
> >
> > return bh;
> > }
> >
> > int reiserfs_init_bitmap_cache(struct super_block *sb)
> > {
> > 28b0: e8 00 00 00 00 callq 28b5
> > <reiserfs_init_bitmap_cache+0x5>
>
> That looks to be the call to fentry, but without being resolved. What
> we saw in the previous report wasn't 0xe8 but 0x14, and it was
> unresolved after loading!
>
> I'm surprised that the module built with a different
> DEBUG_KOBJECT_RELEASE config would load. Does it not affect module
> versions?
# CONFIG_MODVERSIONS is not set
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
