On Thu, Dec 23, 2004 at 04:58:03PM +0530, Nori, Soma Sekhar wrote: > We are using montavista Linux version 2.4.17, gcc version 2.95.3 running on MIPS 4kec. > > Here is the dump: > $0 : 00000000 0044def4 000001ac 0000006b 00000000 7fff7c08 00000001 00000000 > $8 : 0000fc00 00000001 00000000 941524d0 00004700 00000000 97fc3ea0 7fff7c08 > $16: 100048a4 100029d8 100029d8 10003020 00000000 7fff7dc8 10003b60 2d8e2163 > $24: 00000001 2ab7bc30 10008e70 7fff7bf0 04000000 00439e50 > Hi : 00000000 > Lo : 00000001 > epc : 00439e84 Not tainted > Status: 0000fc13 > Cause : 10800028 > Process sh (pid: 18, stackpage=97fc2000) > Stack: 00000001 00000000 2abd0ff0 7fff7c28 10008e70 00000000 10008e6c 00000000 > 100049a0 0042f188 00000000 100029d8 00000001 00000001 7fff7f04 10008e70 > 00427fe4 00427f00 00000000 00000000 10002764 10008e70 10008e70 00000000 > 00000000 00000000 10008e70 00422734 00000001 00000001 7fff7f04 10008e70 > 10008e70 00000003 10008e70 004315cc 00000001 00000000 10002764 00000000 > 10008e70 ... > Call Trace: > Code: 00000000 2421dd48 00220821 <8c220000> 00000000 005c1021 00400008 0000 > 0000 8f99802c > > The epc is not in kernel space and ksymoops did not provide any info. The epc keeps changing to different locations in user space over multiple runs. In a case like this you're likely dealing with double exceptions. Your code is taking an exception and the exception handler while running with c0_status set is taking another exception. If the first exception handler is still running with the c0_status.exl bit set the CPU when taking the second exception it will not record the PC of the second exception and you will have a seemingly unexplainable exception. A few processors have the nasty habit of throwing RI receptions or do similarly weird things when executing code that is mapped through multiple TLB pages but the 4kEC shouldn't. Ralf
