[TUHS] 2.9 kernel compile

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Cory Smelosky <b4 at gewt.net>

    > Only the 11/23+ can, early rev 11/23s couldn't go above 256K.

Correctamundo on the last part, but not the first. I have both 11/23+'s and
11/23's, and I can assure you that Rev C and later 11/23's (the vast majority
of them) can do more than 256KB. See:

  http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/hardware/micronotes/1123.eco

for more.

	Noel

[TUHS] 2.9 kernel compile

[Dave Horsfall]

On Thu, 12 Feb 2015, Noel Chiappa wrote:

> I don't know about 2.9, maybe it knows about these. For V6, the SLR 
> won't be an issue; the SLR is an option on the 11/40, so not all 
> machines had it, and m40.s in V6 doesn't use it. The instruction restart 
> thing sounds like it will be an issue with running V6 on a /34.

I have no idea how, or even whether, I handled that...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] 2.9 kernel compile

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Thu, 12 Feb 2015, Jacob Ritorto wrote:

> found a copy here, 
> ithink.. https://github.com/eunuchs/unix-archive/blob/master/PDP-11/Bug_Fixe 
> s/V7_on11-34/unix_on_1134.txt

Yeah; I wrote that.  It originally appeared in an issue of AUUGN; don't 
know which one, as I haven't set myself up as a mirror for Minnie yet.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Noel Chiappa

    > apparently there are two differences between the 11/34 and 11/40, other
    > than the clock and switch register

Too early in the morning here, clearly... I was thinking of the 11/23 and the
11/40 here in the clock/SR comment, not the /34 and the /40.

_Iff_ the 11/34 is using the standard DL11-W console interface board (which
includes an LTC), there's no difference that I know of between the 11/34 and
the 11/40 on the LTC front (although the LTC is an option in the /40, so a /40
might not have one, in which case the V6 will panic on trying to boot unless
it has a KW11-P).

As for the switch register... I guess that on machines with a KY11-A, there
is no switch register? (Too lazy/busy to go read the manual(s) to confirm...)

	Noel

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Jacob Ritorto

    > found a copy here, i think..

Ah, thanks.

You might want to look around in the parent directory; apparently there are
two differences between the 11/34 and 11/40, other than the clock and switch
register: the stack limit register, and different handling of
segmentation-violation aborted instructions (which affects instruction
restart on stack extension).

I don't know about 2.9, maybe it knows about these. For V6, the SLR won't be
an issue; the SLR is an option on the 11/40, so not all machines had it, and
m40.s in V6 doesn't use it. The instruction restart thing sounds like it will
be an issue with running V6 on a /34.

	Noel

[TUHS] 2.9 kernel compile

[Jacob Ritorto]

found a copy here, i think..
https://github.com/eunuchs/unix-archive/blob/master/PDP-11/Bug_Fixes/V7_on11-34/unix_on_1134.txt

On Thu, Feb 12, 2015 at 8:47 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall <dave at horsfall.org>
>
>     > Read my paper on it :-)
>
> URL?
>
>         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/20150212/30780ed5/attachment.html>

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    > Read my paper on it :-)

URL?

	Noel

[TUHS] 2.9 kernel compile

[Dave Horsfall]

On Wed, 11 Feb 2015, Noel Chiappa wrote:

>     > 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.)

Read my paper on it :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Jacob Ritorto

    > I jiggled the memory board and the seqfault went away.

Ugh. A flaky. I hate those....

    > So now the real box is behaving more like the simh and just hanging,
    > not panicing anymore.

Does it _always_ hang at the same point in time? If so, what are the
circumstances, - have you just tried to start multi-user operation, or what?

    > How can I find this startup() you mention?

It's in machdep.c in sys/sys.

	Noel

[TUHS] 2.9 kernel compile

[Jacob Ritorto]

OK, I jiggled the memory board and the seqfault went away.  Which is weird
because I had all the boards out of this one, thoroughly vacuumed the
backplane and all boards and deoxidized the edge connectors before
reassembling.   So now the real box is behaving more like the simh and just
hanging, not panicing anymore.  How can I find this startup() you mention?

On Wed, Feb 11, 2015 at 4:14 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > I set simh to 11/34 and I managed to get actual panics before (that I
>     > didn't record)
>
> Ah.
>
>
>     > now I'm just getting hangs, mostly when hitting ctrl-D to bring
> system to
>     > mutiuser.
>
> The fact that it boots to the shell OK indicates things are mostly OK. I
> wonder what it's trying to do, in going to multi-user, that's wedging the
> system?
>
>     > Same if I mount -a in single user and then try to access /usr (works
> for
>     > a while, then hangs.).
>
> Ah. That sounds very much like a 'lost' interrupt. The process is waiting
> (inside the kernel) for the device to complete, and ..... crickets.
>
>     > When hung, I can still get character echo to my terminal
>
> So the machine is still running OK (most echoing is done inside the TTY
> interrupt handler).
>
>     >  but can't interrupt or background the running command, etc.
>
> Like I said, it's sleeping inside the kernel, and missed the wakeup event.
>
> If you have another console logged in, it would be interesting to see if
> that
> one is frozen too. If not, we can use tools like 'ps', running on the
> second
> line, to look at the first process and see what it's waiting for.
>
> Single user, the following hack:
>
>   sh < /dev/ttyX > /dev/ttyX &
>
> can be used to start a shell on another tty line (since going full
> multi-user
> seems to wedge it).
>
>     > Would it help if I traced memory and single-stepped through the
>     > (apparently) infinite loop?
>
> No, because it's very likely not a loop! ;-)
>
>
>     > 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):
>     >
>     >  CONFIGURE SYSTEM:
>     >  ka6 = 2200
>     >  aps = 141572
>     >  pc = 50456 ps = 30250
>     >  __ovno = 7
>     >  trap type 11
>     >  panic: trap
>
> That's a segmentation fault. Very odd trap to get! 2.9 uses overlays right?
> Maybe there's a problem with how some overlay fits, or something? I don't
> know
> much about the overlay feature, never used it, sorry.
>
> Most of the other data (PS address, PC, KDSA6 contents, etc) aren't much
> use
> without a dump.
>
>
>     > and another: plain boring old hang at boot when trying to size
> devices.
>     > Can't even echo characters this time.
>
> If the init process hasn't got as far an opening the TTY, you might not get
> character echoing.
>
> If that randomly lost interrupt got lost very early on, you might could see
> this sort of behaviour.
>
>
>     > One thing I think is interesting is that it's claiming 158720KW of
>     > memory. Is that weird? ...  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
>
> No idea where it's coming from, but remember Beowulf Schaeffer's advice to
> Gregory Pelton in "Flatlander".
>
> And now that I think about it, if the system thinks it has more memory
> than it
> actually does, that would definitely cause problems.
>
> Probably you should put some printf()'s in startup() and see where it's
> coming
> from.
>
>         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/f647ab2c/attachment.html>

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > From: Jacob Ritorto

    > I set simh to 11/34 and I managed to get actual panics before (that I
    > didn't record)

Ah.


    > now I'm just getting hangs, mostly when hitting ctrl-D to bring system to
    > mutiuser.

The fact that it boots to the shell OK indicates things are mostly OK. I
wonder what it's trying to do, in going to multi-user, that's wedging the
system?

    > Same if I mount -a in single user and then try to access /usr (works for
    > a while, then hangs.).

Ah. That sounds very much like a 'lost' interrupt. The process is waiting
(inside the kernel) for the device to complete, and ..... crickets.

    > When hung, I can still get character echo to my terminal

So the machine is still running OK (most echoing is done inside the TTY
interrupt handler).

    >  but can't interrupt or background the running command, etc.

Like I said, it's sleeping inside the kernel, and missed the wakeup event.

If you have another console logged in, it would be interesting to see if that
one is frozen too. If not, we can use tools like 'ps', running on the second
line, to look at the first process and see what it's waiting for.

Single user, the following hack:

  sh < /dev/ttyX > /dev/ttyX &

can be used to start a shell on another tty line (since going full multi-user
seems to wedge it).

    > Would it help if I traced memory and single-stepped through the
    > (apparently) infinite loop?

No, because it's very likely not a loop! ;-)


    > 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):
    >
    >  CONFIGURE SYSTEM:
    >  ka6 = 2200
    >  aps = 141572
    >  pc = 50456 ps = 30250
    >  __ovno = 7
    >  trap type 11
    >  panic: trap

