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.


Reply via email to