On 06/11/2021 19:32, Dave Froble wrote:
> On 11/6/2021 12:28 PM, Stephen Hoffman wrote:
>> On 2021-11-06 13:52:03 +0000, Robert A. Brooks said:
>>
>>> On 11/5/2021 7:52 PM, Rich Jordan wrote:
>>>
>>>> VSI found it, though there's still a mystery of sorts attached.
>>>>
>>>> The original system also has EIA-0 (and 1) NICs.  The EIA-0 is set
>>>> to 1Gbs full duplex, auto negotiation disabled, and the
>>>> corresponding Cisco port is set the same.
>>>
>>>> This is because they've had the system long enough that they
>>>> experienced the bad behavior between VMS and switches doing auto
>>>> negotiations in the dim past.
>>>
>>> Unless they are referring back to the mid-90's when the early PCI
>>> Ethernet adapters on Alphas were not-so-great, that info is a bit stale.
>>>
>>> VMS Engineering (specifically, the guy who's been writing our
>>> Ethernet drivers for over 30 years) has stated that auto-negotiate
>>> should always be used.
>>>
>>> If it doesn't work, he'll fix it, or determine that the switch is
>>> non-conforming to the standard.
>>
>>
>> That's been becoming the new policy since ~Y2K or so—though with some
>> wrinkles around Alpha and Itanium NICs—then GbE controllers and
>> late-era Fast Ethernet that are detected with auto-negotiate disabled
>> should generate an informational message at OpenVMS boot, in the logs,
>> when viewed within LANCP, and within the documentation. For important
>> network switch settings preferences, I'd be included to post driver
>> status information to end-users via SHOW DEVICE /FULL, and AMDS/AM, too.
>>
>> The distribution of this information—and of other analogous
>> recommendations for many other API choices available—has been
>> inconsistent, at best. An API with choices needs to have published
>> opinions, and best has diagnostics when the existing settings are
>> drifting out of current preferences. Y'all want us pesky customers to
>> move in certain shorter-term or longer-term directions, y'all need to
>> tell us that. WTFM, minimally. Displaying diagnostics is preferred.
>>
>> If y'all as developers don't have an opinion for an API or settings
>> choice, there shouldn't be an API or settings choice. And preferences
>> can shift over time, which means shifting our usages.
>>
>> Unfortunately for this and similar cases where the end-user really
>> intends to have a bogus setting—this because there's a busted switch
>> port or busted switch firmware or whatever—OpenVMS also lacks a means
>> to provide overt alert messaging and to then suppress the the overt
>> displays over time, moving the displays to status-related cases.  Such
>> as into LANCP, here. That'll probably require some updates to the
>> existing 1970s- and 1980s-era diagnostics and status-reporting
>> infrastructure.
>>
>>
>
> I've got to second this concept.  An example:
>
> With one exception, every VMS system I set up had one ethernet port.
> The exception
> is my AlphaServer 800, which had a 4 ethernet port card when I got it.
> After having
> problems, I pulled out the 4 port card and installed a DE500-BA single
> port card.
> Things worked, and I didn't look further.
>
> One of your fine support people mentioned to me:
>
> By default, DECnet Phase IV installation and configuration will enable
> DECnet protocol on all available interfaces on the system.  Once
> configured, the system administrator would want to go into NCP and purge
> all lines and circuits that are not needed from the database.
>
> I never knew that.
>
> When setting up DECnet, perhaps in NETCONFIG, or elsewhere, something
> could be mentioned about that issue.
>
> Just one example of how to make VMS more user friendly.
>
> And yes, I'm aware, the list of such "hints" could be quite extensive.
>

For some relatively brief period during the life of multi-port adapters
on PCI, and not just multiport network adapters, some PCI cards used PCI
to PCI bridges to provide multiple adapters on one card.

That introduced a whole load of fun for the affected adapters, as the
rules for configuring stuff behind a PCI bridge weren't particularly
clear at the time.

Pulling out your four port adapter and replacing it with a single port
adapter, in the AlphaServer 800 era, *might* have unknowingly fixed that
problem too.

Also, some systems used a PCI-PCI bridge on the *motherboard* to provide
an increased number of PCI slots. This is back in the days of e.g. Miata
and MiataGL and similar.

Back then, some considerable time ago, PCI-PCI bridges in general were a
bit of a challenge.

Nowadays the HYPErvisor presumably solves all this device support
weirdness, leaving just the DECnet bits to be sorted in your picture.

On 2021-11-06, Dave Froble <davef@tsoft-inc.com> wrote:
>
> If using a VM, the issue probably isn't. For "bare metal" (how did we ever
> come up with such an idiot name?) as mentioned elsewhere, x86 VMS will
> support a limited set of HW.
>

It's not an idiotic name, but you _clearly_ don't have any embedded
experience. :-)

It's from the embedded world and means application code that runs
directly on the hardware without any operating system between the
code and the hardware.

In the same way, it was extended to mean operating systems that run
directly on the hardware instead of under some hypervisor.

If you ever see a reference to an operating system running on
"bare metal" while the operating system is in fact running under
a hypervisor and not directly on the hardware, then that's the
marketing people playing idiotic word games to try and make their
solution appear to be something that it is not. Such people can
(and should) be ignored.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.