4 Feb
2019
4 Feb
'19
9:20 a.m.
Hi all; thanks for the write-up on the issue, Noel!
On Feb 4, 2019, at 8:24 AM, Jon Elson via cctalk
<cctalk at 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.