Re: Problems with 2.6.17-rt8

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2006-08-03 at 08:08 -0700, Robert Crocombe wrote:
> On 8/3/06, Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > Call Trace:
> > >        <ffffffff8047655a>{_raw_spin_lock_irqsave+24}
> > >        <ffffffff8022b272>{__WARN_ON+100}
> > >        <ffffffff802457e4>{debug_rt_mutex_unlock+199}
> > >        <ffffffff804757b7>{rt_lock_slowunlock+25}
> > >        <ffffffff80476301>{__lock_text_start+9}
> >
> > hmm, here we are probably having trouble with the percpu slab locks,
> > that is somewhat of a hack to get slabs working on a per cpu basis.
> >
> > >        <ffffffff80271e93>{kmem_cache_alloc+202}
> >
> > It would also be nice to know exactly where ffffffff80271e93 is.
> 
> >From the System.map file:
> 
> ffffffff80271df5 t gather_stats
> ffffffff80271e98 t get_zonemask
> ffffffff80271f1e T __mpol_equal
> 

Actually, if you compiled with debugging information on, you can use gdb
to get a pretty good location:

$ cd path/to/build/directory
$ gdb vmlinux
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-linux --target=x86_64-linux".

(gdb) li *0xffffffff80271e93

That is if your gdb is also compiled for 64 bit.

-- Steve