Messages in this thread | | | Date | Thu, 30 Jun 2011 11:02:54 -0700 | Subject | Re: PROBLEM: ARM-dma-mapping-fix-for-speculative-prefetching cause OOPS | From | Dan Williams <> |
| |
On Thu, Jun 30, 2011 at 4:28 AM, Russell King <rmk@arm.linux.org.uk> wrote: > On Thu, Jun 30, 2011 at 07:16:24PM +0800, Qin Dehua wrote: >> Commit 2ffe2da3e follows v2.6.32, the message is from kernel build on >> commit 2ffe2da3e. >> >> The config has CONFIG_BUG=y and CONFIG_DEBUG_BUGVERBOSE=y, but the >> message is Oops, not BUG() macro, so they don't have line number. > > In that case, the raid5 code contains an explicit NULL pointer > dereference which isn't a BUG() - the code line disassembles to: > > 0: ebfff1bc bl 0xffffc6f8 > 4: e28dd044 add sp, sp, #68 ; 0x44 > 8: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc} > c: e3a03000 mov r3, #0 ; 0x0 > 10: e5833000 str r3, [r3] <=== faulting instruction > > So, if you're saying that's not a BUG(), then I don't know what it is > and I'm afraid I can't help because the oops doesn't make any sense > to me. >
QinDehua,
Can you rebuild with CONFIG_DEBUG_INFO=y, reproduce the crash and then send the output of:
$ gdb drivers/md/raid5.o (gdb) li *(raid5d+0x580) (gdb) li *(__release_stripe+0x1e4) etc...
...those offsets might change so just grab whatever "PC is at " reports in the oops.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |