Ok, I've now done some more extensive debugging on the bitfield
operation failure.  I can now predict when the problem occurs.

*	Odd-aligned memory access AND
*	24-bit wide access (thus only bitfield-operations) AND
*	access causes a pagefault AND
*	access is from Zorro II memory

The problem is that the word ending on the odd address will get
incorrectly read if the read occurs soon after the aforementioned
access.  All other words on the faulted page seems quite correct
to me.  This happens even when caches are disabled.

These facts together make me think that the error must be in the
buslogic of GVP's accelerator.  It guess they have a two 16bit
registers which builds 32 bit data together when accessing 16bit
mem.  I also guess they use these as a cache, but that the high-
word of the cache doesn't get filled by a 24-bit odd-aligned
access.  Unfortunately it seems to still be valid.  Why do I think
this is the case?  Well, the bitfield operation succeeds, I have
never seen it behave incorrectly, BUT the next read, however
ordinary (longword-aligned plain movel)  that instruction is.  The
piece I cannot fit in, is why the pagefault is a trigger.  Maybe
the buslogic cache gets flushed and the next 24-bit access gets
associated to a randomly filled register, where it normally
wouldn't change the cache a bit.  I don't know... Does anyone
have any thoughts about my reasoning?

If this is the case, I guess a kludge could be written.  After an
successful vm_fault in trap() case T_MMUFLT: a read could be done
to the even-aligned word ending in the original odd address.  Then
should the cache (which existance is still purely a guess) get
correctly filled.

Now, I'm showing off my ignorance of the vm internals:  How do I
translate the user address to a kernel virtual address in trap()?
Must I map it first in some way?  Surely someone on this list knows...

Still, I'm looking for GVP tech-support on Email.  What kind of
computer company can't be reached via Internet today?  I cannot
afford call their BBS routinely, Phone would also be expensive.
Of course I could resort to FAX, but that's messy, as I have no
provision (yet) for sending & receiving FAX from home, where the
NetBSD computer is.

Niklas

Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas

------------------------------------------------------------------------------