>>>>> "Olaf" == Olaf Seibert <rhialto@mbfys.kun.nl> writes:

Olaf> niklas@appli.se (Niklas Hallqvist) wrote:
>> The key is that an odd-aligned bitfield access which causes a
>> page-fault makes the page get incorrectly read from 16-bit mem.
>> Longword align the test, or use tstb or tstl, or don't force the
>> page to swap and you'll get by just fine.

Olaf> I seem to recall something from comp.sys.amiga.hardware a
Olaf> moderately long time ago that certain memory boards had problems
Olaf> with non-4-aligned access somehow. But my memory may not be
Olaf> accurate about that, nor may it be relevant.

It's much more to it than that.  I've ran odd-aligned mem-tests programs
and no problems.  I've done the odd-aligned bit-field op on a resident page
and no problems.  I've done an odd-aligned ordinary long-word and byte
test on a swapped page and no problems.  I've done aligned bit-field
tests on a swapped page without problems.  It has to be the combination:

A	Bit-field test AND
B	Odd-aligned data fetch AND
C	pagefault forced by the bit-field op AND
D	Merged 32- & 16-bit memory AND
E	My HW setup :-) at least it seems so...

I'd be interested in people who wants to try running my test ten or twenty
times or so.  Just remember to set the malloc sizes correct for your machine.
If it produces zeroes everytime don't bother to report the result, but if
it *once* returns a non-zero value, be sure to report your HW setup here!

Are ther any m68k gurus who can tell me how the bus-cycles looks like for
a bftst a1@(1){#0:#24} instruction?  Especially when there'll be a pagefault,
how will the trap frame look like.  I might put in kernel debugging for
this specific case in order to provide a workaround.  I wish I had a real
m68k reference manual...  Does anyone know of an online net reference or
how to get one for free from Motorola (tough luck, I suppose)?

Niklas

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