Interesting. But why would everything fail just because you set the CSR
address manually? This is a mystery to me. As far as I can think, it
should still work just fine.
What else is simh doing, that happens differently depending on if it
autoconfigures things or not? I mean, after all, in the real world, you
*always* had to set the CSR addresses of all controllers manually.
You could try and follow the rules laid out by DEC for enabling OSes to
auto detect what hardware you had, but that was basically the main use
for it, and if you configured the software yourself, then that reason
also went out the window.
And finally, the actual address selected by the OP, was the correct one
according to the DEC configuration rules for the floating address space.
So unless simh does something wrong, it should end up with the same
address, based on the same configuration.
Curious to get some more details on this problem and solution... :-)
Johnny
On 2019-07-29 22:45, Hittner, David T [US] (MS) wrote:
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
