On 2019-07-31 05:18, Geoff Conway wrote:
I spent a few hours yesterday investigating how the XU, XUB and XQ, XQB devices
interact within simh with respect of having CSR and vectors assigned with or
without autoconfig enabled.
Unlike every other device the DEUNA XU & XUB behaviour in not auto-assigning the
vectors within simh as the OS assigns them appears to be inconsistent with every other
PDP device I've used so far in simh - and is the only device that won't work if
autoconfig has been disabled before their vector value has been autoconfigured in simh
as there is no way to manually assign the needed vector for either of XU & XUB.
If you cannot assign a vector, then there is a bug there.
Essentially, it is an absolutely requirement that you can set the
vector, if you are configuring manually, as that is what you'd do on the
real hardware.
In short, if you grab a real DEUNA or DELUA, there are two dip-switches
with 8 or 10 switches each. One is used to set the CSR, the other is
used to set the vector.
In comparison XQ & XQB devices set their simh vectors as they are assigned by
the PDP11 OS - in my case RSX11M-PLUS. While the OS drivers all include a mechanism
that passes that vector to the simh driver routine - relying on an XQ, XQB driver
routine to set the XQ, XQB vector values within simh.
First of all, disregard the PDP-11 OS aspect. That is not relevant here.
Second, the DEQNA/DELQA only have two fixed configurations on the real
hardware. You cannot set arbitrary CSR address or vector on them, so it
makes total sense that this cannot be set in simh either. You
essentially only have one switch on the real hardware to say if this is
controller #0 or controller #1. And that's it.
Whereas the XU &XUB ethernet devices can only have their vector values assigned when
auto-config is enabled which then assigns both CSR and vector values. whereas other devices
only auto-assign the CSR address and rely on the OS vector assignment toset the simh
vector within the simh driver routine. If autoconfig is disabled when XU &XUB are
enabled while their CSR values can be assigned manually their vectors cannot which means
that when we return to simh after shutting down the OS we will find that both XU & XUB
devices still do not have vectors associated with them.
The OS vector assignment have nothing to do with this. We're talking
about simh configuration. With the exception of devices which have
software configured vectors (UDA-50 being the one I can think of), it's
all set in simh, and any PDP-11 OS have nothing to do with this.
The PDP-11 cannot set, or even tell, what the expected vector should be.
It is set on dip switches on the hardware, and the OS merely expect
interrupts to happen at whatever vector you configure on the software
side, but the software do not have any way of telling the hardware what
vector is expected.
You are confusing how things happen.
In my case it was the manual assignment of XU CSR that disabled system wide
autoconfig - preventing XUB auto-vector assignment - but I have confirmed that by
setting the CSR address of another device before XU is enabled that neither of XU
& XUB will have their vectors assigned.
As XU &XUB are the only devices that require autoconfig (and there is no
override to re-enable autoconfig for just XU, XUB) then to eliminate this
inconsistency there are a few options:
I would not expect only ethernet to require this.
In the real world, *every* controller needs to have it's CSR address
programmed by dip switches or jumpers. simh just gives you a convenient
way of not having to do this step, which you always had to do on the
real hardware.
And almost every controller also required you to set the vector.
And for every controller, you then had to figure out the proper values
to use. For some controllers, DEC had a reserved address and vector for
the first controller, and most equipment was preconfigured for this from
DEC, so you didn't need to change anything if you only had that one device.
Finally you would install your OS. In the OS you then also had to
configure the system with the same information that you had already set
on all the hardware. Since a few controllers have predefined values for
the first controller, this was usually enough to bring up the initial
installation system, so you could then continue with the system
generation for the full system.
simh then have a feature where it will assign CSR addresse and vectors
automatically, according to the autoconfiguration rules DEC defined.
Using this, you do not need to manually configure each device in simh.
However, the obvious risk with this is that if you add a single device,
your whole system might stop working because lots of devices suddenly
change their address. Which is why in most real life situations, people
did not care about the DEC autoconfiguration rules.
They are nice, but not worth the effort.
If ethernet works any different than any other device inside simh, then
that would appear to be something funny.
1. it could be made possible to set vectors for XU, XUB manually with a "set XU(B)
vector=xxx" command. (The simplest solution?)
That would be the obvious, correct way of doing it.
OR
2. The XU, XUB device driver could be modified to assign the vector through to
simh as it is assigned by the OS. (the consistent approach)
simh have no idea how the OS assigns vectors.
OR
3.Exempt XU XUB autoconfig from being overridden - just like XQ, XQB address
assignment autoconfigure is always enabled as it is not possible to manually
assign CSR address values for XQ, XQB devices.
XQ is the name for the UDA-50/KDA-50, which actually should not have a
way of setting the vector in simh, just as there is no way of setting
the vector on the real hardware. That controller only have a way of
setting the CSR address on the hardware. The vector is programmed by the
PDP-11 during initialization of the controller.
OR
4. Workaround = Always ensure XU, XUB are enabled while autoconfigure is
enabled - preventing the problem from occurring.
Would be bad. There are a reason why it is possible to set in simh. If
you have a OS image which expects a different vector for the controller,
this solution would render it impossible to use the controller with the
OS image.
I'm notsure why it is expected that simh PDP device be autoconfigured always -
especially where it appears as though almost every PDP device will work
correctly without it - excepting where 2 DEUNA's are present.
You seem to think that autoconfigure does something more than it
actually do.
I started with simh mostly for nostalgic reasons - I worked with PDP11's between 1981 and
just prior to 2000 when they were phased out in favour of Unix hosts - and I treated the
simh pdp11 build as I would have when I built 11/24, 11/34, 11/84 and finally 11/94
systems with a mix of fixed and floating addresses and following the normal assignment
"rules" for CSR and vector assignment.
Those rules are one way of deciding what CSR address and vector to use
for each controller. However, the OS does not make use of these rules.
Or at least no RSX version do. RSX have fixed addresses for each
controller. RSX-11M-PLUS is nice in that it is at least possible to
change those addresses with a simple command. With RSX-11M, you will
have to do a new SYSGEN whenever you change anything.
Given a choice I would prefer that simh behaves more like a real PDP-11 and
also allow complete manual configuration - including both CSR and manual vector
assignment. Some of the current devices allow vector assignment most just
vector auto-assignment from the OS - with XU allowing neither in manual config
mode.
A complete manual configuration is, I believe, an essential requirement.
If I were to choose, I would have simh always be in that mode, and then
have a explicit command for simh to scan over what devices are enabled
and set addresses and vectors according to the autoconfiguration rules,
if someone wanted that.
Then it would be much more predictable what happens, and when.
(And then, yes, if you have the autoconfigure command, all CSRs and
vectors would be overwritten on all controllers. But then you asked for
just that.)
While it is not essential that the XU simh driver be modified to either
support manual vector assignment or for the simh XU routines to set their
internal vector based on the OS assigned value - either enhancement would be
helpful in it allowing continued manual address assignment of simh address
values for the PDP11.
You cannot set the address or vector based on the OS assigned values.
Those values are not visible to simh.
Being able to assign CSR address and vector values to the PDP11 peripherals and
then boot off a distribution disk and running a sysgen to build a complete
PDP11 RSX11M-PLUS system adds to the sense of achievement so fixing the simh XU
driver to fix this issue that breaks manual simh configs is preferred so as to
allow manual configs with DEUNA device(s) present. While I see value in simh
autoconfig I'd also like to still be able to fully manual config the simh PDP11
system just as the real PDP11 systems do.
I'm still not entirely clear what the problem you hit was, but anyway, I
think I've summed up now how I think things should work.
Johnny
Geoff
-----Original Message-----
From: Simh <simh-boun...@trailing-edge.com> On Behalf Of Hittner, David T [US]
(MS)
Sent: Tuesday, 30 July 2019 06:45
To: Mark Pizzolato - Info Comm <m...@infocomm.com>
Cc: simh@trailing-edge.com
Subject: Re: [Simh] EXT :Re: Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94
system with 2 DEUNA ethernet device XUB not working
This was a user configuration issue, where the user accidentally turned off
SIMH auto-configuration by explicitly setting an address/vector on another
device, which broke the XUB controller. The issue has been closed by the OP.
I took a look at the pdp11_xu.c code to see if I could spot any obvious
initialization errors without serious debugging, since I know that a double XU
configuration works correctly on a VAX780.
I actually _did_ find a coding error in pdp11_xu.c in my quick review, but it
makes no real difference, since the fields receive the correct value as the
code is currently written.
In the initialization of xub_reg[], there are two cut-n-paste defective lines:
{ BRDATA ( SETUP, &xub.setup, XU_RDX, 8, sizeof(xua.setup)), REG_HRO},
{ BRDATA ( STATS, &xub.stats, XU_RDX, 8, sizeof(xua.stats)), REG_HRO},
Which really should be initializing the 5th field using the sizeof() the XUB
structures rather the sizeof() the XUA structures:
{ BRDATA ( SETUP, &xub.setup, XU_RDX, 8, sizeof(xub.setup)), REG_HRO},
{ BRDATA ( STATS, &xub.stats, XU_RDX, 8, sizeof(xub.stats)), REG_HRO},
Mark P, could you peer review and make this simple change to pdp11_xu.c for me?
I see that the corresponding pdp11_xq.c initialization does not have this
cut-n-paste defect.
David
-----Original Message-----
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Saturday, July 27, 2019 6:30 PM
To: simh@trailing-edge.com
Subject: EXT :Re: [Simh] Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94
system with 2 DEUNA ethernet device XUB not working
Paul's point is actually fully relevant even if you do not bring up DECnet. In
RSX, this is a property already done at the CEX level. CEX knows the DECnet
address, and sets all ethernet controllers to the corresponding MAC address,
even if you do not run ethernet.
The actual MAC address you set in the simh configuration file is pretty much
irrelevant. It needs to be the MAC address corresponding to the DECnet address
you assign.
All that said, from what I've received from you in other mails certainly
suggest that there is some kind of problem in simh. The second ethernet
controller do not even start.
Johnny
On 2019-07-27 20:50, Geoff Conway wrote:
Hi Paul,
The main test environment I am using is with 1 PC with 2 ethernet
NIC’s each connected to a separate IP router – with one being on the
main Internet router with a 192.168.0.x subnet UNA-0 and the other
UNA-1 being on the private router with the 192.168.10.x subnet. This
hopefully should not be an issue in my case.
Thanks for the heads up though – and I will still need to check to see
if I can identify what MAC addresses XU, XUB do have – but as I have
confirmed that the NIC’s are on different segments I should be safe.
I also usually never ran up the DECNet software fully with just
loading the $CEX environment without starting DECNet Then the BQTCP
code connects to each device via ETHACP and initializes the IP
interfaces – so I usually never ran the DECNet Phase IV networking
software side of things as I didn’t have a second DECNet node to communicate
with.
When I couldn’t get anywhere with XUB I shutdown the unibus simh
environment and created the separate Qbus system – with the 2 x DEQNA
with just the $CEX subsystem loaded and with XQ, XQB loaded found that
both ethernet interfaces worked ok with the 2 x DEQNA’s.
It was only after I had created the 2 independent simh configs with
their own unique disk sets that I realized that they should be able to
communicate with each other through winpcap via attaching XU with eth6
(internet router) and XUB with eth5 (private lan router) with the qbus
simh system attaching XQ with eth6 and XQB with eth5 the 2 systems
overlaying the 2 system Network Interfaces under Windows 10 That was
done only as check to confirm the DECNet Phase IV networking comms was
fully working – and works with UNA-0, QNA-0, QNA-1 but not UNA-1. I
suspect that with only $CEX loaded in each simh RSX system that the
driver’s hard-coded MAC address applies with the XU and XQ drivers
each having unique MAC addresses (as do XUB and XQB) preventing the
duplicate MAC address problem occurring when on the same subnet.
If I restrict the unibus system to just loading $CEX (to activate the
ethernet interfaces (but not DECNet) and then startup the BQTCP
software with DEBUG enabled at separate times for each ethernet device
I should be able to at least work out what XUB is meant to be doing
versus what it is doing by comparing DEBUG from XU and XUB and maybe
identify the underlying issue.
As both ethernet interfaces are configured to be initialized at a
TCP/IP level acquiring an IP address lease via DHCP there should be an
initial sequence of almost identical messages for each of the XU, XUB
drivers which may provide a further clue to this puzzling issue.
Thanks for your help – you’ve given me another aspect of the drivers
that I need to check to see what MAC addresses each interface has in
this simh environment plusconfirm that this is not the cause of XUB
driver not working.
Regards
Geoff
*From:*Paul Koning <paulkon...@comcast.net>
*Sent:* Sunday, 28 July 2019 00:45
*To:* Geoff Conway <gcon...@bigpond.net.au>
*Cc:* simh@trailing-edge.com
*Subject:* Re: [Simh] Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94
system with 2 DEUNA ethernet device XUB not working
I haven't tried 2 UNA at all, and don't know RSX, but one thing to
watch out for: don't put two Ethernet interfaces on the same LAN if
you're running DECnet (Phase IV). The reason is that they will both
set the same Ethernet address, from the DECnet node address, so you
have a duplicate address condition. If both are connected to the same
LAN segment this will make for a mess; if they are connected to
different segments of a switched Ethernet then many packets will be
lost as the switches keep changing their mind about where that address is
located.
paul
On Jul 26, 2019, at 11:26 PM, Geoff Conway <gcon...@bigpond.net.au
<mailto:gcon...@bigpond.net.au>> wrote:
Hi All,
I have just raised an Issue in simh #731 where when recent testing
with a simh PDP11/94 Unibus system with 2 DEUNA interfaces it was
found that device XUB did not initialize. Device XU worked normally.
I have not yet been able have XUB start fully – no matter what
CSR/VEC combination I have tried. I believe the current CSR & VEC
are correct as they have been assigned – just that there appears
some internal disconnect within the XU driver where XUB channel just
does not do anything.
In the equivalent simh PDP11/93 Qbus system with 2 DEQNA both XQ,
XQB worked normally.
The details of the actual system configuration is in the Issues log.
With the absence of any messages from XUB it appears to be dead in
the water – although when running the simh environment with DEBUG
enabled in both XU, XUB I found that XUB stayed in
xu_process_local() while the XU device had a lot of activity – which
was expected since XU was working normally whereas XUB was not.
Unfortunately as I am not familiar with the XU driver code I have
not been able to determine why the xub interface is not initializing
correctly.
Regards
Geoff
_______________________________________________
Simh mailing list
Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
