On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:
> On 02/13/2014 03:55 PM, Thomas Gleixner wrote:
> > On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:
> >
> > > On 02/13/2014 02:25 PM, Thomas Gleixner wrote:
> > > > On Wed, 12 Feb 2014, Fernando Lopez-Lezcano wrote:
> > > > > [771508.546449] RIP: 0010:[<ffffffff810dc60a>] [<ffffffff810dc60a>]
> > > > > smp_call_function_many+0x2ca/0x330
> > > >
> > > > Can you decode the exact location inside of smp_call_function_many via
> > > > addr2line please ?
> > >
> > > Hope this is useful (adding 0x2ce/0x330 as offsets does not make any
> > > difference, don't know if it should)...
> > >
> > > # grep smp_call_function /var/log/messages|tail -1
> > > Feb 12 14:18:21 cmn27 kernel: [771840.224419] RIP:
> > > 0010:[<ffffffff810dc60e>]
> > > [<ffffffff810dc60e>] smp_call_function_many+0x2ce/0x330
> > > # addr2line -e
> > > /usr/lib/debug/lib/modules/3.12.10-300.rt15.1.fc20.ccrma.x86_64+rt/vmlinux
> > > ffffffff810dc60e
> > > /usr/src/debug/kernel-3.12.fc20.ccrma/linux-3.12.10-300.rt15.1.fc20.ccrma.x86_64/kernel/rtmutex.c:1295
> >
> > I can't see how the kernel decoder thinks it's smp_call_function_many
> > but addr2line looks at rtmutex.c
> >
> > That doesn't make any sense at all. Version mismatch?
>
> Indeed, sorry for the mixup... here I go again, hopefully this one will make
> sense:
>
> # addr2line -e
> /usr/lib/debug/lib/modules/3.12.9-301.rt13.1.fc20.ccrma.x86_64+rt/vmlinux
> ffffffff810dc60e
> /usr/src/debug/kernel-3.12.fc20.ccrma/linux-3.12.9-301.rt13.1.fc20.ccrma.x86_64/kernel/smp.c:108
So it's stuck in csd_lock_wait(), which means that the csd of the
target cpu is not free.
Is the machine completely dead or can you still retrieve information
from it?
Thanks,
tglx
--
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/
