>>>>> "Michael" == Michael L Hitch <osymh@gemini.oscs.montana.edu> writes:

Michael> On Mar 6, 11:51am, Charlie Root [Niklas] wrote:

Yeah, I forgot to log in to my non-root account, but that was the first
*real* mail I sent of from my NetBSD Amiga, where I'm almost always root.

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

Michael>   What was the address in a1?  I'm wondering if the long word
Michael> access is being made at an odd-word alignment.  Also, is the
Michael> access to 32 bit or 16 bit memory?

The a1 address varied from run to run, probably due to such misbehaviour
earlier in the process.  From what I recall (I have now unplugged the
16bit-mem, trying to build a sellable machine out of my 2nd A2000!) the
address were indeed odd-word aligned.  I did never check where the
physical location of the virtual address were, I didn't know howto,
short of putting some kernel hack in, which I didn't wanted to.  Is it
easily available provided the page is resident?  I guess it's possible
to read the maps through /dev/kmem but it seems to be a bit of work to
find out how.  Anyway I assume it was in the 16-bit mem, as plain
32-bit 4MB has always worked like a charm wrt this specific problem.
Well maybe it was in 32-bit mem but the kernel stack was in 16-bit
mem.  The high-order bits after the load was always found in some
other register, which could of course be coincidents.  I found the
timing question interesting, if I put breakpoints before the first
reference through a1 it would still fail at the point I was
examining, but if I put a breakpoint which just continued between
that reference and the point of examination, I never got a failure.
This could also be coincidental as the failure rate was about 50%,
but after 10 successful tests it's quite safe to say that the break-
point mattered.  What does this mean?  Well either the breakpoints
extra delay was the interesting fact, or maybe the entering of GDB
caused page replacements both at the entry and exit which changed
the behaviour.

I have tested the board both with and without the DTACK jumper to no
avail.  Where did you get the tip about this jumper from?  And what
does it mean?  I don't have but a german m68k reference, and I don't
understand tech-german very well :-)  Hell, I don't even understand
common german :-)

I haven't said anything earlier but I do have a 2088 bridgeboard
plugged in.  Could that board interfere in anyway?  I've always
thought not, but I'm getting paranoid....

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

Michael>   NetBSD should be running with both data and instruction
Michael> caches enabled on the 68030, as well as the burst enables for
Michael> both caches.

I've checked with kernels both with and without cacheing enabled
now, and there's no difference.

It would be nice to see this solved, but I'm getting real close
to put an ad in the local newspaper.  Well, if anyone comes up
with tests that may help to diagnose the problem I can postpone this
decision in order to execute them.  If that is what it takes to
improve an edge of NetBSD, so be it!

Niklas

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