Subject: Re: -current TLB panics on 3100?
To: None <port-pmax@netbsd.org, port-mips@netbsd.org>
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
List: port-pmax
Date: 11/10/1999 09:35:34
>>   I just built my custom kernel for a 5000/200 I've been running, and it
>> gets the TLB bug 'reliably' during boot up.  I am in the process right
>> now of trying to get a core dump of the system so I can do some
>> post-mortem kernel groveling.  I've also added some additional debugging
>> output in the UTLBmod handler.  Hopefully this shouldn't take too long
>> to track down now.
>
>  One additional item:  after adding MIPS3 to my kernel configuration,
> the kernel boots up fine, so it certainly looks like it's something
> related to a MIPS1-only configuration.  Now all I need to do is figure
> out just how to track this little bug down.

I made a little change on TLB handling early summar after learning 
how smartly MIPS tlbpid/asid is designed. NetBSD/mips TLB handler,
which was inherited from 4.4BSD, does weird jobs trying to 'synchronize'
the content of TLB whenever TLB is about to be invalidated.   It should
not be necessary, bumping tlbpid/asid would be just ok for the purpose,
and that's the reason why tlbpid/asid was invented.

I tried to mimic what NetBSD/alpha does for asn of Alpha processor,
however, during the effort, I recognized it'd be necessary to run an
entire rework in pmap.c rather than a local hack because current
implementation of pmap.c is designed strangely (I even wonder the
designer understood software managed TLB handler, or the original VM
behaves differently from our notion of UNIX processes) and too fragile
to enhance.  The TLB enhancement was half-done and a part of them takes
an effect on MIPS1-only configuration (see trap.c).

The immediate fix would be to backout the mod., but, I have no idea this
moment why my Personal DECstation have not revealed the issue for long
time. 

Tohru Nisimura