RE: Exception in kernel mode

It this a system you are just bringing up or one that's been running=20
for a while.  It really seems like memory corruption of some form. =20
I'd suggest checking memory controller settings.

Also, what happens if you disassemble the kernel image and look at=20
the addresses pointed to by NIP:
C00DEE18 & C002CE68.

- k
Dear Kumar:
=20
We have two systems. One based on an 8241, and one based on an 8541. The =
8241 has been running for some time with Linux 2.4 and the 8541 is =
coming up. Both are using the 2.6.17.11 kernel from kernel.org with =
modifications for our hardware.
=20
In the case of the 8241, I started out with the 2.4 modifications, which =
were originally based on the 8260 and ported them to 2.6. In the case of =
the 8541, I started out with the embedded planet 8555EP 2.6 kernel =
source and added that to the 2.6.
=20
I dont see this exception in the 8541, although extensive testing has =
not yet been completed. The 8241 exhibits this exception on three =
different 8241 boards, so I dont suspect the hardware.
=20
We are using the Montavista toolchain and their root filesystem =
including 'tar' and 'cp' which are the programs that currently exhibit =
the fault.
=20
Yesterday, when I saw an NIP at 0x900, I was ready to jump on the =
interrupts not being setup correctly, but after a few hours of going =
through that, I am now convinced the interrupts are setup correctly, so =
it is something more subtle.
=20
Certainly, memory corruption is the next thing to be concerned with.=20
=20
One thing that has concerned me a bit is that we have no swap space =
available at all. This is an embedded system with 64MByte of RAM and =
JFFS2 NAND flash with no swap partitions.
=20
I suspect auditing the MMU setup differences between the original 2.4 =
kernel and the new 2.6 kernel for the 8241 board is the next step.
=20
The three exceptions I saw yesterday were 1)0x900 in the =
timer_interrupt, 2) C00DEE18 (inside the tar program) and 3) C002CE68 =
(in one of the kernel routines).=20
=20
I suspect the actual addresses are red-herrings and this exception can =
occur at any address. This certainly would tend to indicate some sort of =
memory setup issue.
=20
Changing the Oops logic to printout the NextInstruction as well as the =
NIP might be helpful so I could discern the difference between what the =
program is trying to do and what it is really doing.
=20
Are there any other thoughts you might have on diagnosis techniques at =
this point?
=20
Charles
=20
=20
In the meantime, any thoughts you might have on methods to di