> | Has anybody in this list suceeded in running the Xhpux server following the
> | instructions by Mike in http://fatmac.ee.cornell.edu/X11/ ?
> 
> I have Xhpux working.
> 
> I am typing at it right now.
> 
> The only problem is that it core dumps on exit.  Which, all things considered,
> is a minor problem.  So far, it's been utterly reliable.

I'm gonna take a wild guess that you haven't gone to UVM yet.  I too
ignored the segfault on exit until switching to UVM, at which point it
became a major problem, i.e. a kernel panic.  I don't know if this
happens with all graphics boards but it does occur with the 98550/A1416
and the HP-UX 9.0 X server.

I have a set of patches to grf.c/grfvar.h that fix this which I would
dearly love to send-pr if I could figure out how to traverse the
bureaucratic maze to get permission from my employer (HP).  Yes, this
is really silly, but bureaucracies are like that.

I will describe the problem though (since anybody willing to spend the
time could figure it out and there are comments in the existing grf.c
that allude to it).  If someone else puts in a fix before I can find
out who to get permission from, at least it will get fixed.  Y'all
might not like my solution anyway. :-)

HP-UX overloads the GCUNMAP ioctl() to do either of two things.  It
is called to unmap device registers/framebuffer that were previously
mapped with GCMAP and it's also used to unmap a user space locking
page that may have been mapped via a different path.  The HP-UX X
server attempts to map the locking page which fails on NetBSD.  This
is not a problem per se - X continues on its merry way.  The problem
is that when the X server exits it calls ioctl(fd, GCUNMAP, ...) with
some sort of internally generated locking page address, having not
obtained a "real" one from the driver (don't ask me why...).  This
address is passed into uvm_unmap() with seriously unpleasant results.
It should perhaps be noted that this is a point of attack independent
of the HP X server.

The solution I implemented keeps track on a per-process basis of what
address has been mapped via GCMAP.  A GCUNMAP request for any other
address is rejected with EINVAL.  The X server says to itself "OK fine."
and exits normally without further ado.

-Steve