Luke -Jr wrote:
On Sunday 08 June 2008, Kevin D. Kissell wrote:
and (b) control being transferred to a block of memory that isn't actually
code, as can happen if exception vectors or global pointers-to-functions
aren't set up correctly, or if the kernel stack is being corrupted. When
you say "the instruction in question is a store word", how do you know that?
The RI error spits out a bunch of info, including epc which presumably points
to the instruction causing the problem: ac85ffc0; this is 'sw a1,-64(a0)'
But unless the processor itself is actually defective, there is no way that
a SW instruction can cause an RI exception. Sometimes a kernel crash
is so violent that the kernel stack frame cannot be reliably decoded by
the crash dump code, and this would appear to be one of those cases.
I find the address of 0xac85ffc0 to be a bit suspicious, myself. That's
a kseg1 (non-cacheable identity map) address for physical address
0x0c85ffc0, which would be legitimate (though suspicious) if you had
256MB of RAM, but the boot log quote you posted earlier suggests
that you've only got 16M. Is there really memory of some kind at
that address? Are you calling routines in a boot ROM from Linux?
Debugging Linux kernel crashes is probably not the best way to learn
the MIPS privileged resource architecture. I'd strongly recommend
http://www.amazon.com/See-MIPS-Second-Dominic-Sweetman/dp/0120884216/
Regards,
Kevin K.
