On 4/7/24 9:30 PM, motk wrote:
> On 4/8/24 12:20, Arne Vajhøj wrote:
>
>> I consider it more likely that VMS and the CPU/virtual memory
>> environment your VM provide disagree on something causing
>> random sporadic memory related errors.
>
> It seems odd, I agree. This was running on an intel nuc with a 12th gen
> i5 cpu, and I wonder if openvms doesn't like straddling P/E cores.
>
> I've previously done some memory burn-in on that node without issues.
>
> I've migrated it over to a plain 6th gen node with 4 boring cores; lets
> see if that improves things.

I don't think 6th gen is supported is it? In any case, check your
host(s) with the Python script here:

https://vmssoftware.com/openkits/alpopensource/vmscheck.zip

On 2024-04-06, motk <meh@meh.meh> wrote:
> On 6/04/2024 7:39 pm, motk wrote:
>
>> Now I'll try and work out where dumpfiles go - I did turn on
>> SYSTEM_CHECK and write it to CURRENT so hopefully it's there somewhere.
>
> Yeah, nah, nothing in SYS$SYSTEM:SYSDUMP.DMP.
>

It could be in the pagefile (or VSI may have disabled dumps on this
image they are now shipping.)

Here is a writeup from the VSI Wiki you should find useful and which
will guide you through the various possibilities:

https://wiki.vmssoftware.com/Dump_File

BTW, I am surprised by the lack of answers to this question over the
weekend before I got to see it just now. In the old days, there would
have been a lot of answers to your question (and to my other technical
questions) by now. People still complain about the off-topic stuff, but
when there's a series of good technical questions, there are no longer
any answers to them.

I wonder if the VMS online community has finally collapsed and there
are only a few people left.

Simon.

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

On 2024-04-07, motk <yep@yep.yep> wrote:
> On 4/6/24 19:50, motk wrote:
>
> Everything is going great.
>
> $ help analyze
>
> Improperly handled condition, bad stack or no handler specified.
> Signal arguments: Number = 0000000000000005
> Name = 000000000000000C
> 0000000000000004
> 00000000000007D8
> FFFF830007C02367
> 0000000000000012
> Register dump:
> RAX = 000000007FF9DC80 RDI = 000000007FF9DC80 RSI = 00000000000007D8
> RDX = 0000000000000000 RCX = 00000000000007D8 R8 = 00000000FFFF8F84
> R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9E4A0
> R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C648
> R13 = 0000000000000018 R14 = 000000007FF9C800 R15 = 0000000000008301
> RIP = FFFF830007C02367 RSP = 000000007FF9E440 SS = 000000000000001B
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
> address=000000000000000C, PC=0000000000000002, PS=7AD44D2F
>

Executive mode again (_if_ I am reading the PS register correctly and if
the current mode bits are in the same place as on Alpha.)

I wonder if RMS (or the XQP) has managed to corrupt your disk somehow.

Can you make the system disk available to a second instance and run an
$ anal/disk on it from that second instance ?

Simon.

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

On 2024-04-07, motk <yep@yep.yep> wrote:
> On 4/8/24 12:20, Arne Vajhøj wrote:
>
>> I consider it more likely that VMS and the CPU/virtual memory
>> environment your VM provide disagree on something causing
>> random sporadic memory related errors.
>
> It seems odd, I agree. This was running on an intel nuc with a 12th gen
> i5 cpu, and I wonder if openvms doesn't like straddling P/E cores.
>
> I've previously done some memory burn-in on that node without issues.
>
> I've migrated it over to a plain 6th gen node with 4 boring cores; lets
> see if that improves things.
>

It's still a VMS bug (even if VMS is being _way_ too fragile) IMHO.

IIRC, motk is using proxmox, which many other people are using just fine
to run other operating systems.

If there's something VMS needs or a configuration it doesn't support,
then that should be probed at boot time and VMS should refuse to continue
booting with the reason why been made clear. The bug in this case is that
this check is missing from VMS.

The other possibility is that VMS is _supposed_ to work OK in this
configuration, but this specific VM setup has been untested by VSI until
now. That means there is a bug in the VMS code itself which needs fixing.

Simon.

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

On 4/8/2024 8:34 AM, Simon Clubley wrote:

> If there's something VMS needs or a configuration it doesn't support,
> then that should be probed at boot time and VMS should refuse to continue
> booting with the reason why been made clear. The bug in this case is that
> this check is missing from VMS.

That's one way to look at it.

Another way is that we have been quite clear what the requirements are to run VMS.

Any variation from that is unsupported. We recognize that there are likely configurations
that are technically unsupported, but will still likely work. Preventing those
configurations from working is someething we could do, but chose not to.

> The other possibility is that VMS is _supposed_ to work OK in this
> configuration, but this specific VM setup has been untested by VSI until
> now. That means there is a bug in the VMS code itself which needs fixing.

We are not claiming support for Proxmox, although that testing has begun.
Given that it is a KVM-based hypervisor, getting it fully supported should not
be difficult, but we're not there yet.

It is for these reasons that we've been quite conservative about what is supported.

We are interested in any feedback we get, but that doesn't mean we're going to respond to every
problem immediately when it's an unsupported configuration.

--
-- Rob

On 2024-04-08, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 4/8/2024 8:34 AM, Simon Clubley wrote:
>
>> If there's something VMS needs or a configuration it doesn't support,
>> then that should be probed at boot time and VMS should refuse to continue
>> booting with the reason why been made clear. The bug in this case is that
>> this check is missing from VMS.
>
> That's one way to look at it.
>
> Another way is that we have been quite clear what the requirements are to run VMS.
>
> Any variation from that is unsupported. We recognize that there are likely configurations
> that are technically unsupported, but will still likely work. Preventing those
> configurations from working is someething we could do, but chose not to.
>

Given that the VMS mindset is supposed to be one of robustness and
reliability, perhaps the proper approach is to enforce a default refuse
to boot on unsupposed configuration, but allow an override with a boot
flag or SYSGEN parameter.

That way, people don't accidentally use an unsupported configuration in
production use, but you also don't stop people from using an unsupported
configuration if they choose to do so.

However, if you implement this, an impossible to miss message should be
output on every boot so that the flag is not set and then forgotten about.

Simon.

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

On 2024-04-08, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2024-04-08, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>> On 4/8/2024 8:34 AM, Simon Clubley wrote:
>>
>>> If there's something VMS needs or a configuration it doesn't support,
>>> then that should be probed at boot time and VMS should refuse to continue
>>> booting with the reason why been made clear. The bug in this case is that
>>> this check is missing from VMS.
>>
>> That's one way to look at it.
>>
>> Another way is that we have been quite clear what the requirements are to run VMS.
>>
>> Any variation from that is unsupported. We recognize that there are likely configurations
>> that are technically unsupported, but will still likely work. Preventing those
>> configurations from working is someething we could do, but chose not to.
>>
>
> Given that the VMS mindset is supposed to be one of robustness and
> reliability, perhaps the proper approach is to enforce a default refuse
> to boot on unsupposed configuration, but allow an override with a boot

s/unsupposed/unsupported/

Oops. :-)

> flag or SYSGEN parameter.
>
> That way, people don't accidentally use an unsupported configuration in
> production use, but you also don't stop people from using an unsupported
> configuration if they choose to do so.
>
> However, if you implement this, an impossible to miss message should be
> output on every boot so that the flag is not set and then forgotten about.
>

Simon.

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

On 4/8/24 22:18, Craig A. Berry wrote:

> I don't think 6th gen is supported is it?  In any case, check your
> host(s) with the Python script here:

Depends on what you mean by 'supported', unless there's some very odd
microcode or msr setup that needs to be done so long as it meets cpu
criteria, it should Just Work. We're in an age of commodity COTS
hardware now.

> https://vmssoftware.com/openkits/alpopensource/vmscheck.zip

All my hardware checks out using the vmscheck.py script.

--
motk

On Tue, 9 Apr 2024 10:05:59 +1000, motk wrote:

> We're in an age of commodity COTS hardware now.

Remember that x86 is not exactly an “open standard”--it is very much
controlled by proprietary vendors who never cease their search for that
vendor-lock-in edge.

Just because you have been pampered by the ongoing efforts of OS
developers in the Linux community and elsewhere to ensure that things
“just work” doesn’t mean it’s something you can take for granted.

On 4/8/24 22:27, Simon Clubley wrote:

[ ... ]

n (_if_ I am reading the PS register correctly and if
> the current mode bits are in the same place as on Alpha.)
>
> I wonder if RMS (or the XQP) has managed to corrupt your disk somehow.
>
> Can you make the system disk available to a second instance and run an
> $ anal/disk on it from that second instance ?

Sounds like a plan, I'll give it a go.

--
motk

On 4/9/24 10:18, Lawrence D'Oliveiro wrote:

> Remember that x86 is not exactly an “open standard”--it is very much
> controlled by proprietary vendors who never cease their search for that
> vendor-lock-in edge.
>
> Just because you have been pampered by the ongoing efforts of OS
> developers in the Linux community and elsewhere to ensure that things
> “just work” doesn’t mean it’s something you can take for granted.

Yeah, good point. That said, even if it's not an open standard with a
fixed system architecture, you have things like the x86-64 cpu
micro-arch feature levels to work with, eg
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html. Making the
supported versions narrow enough to not burden development but not so
narrow that it discourages use and therefore discovering interesting
bugs isn't an easy job.

--
motk

On 4/8/24 22:11, Simon Clubley wrote:
> On 2024-04-05, motk <meh@meh.meh> wrote:

>> I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
>> now.
>>
>
> Is there anything in the error log ?

I was trying to check that when it carked it last time :)

--
motk

On 4/8/2024 12:49 PM, Robert A. Brooks wrote:
> On 4/8/2024 8:34 AM, Simon Clubley wrote:
>> If there's something VMS needs or a configuration it doesn't support,
>> then that should be probed at boot time and VMS should refuse to continue
>> booting with the reason why been made clear. The bug in this case is that
>> this check is missing from VMS.
>
> That's one way to look at it.
>
> Another way is that we have been quite clear what the requirements are
> to run VMS.
>
> Any variation from that is unsupported.  We recognize that there are
> likely configurations
> that are technically unsupported, but will still likely work.
> Preventing those
> configurations from working is someething we could do, but chose not to.
>
>> The other possibility is that VMS is _supposed_ to work OK in this
>> configuration, but this specific VM setup has been untested by VSI until
>> now. That means there is a bug in the VMS code itself which needs fixing.
>
> We are not claiming support for Proxmox, although that testing has begun.
> Given that it is a KVM-based hypervisor, getting it fully supported
> should not
> be difficult, but we're not there yet.
>
> It is for these reasons that we've been quite conservative about what is
> supported.
>
> We are interested in any feedback we get, but that doesn't mean we're
> going to respond to every
> problem immediately when it's an unsupported configuration.

I think the current practice makes sense.

It should be obvious that running an unsupported configuration
comes with a risk of problems.

It makes sense to have VMS complain about configs that are
known not to work.

But I think it would be very problematic with VMS complaining
over configs that are not known to work.

Because removing that test would require a release.

We would see:

....
VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
...

No thanks.

Arne

On Mon, 8 Apr 2024 21:00:26 -0400, Arne Vajhøj wrote:

> Because removing that test would require a release.

You don’t have the concept of “volatile” package updates? Like the
timezone database, which changes several times a year?

On 9/4/24 02:49, Robert A. Brooks wrote:

> We are not claiming support for Proxmox, although that testing has begun.
> Given that it is a KVM-based hypervisor, getting it fully supported
> should not
> be difficult, but we're not there yet.

It's basically vanilla kvm-qemu. People aren't trying to run it in
nested emulators on an FPGA or anything.

--
motk

On 9/4/24 11:43, Lawrence D'Oliveiro wrote:
> You don’t have the concept of “volatile” package updates? Like the
> timezone database, which changes several times a year?

It sounds like it's going to be a yearly build and then thrown over the
fence? Surely not.

--
motk

On 2024-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> But I think it would be very problematic with VMS complaining
> over configs that are not known to work.
>
> Because removing that test would require a release.
>
> We would see:
>
> ...
> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
> ..
>
> No thanks.
>

It does not have to be a release - it could be a patch. It is also
absolutely no different from in the past when a new version of VMS
used to add support for new CPUs from DEC.

IOW, my suggested approach is a very long-established part of the
VMS world. The only difference now is that VMS would be allowed to
continue booting if you set an override flag or SYSGEN parameter.

Also, there should be no need to add support for "VM Bar 4" unless
it brought new functionality over "VM Bar 3" that you wanted to
support in VMS.

VMS is used in mission-critical production environments. You should
not be allowed to accidentally boot into an unsupported configuration
without being made _VERY_ aware of that fact.

Simon.

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

On 2024-04-09, motk <yep@yep.yep> wrote:
> On 9/4/24 02:49, Robert A. Brooks wrote:
>
>> We are not claiming support for Proxmox, although that testing has begun.
>> Given that it is a KVM-based hypervisor, getting it fully supported
>> should not
>> be difficult, but we're not there yet.
>
> It's basically vanilla kvm-qemu. People aren't trying to run it in
> nested emulators on an FPGA or anything.
>

That's what makes the dramatic failure you are seeing even more surprising.

Simon.

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

On 4/9/2024 8:45 AM, Simon Clubley wrote:
> On 2024-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But I think it would be very problematic with VMS complaining
>> over configs that are not known to work.
>>
>> Because removing that test would require a release.
>>
>> We would see:
>>
>> ...
>> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
>> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
>> ..
>>
>> No thanks.
>
> It does not have to be a release - it could be a patch.

True.

But I don't like:
....
VMS 9.2-2 with HW patch 41
VMS 9.2-2 with HW patch 42
....

either.

> It is also
> absolutely no different from in the past when a new version of VMS
> used to add support for new CPUs from DEC.

Correct. This is the mechanism used in the past.

But the context has changed. Instead of DEC releasing a few new
models every year, then we have an huge number of VM, VM version,
host, host version combos.

H1..H4 is fine. H1..H100 is a problem.

> IOW, my suggested approach is a very long-established part of the
> VMS world. The only difference now is that VMS would be allowed to
> continue booting if you set an override flag or SYSGEN parameter.
>
> Also, there should be no need to add support for "VM Bar 4" unless
> it brought new functionality over "VM Bar 3" that you wanted to
> support in VMS.

????

The interest in different VM's is not driven by what VMS need,
but from what customers want.

> VMS is used in mission-critical production environments. You should
> not be allowed to accidentally boot into an unsupported configuration
> without being made _VERY_ aware of that fact.

Hopefully those running a mission critical production environment
on VMS read about supported configs before moving production to
that config and never runs it in anything accidentally
booted.

Arne

On 4/9/2024 1:35 AM, motk wrote:
> On 9/4/24 11:43, Lawrence D'Oliveiro wrote:
>> You don’t have the concept of “volatile” package updates? Like the
>> timezone database, which changes several times a year?
>
> It sounds like it's going to be a yearly build and then thrown over the fence?
> Surely not.
>

In the interest of disapproving the use of assumptions (ASS U ME), I'd guess
nobody yet knows what is going to happen. Perhaps even VSI!

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 4/9/2024 8:45 AM, Simon Clubley wrote:
> On 2024-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> But I think it would be very problematic with VMS complaining
>> over configs that are not known to work.
>>
>> Because removing that test would require a release.
>>
>> We would see:
>>
>> ...
>> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
>> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
>> ..
>>
>> No thanks.
>>
>
> It does not have to be a release - it could be a patch. It is also
> absolutely no different from in the past when a new version of VMS
> used to add support for new CPUs from DEC.
>
> IOW, my suggested approach is a very long-established part of the
> VMS world. The only difference now is that VMS would be allowed to
> continue booting if you set an override flag or SYSGEN parameter.
>
> Also, there should be no need to add support for "VM Bar 4" unless
> it brought new functionality over "VM Bar 3" that you wanted to
> support in VMS.
>
> VMS is used in mission-critical production environments. You should
> not be allowed to accidentally boot into an unsupported configuration
> without being made _VERY_ aware of that fact.
>
> Simon.
>

But hasn't the discussion been about the CL stuff? I don't think CL and mission
critical co-exist. I'm sure VSI doesn't think that.

As for due diligence, when did that go away? Any reasonable customer would
check, and re-check, that they are using supported stuff.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/4/24 10:48, Dave Froble wrote:

> In the interest of disapproving the use of assumptions (ASS U ME), I'd
> guess nobody yet knows what is going to happen.  Perhaps even VSI!

If the latter, that'd be a worry! Hard to tell though, not a lot of
communication happening.

--
motk

On 9/4/24 11:00, Arne Vajhøj wrote:

> We would see:>
> ...
> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7

Just looking at the supported hardware/virtualization environments on
https://vmssoftware.com/about/v92/ and noting a couple of things:

There's no actual 'supported' list, only 'tested'.
The latest tested QEMU version is 5.2.0, from 2020.
The list of 'tested' virt environments is pretty baroque and I wonder
how it's tested.

> No thanks.

In practical terms, you're already there. That's the reality of COTS
visualization. You can probably make a good case for requiring proper
ECC RAM and so on so long as you don't handwave away bug reports.

> Arne

--
motk

On 2024-04-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/9/2024 8:45 AM, Simon Clubley wrote:
>> On 2024-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> But I think it would be very problematic with VMS complaining
>>> over configs that are not known to work.
>>>
>>> Because removing that test would require a release.
>>>
>>> We would see:
>>>
>>> ...
>>> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
>>> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
>>> ..
>>>
>>> No thanks.
>>
>> It does not have to be a release - it could be a patch.
>
> True.
>
> But I don't like:
> ...
> VMS 9.2-2 with HW patch 41
> VMS 9.2-2 with HW patch 42
> ...
>
> either.
>

How many VM solutions do you think there are out there ? :-)

Hint: there isn't 41 of them. :-)

>> IOW, my suggested approach is a very long-established part of the
>> VMS world. The only difference now is that VMS would be allowed to
>> continue booting if you set an override flag or SYSGEN parameter.
>>
>> Also, there should be no need to add support for "VM Bar 4" unless
>> it brought new functionality over "VM Bar 3" that you wanted to
>> support in VMS.
>
> ????
>
> The interest in different VM's is not driven by what VMS need,
> but from what customers want.
>

What customers need is implemented by turning it into what VMS needs...

>> VMS is used in mission-critical production environments. You should
>> not be allowed to accidentally boot into an unsupported configuration
>> without being made _VERY_ aware of that fact.
>
> Hopefully those running a mission critical production environment
> on VMS read about supported configs before moving production to
> that config and never runs it in anything accidentally
> booted.
>

According to some people: "There is no need for anything more safer than
the C or C++ programming language. You just have to be careful when writing
your code...". Your comment above is from the same incorrect mindset.

In the real world, people make mistakes, especially in an outsourced
environment where people cost, not people capability, is the driving
factor and hence people are not as skilled with VMS as they could be.

Simon.

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

On 2024-04-09, Dave Froble <davef@tsoft-inc.com> wrote:
>
> But hasn't the discussion been about the CL stuff? I don't think CL and mission
> critical co-exist. I'm sure VSI doesn't think that.
>

No. This is about adding checks to VMS itself.

> As for due diligence, when did that go away? Any reasonable customer would
> check, and re-check, that they are using supported stuff.
>

People make mistakes. See my reply to Arne.

Simon.

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