31 Oct
2005
31 Oct
'05
noon
Hi Guys,
Debee is depending on me to get this PDP-11 working for VCF this weekend
(she's speaking on Sunday!). I've got a 11/73 with 2.11BSD. The hardware
configuration is pretty typical - RQDX3, DEQNA, TK50, and one DZQ11.
Everything runs fine, but I need to install a second DZQ. The first DZQ has
csr 160100 and vector 300, so according to my calculations the second should
be at 160110 and vector 310. I set the switches, install the card, and then
edit my system configuration to change NDZ to be 2, rebuild the kernel,
reboot, and, .... Disappointment!
When it gets up to init, it says:
init: configure system
dz 0 csr 160100 vector 300 attached
ra 0 .... 172150 .... 154
tms 0 .... 174500 ... 260
... etc ...
nothing about the second DZQ. Everything else still works, including the
original DZQ11, and it boots up just fine except that there's no sign of the
second DZQ11.
I figured I made a mistake building the kernel, so I double check my
kernel configuration and yes, the file dz.h contains "#define NDZ 2". Just
to be safe I delete all the objects from my machine's configuration
directory and rebuild the entire kernel from sources (takes a couple of
hours on a 11/73!). Still no joy - init only finds one DZ... And I'm sure
I'm booting the new kernel because of the timestamp it prints out when you
boot it.
At this point I figured it's a hardware problem. Just to be sure, I
pulled out both DZQs and swapped the switch settings on the two cards. This
makes the original DZQ card now the "second" one at 160110/310 and the new
card the "first" DZQ at 160100/300. Put it all back together and boot it up
again - same results! Init finds the first DZ but not the second! Moreover,
all the serial ports on the back that are now connected to dz0 (which is the
card that used to be the second dz) still work! Of course, the ports on dz
1 (which is the card that used to work) are now dead. It seems like the two
DZQ11 cards must be OK.
Oh, and BTW, I even used the 11/73's console ODT to verify that all
addresses from 17760100 to 17760117 respond.
The only explanation I'm left with is a configuration problem. Is there
something I don't know about rebuilding the 2.11bsd kernel? Is 160110/310
the wrong location for the second DZQ11?
Thanks much, any suggestions are appreciated.
Bob Armstrong
31 Oct
31 Oct
12:15 p.m.
Bob,
At 9:00 AM -0800 10/31/05, Robert Armstrong wrote:
The only explanation I'm left with is a
configuration problem. Is there
something I don't know about rebuilding the 2.11bsd kernel? Is 160110/310
the wrong location for the second DZQ11?
I don't know BSD at all and can't verify the CSR/vector above without
looking some things up, but... on many Unix systems you need to make
the device files (/dev/tty???) that correspond to the terminal lines.
Has this been done? Although perhaps this needs to wait until init
sees the device?
John
12:25 p.m.
I don't know BSD at all and can't verify the
CSR/vector above without
looking some things up, but... on many Unix systems you need to make
the device files (/dev/tty???) that correspond to the terminal lines.
Has this been done? Although perhaps this needs to wait until init
sees the device?
Thanks, John - good point. I didn't mention it in my original posting,
but I already did this too. The script is called MAKEDEV and it creates the
/dev/ttynn nodes - in this case tty08..tty15. All the /dev/ttyxx entries
are there but none of them on the second dz work - they give "device not
configured" errors when you access them.
BTW, as far as I know it's tty08..tty15 because 2.11BSD thinks it's
talking to a DZ11 (i.e. UNIBUS, not QBUS) and DZ11 cards have eight lines
each. AFAIK it doesn't matter because the software interface for the DZ and
DZQ is the same except for the missing lines. Certainly there's nothing I
can find in 2.11BSD or 4.3BSD about a special driver or setting for DZQs
only.
So I would expect the first DZQ to be tty0..tty03 and the second one to be
tty08..tty11. In any case (as you said) I don't think it would prevent init
from configuring the device, but I might be wrong :-)
Thanks again,
Bob
3:52 p.m.
When I brought up my 11/44 with 2.11BSD I also had to fiddle with the
/etc/dtab file, which allocates CSRs/VECTORs to devices (ie, tells the
s/w what you did to the hardware). Your second DZQ is probably being
probed by s/w as a floating device (160070 ??) or at least not at the
address you have the h/w set to.
I had to change the /etc/dtab entry for my first DZ11 to 160100/300 from
160100/310 to be compatible with SIMH (I don't configure the TU58 at
176500/300 under SIMH and/or 2.11BSD).
Don North
Robert Armstrong wrote:
I don't
know BSD at all and can't verify the CSR/vector above without
looking some things up, but... on many Unix systems you need to make
the device files (/dev/tty???) that correspond to the terminal lines.
Has this been done? Although perhaps this needs to wait until init
sees the device?
Thanks, John - good point. I didn't mention it in my original posting,
but I already did this too. The script is called MAKEDEV and it creates the
/dev/ttynn nodes - in this case tty08..tty15. All the /dev/ttyxx entries
are there but none of them on the second dz work - they give "device not
configured" errors when you access them.
BTW, as far as I know it's tty08..tty15 because 2.11BSD thinks it's
talking to a DZ11 (i.e. UNIBUS, not QBUS) and DZ11 cards have eight lines
each. AFAIK it doesn't matter because the software interface for the DZ and
DZQ is the same except for the missing lines. Certainly there's nothing I
can find in 2.11BSD or 4.3BSD about a special driver or setting for DZQs
only.
So I would expect the first DZQ to be tty0..tty03 and the second one to be
tty08..tty11. In any case (as you said) I don't think it would prevent init
from configuring the device, but I might be wrong :-)
Thanks again,
Bob
4:47 p.m.
You're right - adding the second dzq11 to /etc/dtab fixes the problem.
Thanks!
Bob
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of Don North
Sent: Monday, October 31, 2005 12:52 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Need help configuring DZQ11s on 2.11BSD for VCF!
When I brought up my 11/44 with 2.11BSD I also had to fiddle with the
/etc/dtab file, which allocates CSRs/VECTORs to devices (ie,
tells the
s/w what you did to the hardware). Your second DZQ is probably being
probed by s/w as a floating device (160070 ??) or at least not at the
address you have the h/w set to.
I had to change the /etc/dtab entry for my first DZ11 to
160100/300 from
160100/310 to be compatible with SIMH (I don't configure the TU58 at
176500/300 under SIMH and/or 2.11BSD).
Don North
Robert Armstrong wrote:
MAKEDEV and
>I don't know BSD at all and can't
verify the CSR/vector
above without
>looking some things up, but... on many Unix
systems you
need to make
>the device files (/dev/tty???) that correspond
to the
terminal lines.
Has this
been done? Although perhaps this needs to wait until init
sees the device?
Thanks, John - good point. I didn't mention it in my original
posting, but I already did this too. The script is called it creates the /dev/ttynn nodes - in this case
tty08..tty15.
All the
/dev/ttyxx entries are there but none of them on
the second
dz work -
they give "device not configured" errors
when you access them.
BTW, as far as I know it's tty08..tty15 because 2.11BSD
thinks it's
talking to a DZ11 (i.e. UNIBUS, not QBUS) and DZ11
cards have eight
lines each. AFAIK it doesn't matter because the software
interface for
the DZ and DZQ is the same except for the missing
lines. Certainly
there's nothing I can find in 2.11BSD or 4.3BSD about a
special driver
or setting for DZQs only.
So I would expect the first DZQ to be tty0..tty03 and the
second one
to be tty08..tty11. In any case (as you said) I
don't think
it would
prevent init from configuring the device, but I
might be wrong :-)
Thanks again,
Bob
5:11 p.m.
So if I run sysgen is /usr/sbin I get:
donorth[208] sysgen
Type device names one per line, optionally followed
by a comma and a repeat count. Finish with EOF.
dz11,2
uda,1
tmscp,1
deqna,1
Table of standard DEC assignments for configuration:
DEVICE CSR VECTOR
-------------------------
DZ11 760070* 0300*
DZ11 760100* 0310*
UDA 772150 0154
TMSCP 774500 0260
DEQNA 774440 0120
CSRs and vectors marked '*' are in floating space.
So it looks like maybe the 2.11BSD autoconfig is only really finding
your second DZ11 and not the first?
Don North wrote:
When I brought up my 11/44 with 2.11BSD I also had to
fiddle with the
/etc/dtab file, which allocates CSRs/VECTORs to devices (ie, tells the
s/w what you did to the hardware). Your second DZQ is probably being
probed by s/w as a floating device (160070 ??) or at least not at the
address you have the h/w set to.
I had to change the /etc/dtab entry for my first DZ11 to 160100/300
from 160100/310 to be compatible with SIMH (I don't configure the TU58
at 176500/300 under SIMH and/or 2.11BSD).
Don North
Robert Armstrong wrote:
I
don't know BSD at all and can't verify the CSR/vector above
without looking some things up, but... on many Unix systems you
need to make the device files (/dev/tty???) that correspond to the
terminal lines. Has this been done? Although perhaps this needs to
wait until init sees the device?
Thanks, John - good point. I didn't mention it in my original posting,
but I already did this too. The script is called MAKEDEV and it
creates the
/dev/ttynn nodes - in this case tty08..tty15. All the /dev/ttyxx
entries
are there but none of them on the second dz work - they give "device
not
configured" errors when you access them.
BTW, as far as I know it's tty08..tty15 because 2.11BSD thinks it's
talking to a DZ11 (i.e. UNIBUS, not QBUS) and DZ11 cards have eight
lines
each. AFAIK it doesn't matter because the software interface for the
DZ and
DZQ is the same except for the missing lines. Certainly there's
nothing I
can find in 2.11BSD or 4.3BSD about a special driver or setting for DZQs
only.
So I would expect the first DZQ to be tty0..tty03 and the second one
to be
tty08..tty11. In any case (as you said) I don't think it would
prevent init
from configuring the device, but I might be wrong :-)
Thanks again,
Bob
4:12 p.m.
Robert Armstrong wrote:
Hi Guys,
Debee is depending on me to get this PDP-11 working for VCF this weekend
(she's speaking on Sunday!). I've got a 11/73 with 2.11BSD. The hardware
configuration is pretty typical - RQDX3, DEQNA, TK50, and one DZQ11.
Everything runs fine, but I need to install a second DZQ. The first DZQ has
csr 160100 and vector 300, so according to my calculations the second should
be at 160110 and vector 310. I set the switches, install the card, and then
edit my system configuration to change NDZ to be 2, rebuild the kernel,
reboot, and, .... Disappointment!
When it gets up to init, it says:
init: configure system
dz 0 csr 160100 vector 300 attached
ra 0 .... 172150 .... 154
tms 0 .... 174500 ... 260
... etc ...
nothing about the second DZQ. Everything else still works, including the
original DZQ11, and it boots up just fine except that there's no sign of the
second DZQ11.
I figured I made a mistake building the kernel, so I double check my
kernel configuration and yes, the file dz.h contains "#define NDZ 2". Just
to be safe I delete all the objects from my machine's configuration
directory and rebuild the entire kernel from sources (takes a couple of
hours on a 11/73!). Still no joy - init only finds one DZ... And I'm sure
I'm booting the new kernel because of the timestamp it prints out when you
boot it.
At this point I figured it's a hardware problem. Just to be sure, I
pulled out both DZQs and swapped the switch settings on the two cards. This
makes the original DZQ card now the "second" one at 160110/310 and the new
card the "first" DZQ at 160100/300. Put it all back together and boot it up
again - same results! Init finds the first DZ but not the second! Moreover,
all the serial ports on the back that are now connected to dz0 (which is the
card that used to be the second dz) still work! Of course, the ports on dz
1 (which is the card that used to work) are now dead. It seems like the two
DZQ11 cards must be OK.
Oh, and BTW, I even used the 11/73's console ODT to verify that all
addresses from 17760100 to 17760117 respond.
The only explanation I'm left with is a configuration problem. Is there
something I don't know about rebuilding the 2.11bsd kernel? Is 160110/310
the wrong location for the second DZQ11?
Thanks much, any suggestions are appreciated.
Bob Armstrong
According to the VMS configuration routine:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONFIGURE
DEVICE> RQDX3
%SYSGEN-I-EQV_NOTICE, equivalent name - device RQDX3 will be output as UDA
DEVICE> DEQNA
%SYSGEN-I-EQV_NOTICE, equivalent name - device DEQNA will be output as QNA
DEVICE> TK50
%SYSGEN-I-EQV_NOTICE, equivalent name - device TK50 will be output as TU81
DEVICE> dz11,2
DEVICE> Exit
Device: UDA Name: PUA CSR: 772150 Vector: 154 Support:
yes
Device: TU81 Name: PTA CSR: 774500 Vector: 260 Support:
yes
Device: QNA Name: XQA CSR: 774440 Vector: 120 Support:
yes
Device: DZ11 Name: TTA CSR: 760100* Vector: 300* Support:
yes
Device: DZ11 Name: TTB CSR: 760110* Vector: 310* Support:
yes
SYSGEN>
Which looks like you think it should. CONFIGURE only accepts
UNIBUS devices, so I'm assuming that the QBUS version of the
DZ is configured the same as the UNIBUS version.
iirc, the 11/73 has a simple boot console that has some commands
similiar to the VAX console commands. This is before you drop
to ODT. Normally you give it a "B du0" type of command.
(Been a while since I used real hardware, so ymmv)
Does the boot console (SHOW DEVICE?) display the devices?
5 p.m.
At 2:12 PM -0700 10/31/05, Kevin Handy wrote:
iirc, the 11/73 has a simple boot console that has some
commands
similiar to the VAX console commands. This is before you drop
to ODT. Normally you give it a "B du0" type of command.
(Been a while since I used real hardware, so ymmv)
Does the boot console (SHOW DEVICE?) display the devices?
It will depend on the board as to just how much info you're able to
get from the console on a PDP-11. The full quad-height board (which
seems to be much rarer), will have lots of features, and might be
able to give some info on the devices (it's been a couple years since
I did anything other than boot mine).
The more normal dual-height board will depend on the board with the
boot strap. As an example, my /73 originally used a dual-height
board, and I used a DLV11J for the console port, and a WQESD/04 for
the boot strap (even after I moved from ESDI to SCSI disks). With
that combo, I had a working system, but it provided no info, just a
bootstrap.
Zane
--
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
5:16 p.m.
It will depend on the board as to just how much info
you're able to
get from the console on a PDP-11.
About the best you can do with a PDP-11, even a fairly "modern" one like a
11/73, is to use console ODT to see if the device CSRs respond. I've never
seen a PDP-11 microcode or boot ROM with anything even close to "SHOW
DEVICE".
Bob
7:31 p.m.
Robert Armstrong wrote:
About the best you can do with a PDP-11, even a
fairly "modern" one like a
11/73, is to use console ODT to see if the device CSRs respond. I've never
seen a PDP-11 microcode or boot ROM with anything even close to "SHOW
DEVICE".
Bob
Actually, the quad wide board QBUS based 11 (53 (?), some 73, 83, 84,
93, 94) boot roms do have the Map command that does a pretty good job
of listing the addresses that are readable.
Example dump from my KDJ11-B microPDP-11/73:
Testing in progress - Please wait
Memory Size is 4088 K Bytes
9 Step memory test
Step 1 2 3 4 5 6 7 8 9
Message 04 Entering Dialog mode
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: MAP
15.206 MHz
CPU Options: FPA
Memory Map
Starting Ending Size in CSR CSR Bus
Address address K Bytes address type type
00000000 - 07777776 2048 17772100 ECC PMI
10000000 - 17757776 2040 17772102 ECC PMI
17760334 - 17760336
17765000 - 17765776 CPU ROM or EEPROM
17772100 - 17772102 Memory CSR's
17772150 - 17772152
17772200 - 17772276 Supervisor I and D PDR/PAR's
17772300 - 17772376 Kernel I and D PDR/PAR's
17772516 MMR3
17772520 - 17772522
17773000 - 17773776 CPU ROM
17774440 - 17774456
17777170 - 17777172
17777520 - 17777524 BCSR, PCR, BCR/BDR
17777546 Clock CSR
17777560 - 17777566 Console SLU
17777572 - 17777576 MMR0,1,2
17777600 - 17777676 User I and D PDR/PAR's
17777744 - 17777752 MSER, CCR, MREG, Hit/Miss
17777766 CPU Error
17777772 PIRQ
17777776 PSW
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key:
It shows the address ranges for devices that are not part of the
processor module but does not identify them.
-chuck
7:38 p.m.
On Monday 31 October 2005 14:16, Robert Armstrong wrote:
The closest thing is the MAP command from the boot PROM (11/73/83, etc.) - it
will identify all devices it finds in the I/O page map.
It will depend
on the board as to just how much info you're able to
get from the console on a PDP-11.
About the best you can do with a PDP-11, even a fairly "modern" one like
a 11/73, is to use console ODT to see if the device CSRs respond. I've
never seen a PDP-11 microcode or boot ROM with anything even close to "SHOW
DEVICE". From RT you can do a "show device"
From RSX MCR "DEV" or DCL "SHOW
DEVICES"
Cheers,
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
Mountain View, CA
http://bickleywest.com
"Black holes are where God is dividing by zero"
8:16 p.m.
>>>> "Lyle" == Lyle Bickley
<lbickley at bickleywest.com> writes:
> From RT you can do a "show device"
> From RSX MCR "DEV" or DCL "SHOW
DEVICES"
In RSTS, boot to the "start timesharing" prompt, and say "hardware
list".
RSTS uses floating CSR rules but doesn't care about floating vectors,
so if you have a vector wrong it still works, which may not help you
if another OS is pickier.
paul
6788
days inactive
6789
days old
11 comments
8 participants
participants (8)
-
ak6dn＠mindspring.com -
bob＠jfcl.com -
chd_1＠nktelco.net -
dundas＠caltech.edu -
healyzh＠aracnet.com -
kth＠srv.net -
lbickley＠bickleywest.com -
pkoning＠equallogic.com