>  Michael Goryll <m.goryll@fz-juelich.de> wrote:
> 
>  > I experienced a similar beaviour to that described by Steve Peurifoy
>  > (see the link on Mike Wolfson's page). Running NetBSD 1.3.2 on a
>  > hp9000/345 (1024x768 lo-res display, 16MB RAM, SCSI disks) the X server
>  > works fine, except for the core dump when I quit or restart the server.
>  > When I changed to NetBSD 1.4.1 (generic kernel), the system crashed with
>  > a kernel coredump after killing the X server with Ctrl+Shift+Break. The
>  > following message appeared: "reboot after panic: AMAP_B2SLOT:invalid
>  > byte count". So the system crash seems to occur on (any?) sytem running
>  > the 1.4.1 kernel. 
> 
> Is this the 4.4BSD-derived NetBSD X server or the HP-UX X server?

The situation I've described is with the HP-UX 9.10 X server.  I assume
that Michael is also referring to some version of the HP-UX server.

> I have not been able to reproduce this on a NetBSD-not-quite-current system:

It was absolutely reproducible for me on 1.3H with the then optional
UVM config'd.  The panic message I saw was the same as noted above by
Michael.  The system no longer crashed when I tried it on the 1.4
release GENERIC kernel.  The panic is evidently subject to a certain
degree of unpredictability based on factors I can only guess at.

> ...I can only assume this was an MI UVM bug that's been fixed since the
> 1.4.1 release.

Maybe, but a look just above uvm_unmap() in src/sys/uvm/uvm_map_i.h
reveals:

/*
 *   U N M A P   -   m a i n   e n t r y   p o i n t
 */

/*
 * uvm_unmap: remove mappings from a vm_map (from "start" up to "stop")
 *
 * => caller must check alignment and size 
 * => map must be unlocked (we will lock it)
 */

The function grfunmap() in src/sys/arch/hp300/dev/grf.c passes its
argument (obtained from an ioctl() parameter) directly into uvm_unmap()
so constraint number 1 is violated.  I believe that if you boot a
debug kernel and set grfdebug appropriately you will find that the
HP-UX X server calls ioctl(fd, GCUNMAP, ...) with a decidedly
unaligned address at shutdown.  You can certainly call this a bug
in the server if you like but the kernel ought not choke on it.
Rejecting the ioctl() request if the address is not page aligned
is one quick-and-dirty solution.  A completely clean solution is
somewhat complicated as far as I can tell.

> I know it's been a while since there's been a snapshot.  If I can't find
> someone else to put one together soon, I'll try to get one built.  Then
> perhaps you could try NetBSD-current and see if the problem still exists
> for you.

You might get lucky but methinks there still be trouble lurking about...

-Steve