On Sun, 26 Nov 2000, Ken Wills wrote:

> I've applied this patch, but I'm still seeing the same thing (although panics seem to be less frequent.)
> 
> panic: TLB out of universe: ksp 0xc48fbf78 epc 0x8004bd74 vaddr 0xd261f000
> Stopped at      0x80100230:     jr      ra
>                 bdslot: nop
...

 db> machine tlb
> TLB  0 Hi 0xc4db4000 Lo0=0x03b52000 DG attr 3 Lo1=0x03b51000 DG attr 3 sz=0
...
> TLB 21 Hi 0xc48fa002 Lo0=0x00507000 DG attr 3 Lo1=0x00498000 DG attr 3 sz=0

  This looks a little odd to me, but it might just be that I've forgotten
how this stuff works.  The KSP at the time of the exception is 0xc48fbf78,
which is mapped by the entry in TLB 21.  The last I knew, the kernel stack
should be the address mapped by the wired TLB 0 entry.

> Any more clues? :)

  It might be interesting to know where in the kernel the execption
occurred, i.e. what kernel address corresponds to the EPC value
0x8004bd74.  Also, in DDB you can do x/i 0x8004bd74 to display the
instruction at the EPC.  [A little more context around that EPC might be
helpful by displaying several instructions at that point.]

  You could also try getting a valid stack trace.  This would require
modifying the code in locore_mips3.S at outofworld: to not change the
stack pointer.  [I think the original code presumed that a TLB miss with a
KSEG2 address outside of the kernel's allocated memory was most likely a
stack overflow/underflow (the kernel stack was at a fixed address at the
end of the KSEG2 space then), and forced a KSEG0 stack address.]

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA