[pups] Hardware config for 2.11BSD Installation on PDP-11/73
Steven M. Schultz
sms at moe.2bsd.com
Mon Feb 5 12:35:54 AEST 2001
> From: "Chuck Dickman" <chd at nktelco.net>
> What you described here makes sense and was my first impression of
> what should happen, but my experience is different.
I'm wondering if the console/boot firmware might not be the
cause of some of the confusion.
> My /etc/dtab is:
> ra ? 172150 154 5 raintr # uda50, rqdx1/2/3
> ra ? 160334 160 5 raintr # secondary mscp
Looks good. With 2.11 you can, if you want, leave the interrupt
vector as 0, the kernel will allocate an available vector and
tell the MSCP controller what vector to use.
> The CQD220 is at 172150 and the RXDX3 is at 160334. Is 172154 a valid
> MSCP address? It must be, cause it works for you. The docs I have
> show 160334.
As long as it doesn't conflict with anything else on the system it's
valid ;-) The system came with the RQDX3 and I worked with the RD54
for a while before adding the UC08 - when I added the UC08 I just picked
the next free CSR which happened to be 172154.
> DU8 and DU9 at boot are the RX50 drives on the second controller. The
> floppy in DU8 contains the installation standalone utilities that were
> part of the installation tape, including icheck.
> .83Boot from ra(1,0,0) at 0160334
> .: ra(1,0,0)/icheck
It probably doesn't hurt anything but I would leave off the '/'
> .ra(1,0,0) err op=89 sts=3
> .ra(1,0,0) !online
op=89 is the "ONLINE" command and a status of 3 means the unit didn't
go 'online'. That is very strange since 'boot' was obviously loaded
from the drive/controller.
What I am wondering now is: does the boot monitor pass 0 or 8 thru
as the unit number? If it's expecting 8 or 9 then that might be
the problem because boot and the 2.11 kernel only deal with 0 thru 7
> .: ra(0,0,0)/unix
> .Boot: bootdev=02400 bootcsr=0172150
> hk ? csr 177440 vector 210 skipped: No autoconfig routines.
> ht ? csr 172440 vector 224 skipped: No autoconfig routines.
> ra 0 csr 172150 vector 154 vectorset attached
> ra 1 csr 160334 vector 160 vectorset attached
Ok, that looks encouraging.
> # mount /dev/ra8a /mnt/rx0
> ra1: Ver 4 mod 3
> ra8 st=3 sb=0 fl=0 en=9
> /dev/ra8a on /mnt/rx0: Input/output error
> : not found
> : not found
> # mount /dev/ra9a /mnt/rx0
> ra9 st=3 sb=0 fl=0 en=9
> /dev/ra9a on /mnt/rx0: Input/output error
Same as before - the "online" command is failing for reason(s)
unknown as yet.
> I agree that it is pretty simple as you describe it and it is what I expected,
> but it does not seem to be as I see it here. Could the problem be that I am
> booting from the second controller? Should all the controllers be jumpered
I boot from the second controller all the time. If I weren't so
lazy (and the BA23 so narrow and hard to work in ;)) I'd have swapped
the UC08 and RQDX3 around a long time ago. As it is now I have to
hit ^C during the POST and at the BOOT> prompt I enter "172154 DU 0"
to boot from the second controller.
> for unit 0? Now that I think about it, it may be the boot firmware that is
Yes, if given a choice (and I don't know how this is done) all the
controllers need to start from 0. If the "base unit" of a controller
is 8 then I think the problem is that the controller is expecting
values such as 8, 9, etc in the 'mscp_unit' part of the MSCP packet.
That would explain the failure to "online unit 0" - the controller
is expecting to be told "online unit 8".
> controller's first disk, but I can from the second. So, I should set all the
> controller unit numbers to 0. The restriction is that the boot device
> must be visible to the firmware. Make sense?
Yes. I think the 'restriction' in this case is 2.11 - it doesn't
know how to deal with units other than 0 thru 7.
> Thanks for helping me work through this. It looks like the boot device
> must be within the first 8 devices that the firmware can see, but 2.11 BSD
> wants all the unit number jumpers set to 0.
Quite welcome! The boot monitor can load anything, but once 'boot'
(or the kernel) is loaded they do not know how to deal with unit=8.
sms at moe.2bsd.com
Received: (from major at localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA63034
for pups-liszt; Mon, 5 Feb 2001 14:23:08 +1100 (EST)
(envelope-from owner-pups at minnie.cs.adfa.edu.au)
More information about the TUHS