On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote:
First oddity - the problem is dependent on the location of the command in main
memory! If Fritz says "sleep 360 &", to run a trivial command in the
background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on
disk is OK)! We _think_ this is because the process executing the 'sleep'
takes up a chunk of main memory, and thus changes the location of the process
executing the 'ls'.
OK, the classic Heisenbug. Is this truly a fault given by
the memory management system, or some other kind of fault
(Unibus timeout or memory parity error)? If really related
to MMU, then maybe there is a bad bit in the MMU that is
causing it to reference the wrong segment entry or somehow
thinking the setting of that segment entry is invalid. Does
the MMU classify what the error condition was, or just
assume the trap handler can figure it out be looking at the
registers?
Anyway, is it possible to borrow an MMU from somebody else?
I can easily imagine that the diags can't test every
possible bit combination while the diags are ALSO running in
memory.
So, a somewhat cryptic bug could go undetected.
If this fault could be caused by memory, then it may be a
pattern-sensitive error, and ls is just the perfect pattern
to trip it up.
Jon
