[TUHS] 2.9 kernel compile

[Jacob Ritorto]

..and here's another boot crash on the real machine:
Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
mem = 158720

CONFIGURE SYSTEM:
ra 0 csr 172150 vector 154 attached
xp ? csr 176700 vector 254 skipped:  No CSR
rl ? csr 174400 vector 160 didn't interrupt
dz ? csr 160110 vector 320 skipped:  No autoconfig routines
lp ? csr 177514 vector 200 skipped:  No autoconfig routines
ka6 = 2200
aps = 141572
pc = 50456 ps = 30250
__ovno = 7
trap type 11
panic: trap

On Wed, Feb 11, 2015 at 3:32 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> 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/6c80c3b6/attachment.html>