On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:

On 02/13/2014 03:55 PM, Thomas Gleixner wrote:

quoted

On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:

quoted

On 02/13/2014 02:25 PM, Thomas Gleixner wrote:

quoted

On Wed, 12 Feb 2014, Fernando Lopez-Lezcano wrote:

quoted

[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