PDP-11/45 RSTS/E boot problem

[Bob Smith]

I keep wondering about the psu. I just recall the /45 in my lab was
always a little flakey.
We suspected everything in the machine, and it was ak to chasing a sea
bat in the dark.
Our environment in ML 1-2 was not the best, the floor actually moved,
we were right at the mid building elevator.
We finally had the cpu backplane replaced and the problem went away.

On Mon, Feb 4, 2019 at 12:13 PM Jay Jaeger via cctalk
<cctalk at classiccmp.org> wrote:
>
> On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote:
> > 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
> >
>
> If he hasn't already, if Fritz has more than one memory board, he might
> try swapping them to see if that changes anything.
>
> The issue I'd see with the MMU swapout idea would be finding one that
> would be ECO-compatible with the rest of the processor.
>
> This sort of situation, where DEC diagnostics run OK but UNIX has issues
> was reported to be not all that uncommon - to the point where the urban
> legend was that some DEC FE's would fire up Unix V6 as a sort of system
> exerciser.
>
> Other things I might be tempted to try in order to coax more information
> out of the situation:
>
> 1.  Run the DEC system exerciser, if that has not already been done.
> 2.  Make a copy of ls, and see if the copy also fails
>     (different location on disk would mess with timing just a bit).
> 3.  Use SimH to build a pack image with an instance of ls that is not
>     pure text (no -n or -i flag)
> 4.  Use SimH to build an ls that does/does not start the data segment
>     for ls at 0 (has / does not have the -i flag) [I have not looked to
>     see how ls would normally be built.]
> 5.  Use SimH to gen a pack image with a kernel that is a not split I/D
>
> JRJ