[cc: tech-kern for issues with mi kernel code]
In message <199903142326.SAA05413@snarf.thnet.com>, I wrote:
> I've been working on MI wscons Xserver support, and I've run into a
> problem.  -current kernels built back in Feb. are able to mmap the
> tga framebuffer, and access the memory, but the only thing that happens
> is the display goes reverse video.  No X background or cursor.
> Everything else seems to be working:  with xev I can verify that keyboard
> and mouse input work, but the framebuffer seems to be mapped wrong.
> After building a more recent kernel (today, Mar 14) framebuffer mmaps
> succeed, but touching any of the mapped memory bombs on a SEGV.
...(program illustrating problem and gdb session deleted)...
> Any ideas on why this doesn't work?

To answer my own question:  wsdisplaymmap is not allowing mmap access
to any display that has a text emulation.  wsdisplaymmap returns -1 and
somehow the vm system allows the system call mmap to succeed, but fail
on actual memory access.

summation - two problems:
	1.	Shouldn't wsdisplaymmap allow mapping under both text and
		graphics conditions?  It's perfectly reasonable to want to
		mmap the display on a tga regardless of any text emulations.
		In fact, a careful program could take advantage of this to
		mix text and graphics on the screen at the same time.  An X
		server will not work at all on a tga that happens to be the
		console.  This is bad - tgas don't have virtual terminals.

	2.	d_mmap() is never called at map time in uvm.  If it would
		return -1, the error can not propogate through the vm system
		to the user code mmap call.  Device mmaps will succeed and
		possibly fail later when they should have died an early
		death.  There was a recent discussion on tech-kern that
		touched on this:

> Message-Id: <199903061740.JAA29220@lestat.nas.nasa.gov>
> Subject: Re: mmap'ing framebuffer memory in MI drivers... 
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Sat, 06 Mar 1999 09:40:39 -0800
> 
> On Sat, 06 Mar 1999 09:34:28 -0800 
>  Jason Thorpe <thorpej@nas.nasa.gov> wrote:
> 
>  > BZZT :-)
>  > 
>  > That's the FAULT handler you're looking at.
>  > 
>  > Now, take a look udv_attach().
> 
> Gack.
> 
> I blame this on the fact that I haven't finished my first cup of coffee.
> 
> The Mach VM code definitely called d_mmap at mmap time, to check every
> possibly page in the mapping, to ensure that the fault handler would never
> fail.
> 
> UVM apparently doesn't do this.  I personally would prefer that UVM did
> the check at mmap time.
> 
> Chuck, is there a reason you didn't implement that?
> 
>         -- Jason R. Thorpe <thorpej@nas.nasa.gov>

Fix for problem #1:
--- src/sys/dev/wscons/wsdisplay.c	Sun Mar 14 07:17:24 1999
+++ wsdisplay.c	Sun Mar 21 11:46:30 1999
@@ -1057,9 +1057,6 @@
 
 	scr = sc->sc_scr[WSDISPLAYSCREEN(dev)];
 
-	if (!(scr->scr_flags & SCR_GRAPHICS))
-		return (-1);
-
 	/* pass mmap to display */
 	return ((*sc->sc_accessops->mmap)(sc->sc_accesscookie, offset, prot));
 #else

Fix for problem #2:
Should the interface to udv_attach change to pass more information about
the device mapping so it can call d_mmap, or should uvm_mmap just loop over
the page range calling d_mmap itself before calling udv_attach?

--Brett