That's a segmentation fault. Very odd trap to get! 2.9 uses overlays right?
Maybe there's a problem with how some overlay fits, or something? I don't know
much about the overlay feature, never used it, sorry.

Most of the other data (PS address, PC, KDSA6 contents, etc) aren't much use
without a dump.


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

If the init process hasn't got as far an opening the TTY, you might not get
character echoing.

If that randomly lost interrupt got lost very early on, you might could see
this sort of behaviour.


    > One thing I think is interesting is that it's claiming 158720KW of
    > memory. Is that weird? ...  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

No idea where it's coming from, but remember Beowulf Schaeffer's advice to
Gregory Pelton in "Flatlander".

And now that I think about it, if the system thinks it has more memory than it
actually does, that would definitely cause problems.

Probably you should put some printf()'s in startup() and see where it's coming
from.

	Noel

[TUHS] 2.9 kernel compile

[Jacob Ritorto]

..and here's another boot crash on the real machine:
\x7f\x7fBerkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
\x7f\x7fmem = 158720
\x7f\x7f
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
\x7f\x7faps = 141572
\x7f\x7fpc = 50456 ps = 30250
\x7f\x7f__ovno = 7
\x7f\x7ftrap type 11
\x7f\x7fpanic: 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>

[TUHS] 2.9 kernel compile

[Jacob Ritorto]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3712 bytes --]

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

\x7f\x7f\x7f\x7f\x7f40Boot
\x7f\x7f\x7f\x7f\x7f: ra(0,0)unix
\x7f\x7f\x7f\x7f\x7f
\x7f\x7fBerkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
\x7f\x7fmem = 158720
\x7f\x7f
CONFIGURE SYSTEM:
                      ka6 = 2200
\x7f\x7faps = 141572
\x7f\x7fpc = 50456 ps = 30250
\x7f\x7f__ovno = 7
\x7f\x7ftrap type 11
\x7f\x7fpanic: 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

\x7f\x7f\x7f\x7f\x7f40Boot
\x7f\x7f\x7f\x7f\x7f: ra(0,0)unix

\x7f\x7fBerkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
\x7f\x7fmem = 158720
\x7f\x7f
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

\x7f\x7fBerkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983
\x7f\x7fmem = 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>

[TUHS] 2.9 kernel compile

[Cory Smelosky]

On Wed, 11 Feb 2015, Noel Chiappa 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.

Only the 11/23+ can, early rev 11/23s couldn't go above 256K.

>
>    > 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
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] 2.9 kernel compile

[Noel Chiappa]

    > 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] 2.9 kernel compile

[Jacob Ritorto]

Hi,
  Since my Fuji160 drive is rather head-crashed, I've replaced it with an
M2333k, which is a smaller SMD rig with more sectors than the 160.
Unfortunately, after many dip switch settings and config changes, I have to
conclude that the sc21 just doesn't work with this new disk.

  I've plugged in my SC41 controller that speaks MSCP and supports the
M2333k correctly.  So now it's a matter of getting a unix small enough to
run on the 11/34 that can also speak MSCP.  Enter Jonathan Engdahl's
2.9bsd-MSCP.

  I managed to restor a root dump from his distribution and am able to
occasionally boot it on my 11/34, but it crashes very soon after booting
and I don't understand why. 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. Maybe
something to do with clock differences. Not sure. But I was thinking that I
could make it work by recompiling the kernel with 11/34 support.

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.

  So I switched the emulation back to '23, rebooted and edited the assym.s
file found in Jonathan's /usr/src/sys/RA directory. I changed
PDP11 = 23.
to
PDP11 = 34.

as well as

UNIBUS_MAP = 0
to
UNIBUS_MAP = 1

and recompiled with 'make unix,' then copied the resultant unix to /unix.

I switched simh back to emulating an 11/34 and rebooted. It crashes
randomly just as it did before the kernel recompile.

Any idea what I'm missing here? My hope was to simply move this
freshly-compiled 11/34-friendly kernel onto my real 11/34 and have a
working hardware system.

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/1758f162/attachment.html>