> To: Havard Eidnes <Havard.Eidnes@runit.sintef.no>
> Cc: port-hp300@NetBSD.ORG
> Subject: Re: port-hp300/496: hp300 port panics after "reboot" 
> From: Jason Thorpe <thorpej@cs.orst.edu>
> Date: Sun, 25 Sep 1994 13:42:55 -0700
> 
> ...
> However, on all of my machines, I have pmap problems if I have 
> MAPPEDCOPY in the kernel config.  Also, all of 
> my 32 meg boxen (with the exception of the 433) are quirky...Like they 
> just `freeze', and occasionally panic with `out of address space', but it 
> always hangs during the dump or before ddb, so that's of no help.
> 
> Seriously, though...yank MAPPEDCOPY if you have it...
> 
I have never seen this in 4.4, but my job mix may be considerably different.
One thing is to make sure all the necessary pieces are there:

locore.s: code in copyin/copyout to divert to the mapped copy routines
vm_machdep.c: the actual mapped copy routines
machdep.c: a check in initcpu() to turn off mapped copy for the 320/350

You don't want this enabled for a 320/350 with a virtually-indexed cache
(setting up the extra kernel mapping to a page creates an alias which
requires cache flushing).

> 
> For my own personal edification (sp?), can someone please enlighten me on 
> just exactly what MAPPEDCOPY is supposed to accomplish?  Thanx in 
> advance...
> 
As Charles said, it avoids cross-address space copies by mapping the
user-mode side of a copyin/copyout into the kernel address space temporarily.
Somewhere, I have written down the results of some timings I did with and
without, and it made a significant difference (primarily for file IO from
the buffer cache).  However, after rummaging around, I cannot find the
piece of paper I wrote it all down on...

Another alternative to putting the kernel/user in the same address space
is to just keep all of physical memory mapped into the kernel.  There are
some words about this in TODO.hp300.