Craig A. Berry wrote on 1-APR-2024 13:05:15.61

>What they said was they will send anyone who has previously applied for
>an x86 license is a link to the new vmdk that already has software and
>licenses on it. My understanding is that the service portal is going
>away for CL users and what you get on the vmdk is what you'll have until
>the next one comes out the following year.

I did not get that E-mail (should have got it because I got CLP licenses).
Seems no vmdk for me.

Jouk

Pax, vel iniusta, utilior est quam iustissimum bellum.
(free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.)
Epistularum ad Atticum 7.1.4.3)

Touch not the cat bot a glove

>------------------------------------------------------------------------------<

Jouk Jansen

joukj@hrem.nano.tudelft.nl

Technische Universiteit Delft tttttttttt uu uu ddddddd
Kavli Institute of Nanoscience tttttttttt uu uu dd dd
Nationaal centrum voor HREM tt uu uu dd dd
Lorentzweg 1 tt uu uu dd dd
2628 CJ Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. +31-15-2782272 tt uuuuuuu ddddddd

>------------------------------------------------------------------------------<

On 4/2/24 1:10 AM, Jouk Jansen wrote:
> Craig A. Berry wrote on 1-APR-2024 13:05:15.61
>
>> What they said was they will send anyone who has previously applied for
>> an x86 license is a link to the new vmdk that already has software and
>> licenses on it. My understanding is that the service portal is going
>> away for CL users and what you get on the vmdk is what you'll have until
>> the next one comes out the following year.
>
> I did not get that E-mail (should have got it because I got CLP licenses).
> Seems no vmdk for me.

I have not gotten such an e-mail either.

On 2024-04-02 8:57 a.m., Craig A. Berry wrote:
>> I did not get that E-mail (should have got it because I got CLP
>> licenses).
>> Seems no vmdk for me.
>
> I have not gotten such an e-mail either.

It sounds like there may be many of us that have not received that email
as of yet, so we're kind of stuck.

Whether our emails are queued up, or we've been overlooked, we have no
way of knowing at this point.

On 2/04/2024 5:10 pm, Jouk Jansen wrote:

> I did not get that E-mail (should have got it because I got CLP licenses).
> Seems no vmdk for me.

Go to https://vmssoftware.com/products/licenses/ where you'll need to
reapply for the Community license for VSI OpenVMS x86_64.

I did this last Sunday and received an e-mail with download details for
the vdmk disk image on Tuesday.

Tony

On 3/04/2024 12:22 am, mjos_examine wrote:
> On 2024-04-02 8:57 a.m., Craig A. Berry wrote:
>>> I did not get that E-mail (should have got it because I got CLP
>>> licenses).
>>> Seems no vmdk for me.
>>
>> I have not gotten such an e-mail either.
>
> It sounds like there may be many of us that have not received that email
> as of yet, so we're kind of stuck.
>
> Whether our emails are queued up, or we've been overlooked, we have no
> way of knowing at this point.

I didn't receive an email for seven months; when I mentioned this on the
forum I was chided for impatience and then was told I had been sent an
email. Checked entire email server logs, nothing there. I asked if it
could be resent and have had no reply.

Friends, it's not looking good.

--
motk

On 3/04/2024 9:10 am, motk wrote:

> I didn't receive an email for seven months; when I mentioned this on the
> forum I was chided for impatience and then was told I had been sent an
> email. Checked entire email server logs, nothing there. I asked if it
> could be resent and have had no reply.

And ... it just appeared! Well, there's a thing.

--
motk

On 3/04/2024 10:10 am, motk wrote:
> On 3/04/2024 9:10 am, motk wrote:
>
>> I didn't receive an email for seven months; when I mentioned this on
>> the forum I was chided for impatience and then was told I had been
>> sent an email. Checked entire email server logs, nothing there. I
>> asked if it could be resent and have had no reply.
>
> And ... it just appeared! Well, there's a thing.

Doing a qm import into proxmox now. I've been a bit intemperant, and I'm
not convinced in any way that this is the right thing to do with the CL,
but I'll give it a go.

--
motk

On 4/2/2024 11:40 AM, Tony Nicholson wrote:
> On 2/04/2024 5:10 pm, Jouk Jansen wrote:
>
>> I did not get that E-mail (should have got it because I got CLP licenses).
>> Seems no vmdk for me.
>
> Go to https://vmssoftware.com/products/licenses/ where you'll need to reapply for the Community license for VSI OpenVMS x86_64.
>
> I did this last Sunday and received an e-mail with download details for
> the vdmk disk image on Tuesday.
>
> Tony
>

From Mister Moderator on the VSI Forum:

"This week already we have processed over 1000 applications to get access to the community instance of x86 OpenVMS for the VMDK. This included some old applications as well so please check your inboxes and spam folders. If you have not received one yet and have only just applied then please be patient as we will get to you and thankfully the process is a lot faster than it once was."

Hopefully everyone is getting their email.

--
John H. Reinhardt

On 4/3/24 10:20, motk wrote:
> On 3/04/2024 10:10 am, motk wrote:
>> On 3/04/2024 9:10 am, motk wrote:
>>
>>> I didn't receive an email for seven months; when I mentioned this on
>>> the forum I was chided for impatience and then was told I had been
>>> sent an email. Checked entire email server logs, nothing there. I
>>> asked if it could be resent and have had no reply.
>>
>> And ... it just appeared! Well, there's a thing.
>
> Doing a qm import into proxmox now. I've been a bit intemperant, and I'm
> not convinced in any way that this is the right thing to do with the CL,
> but I'll give it a go.

After working out I needed to add "args: -no-hpet" to the server conf in
/etc/pve/qemu-server/xxx.conf, it's been working well enough.

I did apparently accidentally fuzz things:

$ product list *

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000007
0000000000006000
FFFF830007C0236B
0000000000000012
Register dump:
RAX = 0000000000000000 RDI = 000000007FF9DC80 RSI = 0000000000006000
RDX = 5344524F5759454B RCX = 0000000000006000 R8 = 00000000FFFF8F86
R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9FF60
R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C0F8
R13 = 0000000000000018 R14 = 000000007FF9C2B0 R15 = 0000000000008301
RIP = FFFF830007C0236B RSP = 000000007FF9FF00 SS = 000000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000014
0000000000000018
000000007FF9CE98
0000000000000012
Register dump:
RAX = 0000000000000001 RDI = 000000007FF7BC20 RSI = 0000000000000001
RDX = 0000000000000000 RCX = FFFFFFFF8AC09B5E R8 = 000000007ACBD11F
R9 = 0000000000000106 RBX = 000000007FFABE00 RBP = 000000007FF9F0A8
R10 = 000000007FFA4D18 R11 = 000000007FFA4D18 R12 = 000000007FF9F060
R13 = 000000007FFCDCAC R14 = 0000000000000002 R15 = 000000003DA78301
Connection closed by foreign host.000000007FF9CA30 SS = 000000000000001B

Am 04.04.2024 um 09:52 schrieb motk:
> On 4/3/24 10:20, motk wrote:
>...
> I did apparently accidentally fuzz things:
>
> $ product list  *
>
>   Improperly handled condition, bad stack or no handler specified.
>     Signal arguments:   Number = 0000000000000005
>                         Name   = 000000000000000C
>                                  0000000000000007
>                                  0000000000006000
>                                  FFFF830007C0236B
>                                  0000000000000012
>     Register dump:
>     RAX = 0000000000000000  RDI = 000000007FF9DC80  RSI = 0000000000006000
>     RDX = 5344524F5759454B  RCX = 0000000000006000  R8  = 00000000FFFF8F86
>     R9  = 000000000808080D  RBX = 000000007FFABE00  RBP = 000000007FF9FF60
>     R10 = 000000007FFABDB0  R11 = 000000007FFA4D18  R12 = 000000007FF9C0F8
>     R13 = 0000000000000018  R14 = 000000007FF9C2B0  R15 = 0000000000008301
>     RIP = FFFF830007C0236B  RSP = 000000007FF9FF00  SS  = 000000000000001B
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
> address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE

motk,

can you reproduce this ? Over and over again ?

If so, please consider to report this in the VSI Forum together with a
detailled description of your underlying software/hardware and the steps
to reproduce this access violation.

https://forum.vmssoftware.com/search.php?search_id=active_topics

Volker.

On 4/4/24 18:49, Volker Halle wrote:

> can you reproduce this ? Over and over again ?
>
> If so, please consider to report this in the VSI Forum together with a
> detailled description of your underlying software/hardware and the steps
> to reproduce this access violation.
>
> https://forum.vmssoftware.com/search.php?search_id=active_topics

If I can reproduce it, I will. No luck so far.

--
motk

On 2024-04-04, Volker Halle <volker_halle@hotmail.com> wrote:
> Am 04.04.2024 um 09:52 schrieb motk:
>> On 4/3/24 10:20, motk wrote:
>>...
>> I did apparently accidentally fuzz things:
>>
>> $ product list  *
>>
>>   Improperly handled condition, bad stack or no handler specified.
>>     Signal arguments:   Number = 0000000000000005
>>                         Name   = 000000000000000C
>>                                  0000000000000007
>>                                  0000000000006000
>>                                  FFFF830007C0236B
>>                                  0000000000000012
>>     Register dump:
>>     RAX = 0000000000000000  RDI = 000000007FF9DC80  RSI = 0000000000006000
>>     RDX = 5344524F5759454B  RCX = 0000000000006000  R8  = 00000000FFFF8F86
>>     R9  = 000000000808080D  RBX = 000000007FFABE00  RBP = 000000007FF9FF60
>>     R10 = 000000007FFABDB0  R11 = 000000007FFA4D18  R12 = 000000007FF9C0F8
>>     R13 = 0000000000000018  R14 = 000000007FF9C2B0  R15 = 0000000000008301
>>     RIP = FFFF830007C0236B  RSP = 000000007FF9FF00  SS  = 000000000000001B
>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>> address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
>
> motk,
>
> can you reproduce this ? Over and over again ?
>
> If so, please consider to report this in the VSI Forum together with a
> detailled description of your underlying software/hardware and the steps
> to reproduce this access violation.
>
> https://forum.vmssoftware.com/search.php?search_id=active_topics
>

Well that's a seriously "interesting" thing to suggest Volker. :-(

Assuming the posted output has not been edited, running a user-mode program
resulted in the process being killed. That means it failed in either
supervisor mode or executive mode. That means VSI need to be told _privately_
about the sequence to reproduce (if it can be discovered) so that they can
see if the sequence can be modified to actually exploit the system.

