[Simh] EXT :Re: Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94 system with 2 DEUNA ethernet device XUB not working

[Geoff Conway]

On Wednesday, 31 July 2019 22:02 Johnny Billquist wrote:

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

Yes agreed there is a bug - Mark earlier found what is missing - the ability to set the vector value in simh config for the XU/XUB device - there is a change needed to MTAB contents which basically enables the set xu(b) vector=xxx command.

> 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.
Agreed - they are the older cards if it has switchpacks for CSR and vector.
The DEUNA is an old card and while it has its VEC set by switchpack obviously it cannot have programmable (by OS) vector setting - that is reserved for certain.(read on for elaboration please) newer cards.
> 
> > 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.

There is a reason for mentioning the OS side of things and while in the real world the majority of PDP11 peripherals are set by switchpacks on the cards (been there done that) - the device code for that peripheral (if it's intelligent?) would (presumably) read those register values and load them into itself so it knows what addresses to respond to. In sysgen/netgen (whichever being relevant) the CSR/vector values for every peripheral are then manually entered by a human and the system/DECNet built. The human knows the rules for fixed floating csr/vec assignments for the various devices and their combinations and will decide on the values - although if autoconfig is enabled simh might set different floating values. Generally the simh config11 utility will provide a list of csr values for the overall configuration but it will not specify VEC vales for fixed(known) and floating. The human needs to come up with an overall list of assigned CSR/VEC values for all peripherals in the system.
In the majority of cases then simh will know both the csr and vector values of its peripherals with a few exceptions.

The 3 device exceptions I am talking about are in simh driver names the DEQNA (XQ/XQB) or WHA/WHB (DECNet DLX driver names as from con dis cont att command but derived from DECNet and configured in DECNet
The other 2 exceptions are the UDA50/KDA50 MSCP controllers with sim driver RQ/RQB with OS DUA/DUB controllers, as well as the simh TQ device (TK50 tape drive TMSCP controller) with OS driver name MUA.

In the main all of the other peripherals in simh Qbus config have their CSR/VEC known to simh and these are fed into the sysgen/netgen manually by a human. The human should decide the sysgen/netgen parameters based on which combination of peripherals are being used.

The 3 exceptions are all the 3 devices I included in my simh qbus configuration and when I entered the "show dev" command prior to booting the OS disk all of those simh devices had CSR values but no vectors - devices DEQNA=XQ/XQB; KDA50=RQ/RQB and finally TK50=TQ.
Prior to entering the OS they had <no vector> against them and after the OS was booted into a fully configured system and then finally shutdown those same 5 simh device then had their vectors assigned.

Why ?

Because according to Mark - " Actually only the "newer" devices have OS driver programmable vectors.  These include XQ (DEQNA/DELQA) and the RQ (MSCP-RQDX,UDA,...) and TQ (TMSCP).
All other devices had vectors either unchangeable or with switches on the board."

And because I am just so fortunate (sarcasm!) to have configured these 5 instances and observed their vector value being fed through the OS device driver TO simh devices I was aware of how their vectors were being filled.

The older devices clearly don't have that mechanism -which includes the DEUNA as yes the real device has switch packs for CSR and vector so the information flow there is from the card TO the OS for both CSR and vector. So obviously suggesting that was a mistake.

Other cards I have experience of (ACC X.25 card) I believe also had programmable vectors (yet to be confirmed) so while that mechanism certainly won't be in an older card like the DEUNA it is in the newer 
> 
> 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.
The only addresses I have seen DEQNA  show are the (preassigned) 174440 (XQ) and 174460(XQB) - which is set when they are each enabled. No other addresses available or relevant. But XQ/XQB also has programmable vectors (which I had already seen the evidence of.)
> 
> > 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 - apart from the 3 device exceptions

The only point of this paragraph was to (probably redundantly) explain that the bug associated with XUB also effected XU as currently XU simh device is missing the ability to manually set the vector as is XUB.
The OS vector assignments are a human deciding on based on the known "rules" and then entering values in sysgen and netgen that will be the same as configured simh values - with any simh <no vector> devices having a vector value entered in sysgen or netgen that is in accordance with the DEC fixed/floating vector assignments..

I have already agreed that XUB being an older device does NOT have programmable vectors it was an error to suggest otherwise as the DECNet WEA/WEB (for DEUNA in DECNet) would not include the code for programmable vector. So that option is not an option. However the other five device instances in my qbus simh config ALL have programmable vectors .

> 
See above - agreed not relevant for XU DEUNA as it is the older technology hardware.

> 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.
Of course it doesn't. The human sets the vectors - if they are a compatible set when they are loaded into sysgen/netgen and the resulting system built and booted all the vector values will be accepted as they are assigned by the appropriate driver. If the vector value chosen is wrong then when the assign vector attempt occurs it will be rejected. The human sets the hardware card in the real cases where the boards have vector switchpacks or where the device is an exception the vectors are defined by the human and only in those cases loaded into the equivalent simh device by a driver routine so that XQ/XQB/TQ/RQ/RQB simh devices will then be able to display their vector values. How else are those devices with <no vector> set prior to boot able to show dev and display their assigned vec values after the OS is shutdown and you are back to simh.

It is the human that decides what vector values to enter into the sysgen & netgen but the values already obtained from simh for most devices (excepting DEQNA/TK50/KDA50 - all of the CSR values should have come from simh as that is where they are either autoconfigured or set manually by a human.
All vectors (minus the exception devices) are loaded into sysgen/netgen - basically the same values you would load onto switchpacks or autoconfigured by simh
> 
> You are confusing how things happen.
> 
Unfortunately the 5 exception devices happen to all be in my system and their vectors are set by the human filling in the sysgen and netgen data - which are then (usually) assigned by the OS when the driver asks for that vector to be assigned. Usually it will be granted but if the human picks the wrong vector it may clash and the OS will reject the assignment request. I think that is how it works.
Now in most cases while the OS driver knows the CSR VEC values simh only knows about what addresses that have been assigned and for devices with switchpacks it will also know the vector value.

For the DEQNA TK50 & KDA50 they as mentioned previously have programmable vectors which allows the driver code to write to the low level simh driver for that device and write the vector value to the driver field containing the vector. The simh driver for the KDA50/UDA50, TK50 and DEQNA have to know the vector else the device won't be able to call the correct vector when the interrupt occurs. 
The other device get their CSR/VEC from their simh config as autoconfig or manually set by a human. In the real world the microcode within the peripheral will read the CS & VEC switchpacks and self-configure its registers to respond to the CSR address as well as setting itself to respond at the vector as well.

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

Except XQ/XQB/TQ/RQ/RQB simh devices

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


Been there done that x 36+ PDP11 systems

> 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.
> 
 And as long as the chosen addresses/vectors agree with fixed/floating device rules you should end up with a working environment. Get the CSR or vector wrong then the system may hang or even crash.
> 
> 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.
Which PDP11's had that feature ?- I can't recall seeing it in 11/94 system - but then we already had a long standing fixed/floating configuration when I updated the processor to the 11/94 (from 11/84). But then I doubt I would have looked for autoconfig as we wanted minimal changes with the upgrade to reduce risk of breaking the systems.
> 
> 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.
> 
 And that is what is recommended by Mark also as he found the missing element value in MTAB that would enable the set vector command for the DEUNA devices as it was meant to have.
> > 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.
> 

Already agreed DEUNA is too old for programmable vector assignment
Unlike XQ/XQB/TQ/RQ/RQB simh devices. The exceptions XQ/XQB/TQ/RQ/RQB simh devices do have programmable vectors and they were all the devices without vectors in simh. 
> > 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.

No sorry - we are talking about XQ/XQB the DEQNA Qbus ethernet controller. And in the OS under DECNet they are named WHA/WHB just so it is different. And QNA-0. QNA-1 in DECNet itself. WHA/WHB is from con disp cont att

And XQ/XQB you mentioned earlier while having a programmable vector has preset CSR addresses of 174440 & 174460 for the 2 devices and no way to set CSR (& no need) while the vector is as per the rules.

RQ/RQB is the name for the UDA50/KDA50 MSCP controllersin simh with DUA, DUB controllers in the OS.
> 
> > 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.
> 
The underlying issue was the missing vector for XUB - had both XU XUB been enabled without any address override they would have received valid CSR/VEC that would have matched the system. Of course a part auto/part manual config may end up unworkable - so this is not a good solution as enabling set vector is the appropriate answer.
> > 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 prefer manual configs - completely. Best way to manage the system especially when there are clashing priorities that autoconfig might break. I would like simh to behave completely like a real PDP-11 and allow all peripherals to be set how their real life device would behave - nothing more.
I was asked why I didn't use autoconfig as an answer to modding DUB vector assignment - I had missed that part of the PDP11 simh user guide else I might - but I prefer manual.
> 
> > 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.
The only source of CSR/vector values is the human that decides what they should be in accordance to DEC fixed/floating rules - as long as that produces a viable system configuration.
Having run the sysgen /netgen and had each driver request their assigned vector and been granted that vector - with the exception simh devices having programmable vectors XQ/XQB/TQ/RQ/RQB simh devices which are set by the OS driver mechanism that writes those vector values to the simh device driver so those exceptions know what their vectors are and as long as the OS grants the vector the system is ok. The human may also get it wrong too.
With every other device (in real world their csr/vec is set by switchpacks) they are set on each device and the controller on that board reads the switchpack and then knows to respond to the set CSR and use the assigned vector as interrupt.

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

I'll explain

At the start of the ini file for simh autoconfig by default is enabled.
The initial entries in that ini file did not set device addresses so autoconfig remained enabled until I hit the first set device address=xxxxx which happened to be for set XU address=17774510
So I had set xu enable
;;;XU gets enable with autoconfig address of 17774510 and vector=120
Set xu address=17774510
;;; XU address gets set to same value which also disables autoconfig
Set xub enable
;;; XUB device gets enabled with no csr and no vector
Set xub address=17760400
;;; XUB device now has CSR of 17760400 but still has no vector value due to autoconfig being disabled.

The rest of the system gets loaded and is in accordance with the rules but still with autoconfig disabled.
I then boot the OS, fill in the CSR/VEC values I have either supplied by simh when autoconfig was on or the manual csr/vec values.
I do the sysgen then the netgen and assign 176510/120 for XU and 160400/350 for XUB.

However - because XU & XUB device is an older card it needs to be either autoconfigured to set its vector as well as CSR
And due to the bug in pdp11_xu.c the XU and XUB devices are not allowed to set their vector values when autoconfig is disabled.

So I then boot the new system so that  all sysgen/netgen configured devices are loaded and enabled.

If I had shutdown the OS at that point I would immediately have realised what was wrong - because after shutdown and you are back at simh when you enter the command show dev it shows that device XUB still has no vector.

To fix the bug the vector modifier needs to be set in MTAB for XU/XUB and then set xub vector=350 added to the simh ini file would have fixed the issue.

So all the time device UNA-1 (or OS driver name WEB if you prefer) was sitting there without any vector which meant no driver routines would work as it was essentially stopped.

Had I not entered the set address command for XU as soon as XUB was enabled it would have loaded both a CSR and vector value by autoconfig and there never would have been an issue.

And it was only when I reversed the order of XU/XUB enablement that I found that XUB worked ok but then XU didn't.
I then identified that it was that XUB had no vector and I then raised Issue #731 - which Mark saw the ini file and also saw set xu address=17774510 entry and realised autoconfig was disabled that meant that XUB would not be assigned a vector.

The rest is having fixed the non assignment of a vector I was looking into what options I thought of (and some of them weren't suitable given that the DEUNA is historically a switchpack card -  forgetting how old the DEUNA was so no programmable vector assignment like my 5 other devices with <no vector> displayed prior to booting the OS disk. Namely XQ/XQB/TQ/RQ/RQB simh devices So a reasonable suggestion had the DEUNA been a much newer card but as its real life version has switchpacks and hence my unfortunate suggestion.

So the bug was not having the ability to set the vector values for both XU and XUB - due to a missing parameter in the modifier table with the XU simh device.
Once the new windows build has simh for pdp11.exe rebuilt with this code change - then total manual config for relevant devices in pdp11 simh will work.

> 
>    Johnny
> 
> >
> > Geoff
> >

Geoff
> > -----Original Message-----
> > From: Simh <simh-bounces at trailing-edge.com> On Behalf Of Hittner,
> > David T [US] (MS)
> > Sent: Tuesday, 30 July 2019 06:45
> > To: Mark Pizzolato - Info Comm <Mark at infocomm.com>
> > Cc: simh at 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-bounces at trailing-edge.com] On Behalf Of Johnny
> > Billquist
> > Sent: Saturday, July 27, 2019 6:30 PM
> > To: simh at 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 <paulkoning at comcast.net>
> >> *Sent:* Sunday, 28 July 2019 00:45
> >> *To:* Geoff Conway <gconway at bigpond.net.au>
> >> *Cc:* simh at 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 <gconway at bigpond.net.au
> >>      <mailto:gconway at 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 at trailing-edge.com <mailto:Simh at trailing-edge.com>
> >>      http://mailman.trailing-edge.com/mailman/listinfo/simh
> >>
> >>
> >> _______________________________________________
> >> Simh mailing list
> >> Simh at trailing-edge.com
> >> http://mailman.trailing-edge.com/mailman/listinfo/simh
> >>
> >
> 
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh