Hi!

As you may remember, I've reported problems when I merge 2MB of 16-bit
memory from a 2nd GVP SCSI controller with my main 4MB of 32-bit mem
on my GVP combo before loading NetBSD.  The problems are random memory
corruptions.  I've now got some more investigation done and would like
ideas on what my results may mean.

This is what I've found:

When running a program which suffers from the corruption problem
under GDB this instruction may incorrectly load, or possibly fail to load,
the high 16-bits of the longword:

movel a1@(4),d0

The longword to be loaded does not span over a page boundary, so
it can hardly be due to a pagefault halfway through the instruction,
can it?  Another strange fact, that makes me believe it's some
timing problem, is that if I set a breakpoint at the instruction, i.e.
before it's executed, in order to save the old d0 value, enabling me
to see if it's retaining the old high word, there will never be a
problem.  A few instructions earlier the word has already been
referenced twice with these instructions:

bftst a1@(5),0,24
moveb a1@(4),d0

As you can see both odd-aligned and bytewise references has been done.
Could this have anything to do with the problem.  What about the data-
cache?  When does NetBSD turn caches on, what caches are used?
Are there known problems with 030 caches enabled in GVP-accellerated
A2000s?

I have not seen any problems in AmigaDOS, but I haven't run a full
MMU map there, just Enforcer.  I don't remember what caches are enabled
there.

Please send in *any* ideas you can come up with.

Thanks

Niklas

PS.  I'm sending this mail through my NetBSD system filippa.appli.se
     with UUCP to my office.  Sendmail/UUCP works great!
     

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