If that sequence is published in a public forum before VSI have analyzed
and fixed the problem, it means anyone else will be able to perform the
same analysis to see if the problem can be exploited. :-(

Of course, the OP will have to report this to VSI via insecure email
(if they can discover the sequence) because VSI clearly think it is
below them to actually make available a public security reporting
mechanism. :-(

Simon.

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

On 4/04/2024 10:43 pm, Simon Clubley wrote:
> On 2024-04-04, Volker Halle <volker_halle@hotmail.com> wrote:
>> Am 04.04.2024 um 09:52 schrieb motk:
>>> On 4/3/24 10:20, motk wrote:
>>> ...
>>> I did apparently accidentally fuzz things:
>>>
>>> $ product list  *
>>>
>>>   Improperly handled condition, bad stack or no handler specified.
>>>     Signal arguments:   Number = 0000000000000005
>>>                         Name   = 000000000000000C
>>>                                  0000000000000007
>>>                                  0000000000006000
>>>                                  FFFF830007C0236B
>>>                                  0000000000000012
>>>     Register dump:
>>>     RAX = 0000000000000000  RDI = 000000007FF9DC80  RSI = 0000000000006000
>>>     RDX = 5344524F5759454B  RCX = 0000000000006000  R8  = 00000000FFFF8F86
>>>     R9  = 000000000808080D  RBX = 000000007FFABE00  RBP = 000000007FF9FF60
>>>     R10 = 000000007FFABDB0  R11 = 000000007FFA4D18  R12 = 000000007FF9C0F8
>>>     R13 = 0000000000000018  R14 = 000000007FF9C2B0  R15 = 0000000000008301
>>>     RIP = FFFF830007C0236B  RSP = 000000007FF9FF00  SS  = 000000000000001B
>>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>>> address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
>>
>> motk,
>>
>> can you reproduce this ? Over and over again ?
>>
>> If so, please consider to report this in the VSI Forum together with a
>> detailled description of your underlying software/hardware and the steps
>> to reproduce this access violation.
>>
>> https://forum.vmssoftware.com/search.php?search_id=active_topics
>>
>
> Well that's a seriously "interesting" thing to suggest Volker. :-(
>
> Assuming the posted output has not been edited, running a user-mode program
> resulted in the process being killed. That means it failed in either
> supervisor mode or executive mode. That means VSI need to be told _privately_
> about the sequence to reproduce (if it can be discovered) so that they can
> see if the sequence can be modified to actually exploit the system.

I can guarantee that output wasn't mangled in any way. I've been trying
to reproduce it with no success so far. It was an extremely surprising
result though; would it have hit a log somewhere?

> If that sequence is published in a public forum before VSI have analyzed
> and fixed the problem, it means anyone else will be able to perform the
> same analysis to see if the problem can be exploited. :-(

Fuzzing tools are free and plentiful.

> Simon.

--
motk

On 2024-04-05, motk <meh@meh.meh> wrote:
> On 4/04/2024 10:43 pm, Simon Clubley wrote:
>>> Am 04.04.2024 um 09:52 schrieb motk:
>>>> On 4/3/24 10:20, motk wrote:
>>>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>>>> address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
>>
>> Assuming the posted output has not been edited, running a user-mode program
>> resulted in the process being killed. That means it failed in either
>> supervisor mode or executive mode. That means VSI need to be told _privately_
>> about the sequence to reproduce (if it can be discovered) so that they can
>> see if the sequence can be modified to actually exploit the system.
>
> I can guarantee that output wasn't mangled in any way. I've been trying
> to reproduce it with no success so far. It was an extremely surprising
> result though; would it have hit a log somewhere?
>

The exit status on the accounting log may be interesting.

Try a "$ acc/since=<whatever>/full" and once you have found the correct
session, have a look at the exit status.

Assuming the current mode bits on x86-64 in the PS register match those
on Alpha, then, assuming I am decoding the bitfield correctly, it looks
like an executive mode failure (ie: a failure in RMS itself). :-(

Can someone confirm I am decoding the current mode bits in the above
PS register correctly ?

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-05, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2024-04-05, motk <meh@meh.meh> wrote:
>> On 4/04/2024 10:43 pm, Simon Clubley wrote:
>>>> Am 04.04.2024 um 09:52 schrieb motk:
>>>>> On 4/3/24 10:20, motk wrote:
>>>>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
>>>>> address=000000000000000C, PC=0000000000000002, PS=7AD5D8EE
>>>
>>> Assuming the posted output has not been edited, running a user-mode program
>>> resulted in the process being killed. That means it failed in either
>>> supervisor mode or executive mode. That means VSI need to be told _privately_
>>> about the sequence to reproduce (if it can be discovered) so that they can
>>> see if the sequence can be modified to actually exploit the system.
>>
>> I can guarantee that output wasn't mangled in any way. I've been trying
>> to reproduce it with no success so far. It was an extremely surprising
>> result though; would it have hit a log somewhere?
>>
>
> The exit status on the accounting log may be interesting.
>
> Try a "$ acc/since=<whatever>/full" and once you have found the correct
> session, have a look at the exit status.
>
> Assuming the current mode bits on x86-64 in the PS register match those
> on Alpha, then, assuming I am decoding the bitfield correctly, it looks
> like an executive mode failure (ie: a failure in RMS itself). :-(
>
> Can someone confirm I am decoding the current mode bits in the above
> PS register correctly ?
>

Another idea: If this really is an executive mode failure, I wonder if
setting BUGCHECKFATAL to 1 would be useful here ?

Alex: What this would do is to turn the failure into a failure that
crashes the system (and writes a dumpfile, assuming the VSI virtual
image is setup correctly) instead of just deleting the current process.

It would also mean anything in memory (including command history, etc)
would be written to the dumpfile, so make sure there's nothing private
in the memory of your system before performing more tests.

What you could do then is to compress the dumpfile and send it to VSI
privately via some means they give you.

BTW, another idea: does x86-64 VMS currently write an entry into the
errorlog on an executive mode bugcheck ? I wonder if it would be useful
to check the errorlog to see if there is anything useful there from the
previous failure ?

Simon.

PS: pointed message to VSI management: A hobbyist has just appeared to
find a process-deleting bug within VMS that your testing has missed so far.
_This_ is an example of why the hobbyist program is important, and of
benefit, to you.

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

On 2024-04-05, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> Alex: What this would do is to turn the failure into a failure that
> crashes the system (and writes a dumpfile, assuming the VSI virtual
> image is setup correctly) instead of just deleting the current process.
>

Oops. motk, not Alex. Sorry. :-)

Simon.

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

On Fri, 2024-04-05 at 13:20 +0000, Simon Clubley wrote:
> Alex: What this would do is to turn the failure into a failure that
> crashes the system (and writes a dumpfile, assuming the VSI virtual
> image is setup correctly) instead of just deleting the current
> process.

Who, me? I think it's actually motk with the issue, is it not?
--
Tactical Nuclear Kittens

On 2024-04-05, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Fri, 2024-04-05 at 13:20 +0000, Simon Clubley wrote:
>> Alex: What this would do is to turn the failure into a failure that
>> crashes the system (and writes a dumpfile, assuming the VSI virtual
>> image is setup correctly) instead of just deleting the current
>> process.
>
> Who, me? I think it's actually motk with the issue, is it not?

Yes, you. :-) As I posted in a followup, I got the name wrong. Sorry. :-)

Simon.

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

On 5/04/2024 10:27 pm, Simon Clubley wrote:

> The exit status on the accounting log may be interesting.
>
> Try a "$ acc/since=<whatever>/full" and once you have found the correct
> session, have a look at the exit status.

This seems relevant:

Queue entry: Final status code: 1000000C
Queue name:
Job name:
Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB,
virtual address=!XH, PC=!XH

I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
now.

> Simon.

--
motk

On 5/04/2024 11:20 pm, Simon Clubley wrote:

> Another idea: If this really is an executive mode failure, I wonder if
> setting BUGCHECKFATAL to 1 would be useful here ?
>
> Alex: What this would do is to turn the failure into a failure that
> crashes the system (and writes a dumpfile, assuming the VSI virtual
> image is setup correctly) instead of just deleting the current process.
>
> It would also mean anything in memory (including command history, etc)
> would be written to the dumpfile, so make sure there's nothing private
> in the memory of your system before performing more tests.
>
> What you could do then is to compress the dumpfile and send it to VSI
> privately via some means they give you.
>
> BTW, another idea: does x86-64 VMS currently write an entry into the
> errorlog on an executive mode bugcheck ? I wonder if it would be useful
> to check the errorlog to see if there is anything useful there from the
> previous failure ?

Found some time today to try installing Apache, trying random
half-remembered commands and looking through documentation that just
talks about AXP and Integrity stuff, and lo:

$ show proc

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000000878
FFFF830007C02367
0000000000000012
Register dump:
RAX = 000000007FF9DC80 RDI = 000000007FF9DC80 RSI = 0000000000000878
RDX = 0000000000000000 RCX = 0000000000000878 R8 = 00000000FFFF8F81
R9 = 000000000808080D RBX = 000000007FFABE00 RBP = 000000007FF9E540
R10 = 000000007FFABDB0 R11 = 000000007FFA4D18 R12 = 000000007FF9C648
R13 = 0000000000000018 R14 = 000000007FF9C800 R15 = 0000000000000201
RIP = FFFF830007C02367 RSP = 000000007FF9E4E0 SS = 000000000000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000000
000C, PC=0000000000000002, PS=7AD82CC6

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
8000000000000000
000000007AE15900
0000000000000012
Register dump:
RAX = 0000000000000001 RDI = FFFFFFFF77761C88 RSI = 0000000002040001
RDX = 0000000000000000 RCX = FFFFFFFF8AC09B5E R8 = 000000007ACBD11F
R9 = 0000000000000106 RBX = 000000007FFABE00 RBP = 000000007FF9D608
R10 = 000000007FFA4D18 R11 = 000000007FFA4D18 R12 = 000000007FF9D5C0
R13 = 000000007FFCDCAC R14 = 0000000000000002 R15 = 0000000045178301
Connection closed by foreign host.000000007FF9CA28 SS = 000000000000001B

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.

> Simon.
>
> PS: pointed message to VSI management: A hobbyist has just appeared to
> find a process-deleting bug within VMS that your testing has missed so far.
> _This_ is an example of why the hobbyist program is important, and of
> benefit, to you.

Yeah, noobs do non-obvious stuff and find weird edge cases.
--
motk

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.

--
motk

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

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000014
0000000000000000
0000000000000000
0000000000000012
Register dump:
RAX = 0000000000000001 RDI = FFFFFFFF776521E8 RSI = 00000000020C0001
RDX = 0000000000000000 RCX = FFFFFFFF8AC09B5E R8 = 000000007ACBD11F
R9 = 0000000004000106 RBX = 000000007FFABE00 RBP = 000000007FF9D568
R10 = 000000007FFA4D18 R11 = 000000007FFA4D18 R12 = 000000007FF9D520
R13 = 000000007FFCDCAC R14 = 0000000000000002 R15 = 000000004B9E8301
Connection to 192.168.188.121 closed.000007FF9CA30 SS = 000000000000001B

--
motk

On 4/7/2024 9:36 PM, motk wrote:
> $ 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
>
>   Improperly handled condition, bad stack or no handler specified.
>     Signal arguments:   Number = 0000000000000005
>                         Name   = 000000000000000C
>                                  0000000000000014
>                                  0000000000000000
>                                  0000000000000000
>                                  0000000000000012
>     Register dump:
>     RAX = 0000000000000001  RDI = FFFFFFFF776521E8  RSI = 00000000020C0001
>     RDX = 0000000000000000  RCX = FFFFFFFF8AC09B5E  R8  = 000000007ACBD11F
>     R9  = 0000000004000106  RBX = 000000007FFABE00  RBP = 000000007FF9D568
>     R10 = 000000007FFA4D18  R11 = 000000007FFA4D18  R12 = 000000007FF9D520
>     R13 = 000000007FFCDCAC  R14 = 0000000000000002  R15 = 000000004B9E8301
> Connection to 192.168.188.121 closed.000007FF9CA30  SS  = 000000000000001B

I am getting the idea that VMS does not like your VM.

It seems unlikely to me that:

$ product list *
$ help analyze

trigger some x86-64 specific DCL or RMS bug that nobody else has
encountered.

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.

But then this stuff is way outside of my expertise area
so I am probably wrong.

Arne

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.

> Arne

--
motk

On 2024-04-05, motk <meh@meh.meh> wrote:
> On 5/04/2024 10:27 pm, Simon Clubley wrote:
>
>> The exit status on the accounting log may be interesting.
>>
>> Try a "$ acc/since=<whatever>/full" and once you have found the correct
>> session, have a look at the exit status.
>
> This seems relevant:
>
> Queue entry: Final status code: 1000000C
> Queue name:
> Job name:
> Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB,
> virtual address=!XH, PC=!XH
>
> I remembered vaguely how to drive sysgen, and have enabled SYSTEM_CHECK
> now.
>

Is there anything in the error log ?

Simon.

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