Since a snapshot (or 1.4.2) might be around the corner,
please have also a look at the upgrade in miniroot.

There were some glitches in upgrading from 1.3.3. to 1.4.1
as posted by Rainer Buehl on Oct. 10th. Leaving aside the
X related thing, I also experienced the other problems he
reported. I can just recall now problems setting the timezone
but there where other problems too.
I just had to deal with those problems by escaping to sh and
fixing it.
If my memory serves it was related to the links being referred/created
at the wrong dir. Hope this helps,
Cheers,

Lazaro
-----Original Message-----
From: Steve Peurifoy <swp@alumni.rice.edu>
To: thorpej@nas.nasa.gov <thorpej@nas.nasa.gov>
Cc: port-hp300@netbsd.org <port-hp300@netbsd.org>
Date: 1. desember 1999 04:57
Subject: Re: HP X11R5 server and NetBSD 1.4.1


>
>>  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
>