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

Tue Jul 30 23:18:22 EDT 2019

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.

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.

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.

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:

1. it could be made possible to set vectors for XU, XUB manually with a "set XU(B) vector=xxx" command. (The simplest solution?)
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)
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.     
OR
4. Workaround = Always ensure XU, XUB are enabled while autoconfigure is enabled - preventing the problem from occurring.

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. 

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.

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. 

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

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
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh