There is something seriously messed up here.

The crash is showing you took an abort in IRQ mode - the spsr is 0x20000112.
However, the code in the instruction stream seems to be in the kernel
interrupt dispatch code - this should be executed in svc mode (the sequence
of instructions just before this crash should have done a cps #0x13).

The faulting instruction is ldr r0, [ip] but the ip value is 0x00000002
(hence the data abort on unaligned access).
The ip value should be a valid kernel data location (via ldr ip, [pc, #48]
a few instructions earlier).

What processor is this?

	Sunil.

Narasimha Challa wrote:
> I recently brought up smp kernel on our SoC (v7-mp). I am noticing a kernel crash when I run the mmcsd driver. The 
dump from the kernel crash looks like this
> 
> Shutdown[0,0] S/C/F=10/1/5 C/D=fe02869c/fe0a9000 state(f00)= now lock exit specret
> QNX Version 6.5.0 Release 2010/07/09-14:27:56EDT
> [0]PID-TID=1-1  P/T FL=00019001/09000000 "proc/boot/procnto-smp-instr"
> [0]ASPACE PID=4099 PF=00401010 "proc/boot/devc-ser8250-xingu8"
> [1]PID-TID=12296-2  P/T FL=00401010/85020000 "proc/boot/devi-mvFusion"
> armle context[effdc304]:
> 0000: fe085a58 00000001 00000001 00000001 fe0a9518 fe0a8efc fe085bd4 00000000
> 0020: 00000000 00000000 00000000 00000000 00000002 effeb9f0 fe085a00 effed574
> 0040: 20000112
> instruction[effed574]:
> 00 00 9c e5 00 00 30 e3 fc ff ff 1a 91 00 0c e1 00 00 30 e3 f9 ff ff 1a ba 0f
> stack[effeb9f0]:
> 0000: 00000000 00000000 effeb9fc 00000000 00000010 00000000 00000000 00000000
> 0020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 0040: 000005d0 effedec0 effedec0 effedec0 00000000 02000020 02200802 00800000
> 0060: 00020002 00800000 02000008 22020000 80000080 80002000 00008a80 00080880
> 
> The kernel always crashes in state "now lock exit specret" and while executing an instruction in the address range 
0xeffexxxx. Does anyone know what code exists at 0xeffexxxx and when does the kernel take the special return path?
> 
> I have noticed this happen only with L1 i-cache enabled. But, I think it is just a race condition that happens with i-
cache enabled and doesn't have anything to do with cache maintenance as I verified that cache maintenance operations 
work properly.
> 
> Thanks in advance.
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post89670
>