Hi all; thanks for the write-up on the issue, Noel!
> On Feb 4, 2019, at 8:24 AM, Jon Elson via cctalk <cctalk@classiccmp.org>
> wrote:
> Is this truly a fault given by the memory management system, or some other
> kind of fault (Unibus timeout or memory parity error)?
Trap 250, which is explicitly memory management.
> Does the MMU classify what the error condition was, or just assume the trap
> handler can figure it out be looking at the registers?
The MMU classifies the error in register SR0; this decodes to a segment length
error (access within the segment beyond configured bound). As Noel notes,
however, this is not consistent with the instructions we see at the point of
fault.
> Anyway, is it possible to borrow an MMU from somebody else?
Potentially... It is a two board option; I do have a spare for both of the
boards, but these spares each are in need of other repairs at the moment.
One slightly complicating factor is that I have a *very* early 11/45. Most of
my boards (including the MMU boards), as well as my backplane, pre-date the
currently available schematics on bitsavers, etc., and there are no records
regarding which ECOs have been applied on my hardware. Thus my interest in
tracking down ECOs/FCOs... I've been picking my way through the list that Jay
recently posted, verifying by looking at the greenwires which FCO's I have
applied and which not. Its a bit painstaking.
> I can easily imagine that the diags can't test every possible bit combination
> while the diags are ALSO running in memory.
The "KT11-C Exerciser" diag is a pretty mean beast. It relocates itself around
memory, and is pretty thorough. It takes about 45 mins to work its way through
testing access to all memory from all segments in all processor modes. It uses
the line clock and terminal interface as a source of interrupts to check fault
behavior wrt. interrupts, etc. etc. This, and all the other KT11 diagnostics,
pass cleanly on the machine.
> OH, does this machine have a cache?
Nope, no cache.
One other thing of note, per the genesis of this thread, RSTS/E also has a
consistent failure at boot. As far as we got looking into that before jumping
tracks to V6 Unix, the symptoms there looked similar. Paul thought the
wreckage indicated a bad binary, but an image of the disk we were trying to
boot works fine under SIMH.
RT-11, being much more of a honey badger, just works :-)
--FritzM.
