OK, I recompiled again with PDP11 = 34. and UNIBUS_MAP = 0.

I set simh to 11/34 and I managed to get actual panics before (that I didn't record), but now I'm just getting hangs, mostly when hitting ctrl-D to bring system to mutiuser.  Same if I mount -a in single user and then try to access /usr (works for a while, then hangs.). 

 When hung, I can still get character echo to my terminal but can't interrupt or background the running command, etc.  Would it help if I traced memory and single-stepped through the (apparently) infinite loop?  

The real 11/34 runs like a top under regular 2.9 (on rl02).  Can't get it to do anything wrong; no panics, no hangs.

However, here are some examples of crashes on the real pdp11/34 (booting via vtserver, then bringing in system from the MSCP disk), with the original 2.9bsd-MSCP kernel (the one specifically built for 11/23): 

   Opened boot.dd read-write

 rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF

40Boot

: ra(0,0)unix

Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001

mem = 158720

CONFIGURE SYSTEM:

                      ka6 = 2200

aps = 141572

pc = 50456 ps = 30250

__ovno = 7

trap type 11

panic: trap

and another: plain boring old hang at boot when trying to size devices.  Can't even echo characters this time.

   Opened boot.dd read-write

 rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF

40Boot

: ra(0,0)unix

Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001

mem = 158720

CONFIGURE SYSTEM:

One thing I think is interesting is that it's claiming 158720KW of memory.  Is that weird?  The real 11/34 has 128KW and simh is set to 256.  Where's it getting that odd number?  Vanilla 2.9.1 on the real 11/34 boots with 

Berkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983

mem = 135872

On Wed, Feb 11, 2015 at 11:20 AM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

    > From: Jacob Ritorto

    > I think it's something to do with the fact that he compiled it to run on
    > an 11/23. Maybe it lacks unibus support.

No, the UNIBUS and QBUS appear (from the programming level) to be identical.
There are subtle differences (the /23 and its devices can address more than
256KB of memory, and some devices have minor differences between the QBUS and
UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
should be interchangeable.

    > Maybe something to do with clock differences.

Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
software-controllable clock, and when booting Unix on one, one has to leave
the clock switched off till UNIX is running - at least, for the early versions
of UNIX.)

    > I fired 2.9MSCP up in simh emulating an 11/23 and it works fine. Just to
    > corroborate my hardware experience of it on the '34, I switch the cpu
    > emulation to 11/34 and got a mostly identical crash sequence as with my
    > real hardware.

Ah. Now we're getting somewhere! If the simulator crashes in the same way, it's
not flaky hardware (my first guess as to the cause).

What are the symptoms (in as much detail as you can give us)? What, if anything,
is printed before it dies?

    > I changed ...
    > UNIBUS_MAP = 0
    > to
    > UNIBUS_MAP = 1

The /34 doesn't have a UNIBUS map.

    Noel

_______________________________________________
TUHS mailing list
TUHS@minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs