Subject: Re: uvmpg.swpgonly botch
To: I. Souvatzis <ignatios@cs.uni-bonn.de>
From: Scott Reynolds <scottr@og.org>
List: tech-kern
Date: 04/08/1999 08:27:29
On Thu, 8 Apr 1999, I. Souvatzis wrote:

> On Thu, Apr 08, 1999 at 10:36:02AM +0200, I. Souvatzis wrote:
> > On Wed, Apr 07, 1999 at 06:01:25PM -0500, Scott Reynolds wrote:
> > > 
> > > This fixed that panic on one machine, and caused a new problem on a
> > > different machine, which is why it's not pulled up (yet).  I'm still
> > > gathering information on the new panic.
> > 
> > I see. The real problem I have with it is that it is a monster pullup, with
> > several not necessarily related changes, part of which are already included
> > in the Amiga pmap. 

the main reason that it's a `monster pullup' is that it's essentially a
replica of the hp300 pmap, now, with the appropriate constant
substitutions and a wee little bit in pmap_init().  it would take very
little effort to share the code between hp300 and mac68k, at this point.

> > So I really don't know how to even try it.
> 
> hm, and let me add that: maybe the real problem is generic, and depending on
> pmap behaviour you get either one or the other symptom.

that is a distinct possibility.

the new panic i mentioned above seems to have the potential to affect at
least amiga, hp300, and mac68k.  (i haven't yet looked at others, but i
suspect most/all other pmaps cloned from hp300 are also affected.)  in
other words, even when you get around the `uvmexp.swpgonly botch' panic,
there's still a problem.  the root cause seems to be that the pmap makes
calls back up to the higher-level vm code as a result of calling
pmap_pageable() (via pmap_page_protect()).

i don't have any reasonable ideas on how to solve this.  i'm hoping that
our resident experts can come up with something before too long...

--scott