[TUHS] 2.9 kernel compile

[Jacob Ritorto]

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/88a4195d/attachment.html>