Subject: Re: uvmpg.swpgonly botch
To: I. Souvatzis <email@example.com>
From: Scott Reynolds <firstname.lastname@example.org>
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...