A confusing oops dump ...

A confusing oops dump ...

[Jun Sun]

I got the following oops dump during a stress load, which I cannot make any
sense out of it.  The most confusing part is that the status register
indicates program was running in kernel (KSU bits) while the $epc points to a
userland address.  How could this be ever possible at hardware level?

The only possible explanation is perhaps those saved registers were corrupted
between when the exception happens and core dumps, but so unlikely .... *sigh*

Any insight?

Jun

Unable to handle kernel paging request at virtual address 100096e0, epc ==
10000
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 100015d4 00000001 81e43160
$4 : 00000001 00000001 00000000 8328a680
$8 : 0000308e 00000000 800ba0dc 00000003
$12: 00000010 2ac45e7c 00000000 82f6e039
$16: 0041393c 10003510 000005f0 00000000
$20: 0000308e 00000000 fffffffc 00409350
$24: 00000000 2ab92f10
$28: 83b18000 7fff77f0 10003510 100096e0
epc   : 100096e0
Status: 30017c03
Cause : 00008008
Process  (pid: 0, stackpage=7fff6000)
Stack: 100096e0 7fff7800 004036f0 004036d4 10003518 7fff6fec 00000000 6f727020
       100096e0 7fff6930 7fff7b04 00004dd1 7fff7920 0fb64798 00000000 00000000
       00000000 00000000 0fb94020 00000000 00000000 00000000 0fb600cc 00000000
       00000000 00000000 00000000 00000000 00000000 0fb60104 0fb600d4 0fb600dc
       0fb600e4 00000000 00000000 00000000 0fb600ec 0fb600f4 00000000 00000000
       0fb600cc ...
Call Trace:
Code: (Bad address in epc)

Re: A confusing oops dump ...

[Martin Michlmayr]

* Jun Sun <jsun@mvista.com> [20010621 14:07]:
> Oops in fault.c:do_page_fault, line 172:

Is this related to the oops I get when booting my DECstation or are
these separate issues?

Unable to handle kernel paging request at virtual address 00000004, epc == 80053f48, ra == 80053f00
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 10002000 80720410 00000000 80720410 00000000 00001090 00000001
$8 : 00000000 00000000 00000000 00000000 801ed867 fffffff7 ffffffff 81097470
$16: 81092000 00010000 00000000 80048020 fffffff4 00010f00 80721090 80720fe0
$24: 00000001 0000000a                   80720000 80720f58 00000000 80053f00
epc  : 80053f48
Status: 10002004
Cause : 30000008
Process  (pid: 0, stackpage=80720000)
Stack: 8005b7c4 00000001 000000c0 8005b488 801e703c 800f574c 00000000 00000000
       00000000 80720f7c 80720f7c 00000023 00000000 00000000 00000000 80720f7c
       80720f7c 00000023 00010f00 00010000 00000000 80048020 30464354 a0002f88
       00000200 001220d2 44208a0a 8004d5d0 00000000 ffffffff ffffffff 00000000
       8004deac bc180001 00010f00 00000000 80721090 bc180001 801ed867 fffffff7
       00000000 ...
Call Trace: [<8005b7c4>] [<8005b488>] [<800f574c>] [<80048020>] [<8004d5d0>] [<8004deac>]
Code: 24630010  8e0501d4  8e030218 <8ca20004> 00000000  0043102b 1040030f  2414fff5  40046000

Re: A confusing oops dump ...

[Justin Carlson]

On Thu, 21 Jun 2001, you wrote:
> I got the following oops dump during a stress load, which I cannot make any
> sense out of it.  The most confusing part is that the status register
> indicates program was running in kernel (KSU bits) while the $epc points to a
> userland address.  How could this be ever possible at hardware level?

It's very possible at the hardware level...kernel mode enables access to
several segments; it doesn't disable mapped accesses.  I don't think it should
ever happen in linux, but there's nothing in the hardware that prevents this.

> 
> The only possible explanation is perhaps those saved registers were corrupted
> between when the exception happens and core dumps, but so unlikely .... *sigh*
> 
> Any insight?

You've got a TLBL exception, and va doesn't match epc, so
presumably the processor thinks it was a load and  not an ifetch that triggered
this.  It also follows that the processor thinks it found a valid instruction
at 0x10000.  If this is reproducable and the chip allows it, try dumping out
the icache when you hit this, see if 0x10000 really appears in there...

-Justin