Subject: do_page_fault crash on Indigo2

From: Greg McGary <[email-masked]>
Date: Mon, 11 Sep 2000 18:07:17 -0700

I built a kernel from the CVS trunk, updated as of last night (2000-09-10).

Here's my Indigo2 HW config (I pulled the G3-Elan board):

>> hinv
                   System: IP22
                Processor: 134 Mhz R4600, with FPU
     Primary I-cache size: 16 Kbytes
     Primary D-cache size: 16 Kbytes
     Secondary cache size: 512 Kbytes
              Memory size: 64 Mbytes
                SCSI Disk: scsi(0)disk(4)
                    Audio: Iris Audio Processor: version A2 revision 1.1.0

When I boot (passing init=/bin/sh), this happens:

------------------------------------------------------------------------------
...
Linux version 2.4.0-test8-pre1 ([email-masked]) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #1 Sun Sep 10 11:25:43 MST 2000
... many messages omitted ...
VFS: Mounted root (nfs filesystem) readonly.
Freeing prom memory: 0kb freed
Freeing unused kernel memory: 68k freed
------------------------------------------------------------------------------

Now it hangs, and when I hit <RETURN> at the serial console, I get this:

------------------------------------------------------------------------------
Unable to handle kernel paging request at virtual address 00000000, epc == 88026e10, ra == 880e058c
Oops in fault.c:do_page_fault, line 158:
$0 : 00000000 1000fc00 8818c62c 00000000
$4 : 8818c634 00000023 00000000 00000001
$8 : 884ee520 88009ed0 00000000 03f48000
$12: 8817f010 8818c634 8818c638 1000fc00
$16: 00000001 88185cf8 ffffffdf 0000000d
$20: 00000004 a8746e60 9fc56d94 00000000
$24: 00000000 00000001
$28: 88008000 88009e68 88009e68 880e058c
epc   : 88026e10
Status: 1000fc02
Cause : 00000008
Process swapper (pid: 0, stackpage=88008000)
Stack: 8817c000 881b4fa4 00000007 00000001 00000000 88033678 8802f31c 00000001
       8000000b 881a6cb0 80008000 887fe234 0019b3b0 00000001 881a6cb8 887fe234
       a87489f0 887fe53c 887fec20 881347ac 00008000 887fe234 a87489f0 887fe53c
       00000400 88134a78 88010c88 0000218c 00000f00 00000000 88009f88 0000218c
       00000000 88180000 880114d8 88186ac4 00000019 00000000 1000fc01 ffff00ff
       88009fe0 ...
Call Trace: [<88033678>] [<8802f31c>] [<881347ac>] [<88134a78>] [<88010c88>] [<88009f88>] [<880114d8>] [<88009fe0>] [<88008000>] [<88009f80>] [<8800f78c>] [<880114dc>] [<88135ce0>] [<880025c4>]
Code: 26315cf8  24100001  8c460004 <8cc30000> 00721024  00451024  1040005f  8dad0000  1320000e 
------------------------------------------------------------------------------

I get the exact same failure with both the hardhat-sgi-5.1 root FS and
with the simple/userland-0.2b root FS.

I found reference on the list archives to a possibly related problem
on R5000 Indys some months ago, but the system doesn't live long
enough to add swap space, and besides, the system shouldn't be
consuming all 64 MB so early.

Clues?

Greg

---

From: Greg McGary <[email-masked]>
Date: 11 Sep 2000 21:50:54 -0700

> Oops in fault.c:do_page_fault, line 158:

I'll send cross-ksymoops output when I it running.

> Clues?

As a fallback, can someone give me a date, or better yet a CVS tag,
for which an indigo2 kernel is known to work.

Thanks,
Greg

---

From: Greg McGary <[email-masked]>
Date: 12 Sep 2000 23:53:15 -0700

Here's the call trace.  I'm sure the symbol-table corresponds to the
crashed system, but the trace looks bogus to me.  I should have a look
at the call-trace dumping code in linux.  Since I have already written
one of these things for an embedded system, I painfully aware that
tracing the stack at runtime for MIPS is fraught with peril.

>>???; 88026e10 <__wake_up+80/3a0>   <=====

Trace; 88033678 <update_process_times+34/f8>
Trace; 8802f31c <tasklet_hi_action+a0/11c>
Trace; 881347ac <indy_local0_irqdispatch+c8/f4>
Trace; 88134a78 <__gnu_compiled_c+118/180>
Trace; 88010c88 <stack_done+1c/38>
Trace; 88009f88 <dummy+1f88/2000>
Trace; 880114d8 <r4k_wait+0/18>
Trace; 88009fe0 <dummy+1fe0/2000>
Trace; 88008000 <init_task_union+0/0>
Trace; 88009f80 <dummy+1f80/2000>
Trace; 8800f78c <__gnu_compiled_c+3c/60>
Trace; 880114dc <r4k_wait+4/18>
Trace; 88135ce0 <__gnu_compiled_c+410/2960>
Trace; 880025c4 <stext+40/a7c>

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Sep 2000 03:35:00 +0200

> tracing the stack at runtime for MIPS is fraught with peril.

Backtracing a MIPS stack is tricky; this is about as good as it can get.

  Ralf