AXPbox 1.1.0
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1K
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Zend Engine v3.2.0)
MariaDB Ver 15.1 Distrib 5.5.64-MariaDB, for OpenVMS (Alpha)

This is the first time I've tried to get this working on AXPbox and I'm getting the access violation noted below. Any thoughts? TIA

AXPBOX::@run_mysqld
220116 21:08:49 [Note] DKA0:[MYSQL055.][bin.alpha]mysqld.exe;1 (mysqld 5.5.64-Ma
riaDB) starting as process 1062 ...
220116 21:08:50 InnoDB: The InnoDB memory heap is disabled
220116 21:08:50 InnoDB: Mutexes and rw_locks use VMS atomic functions
220116 21:08:50 InnoDB: Compressed tables use zlib 1.2.11
220116 21:08:56 InnoDB: Initializing buffer pool, size = 128.0M
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
2000, PC=0000000000002000, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 0000000000002000 0000000000002000
DECC$SHR_EV56 0 00000000001E23E4 FFFFFFFF80C7C3E4
DECC$SHR_EV56 0 00000000001E4EA4 FFFFFFFF80C7EEA4
DECC$SHR_EV56 0 00000000001E36B8 FFFFFFFF80C7D6B8
DECC$SHR_EV56 0 000000000013C3A8 FFFFFFFF80BD63A8
DECC$SHR_EV56 0 000000000013BA3C FFFFFFFF80BD5A3C
mysqld os0proc os_mem_alloc_large 38797 0000000000000104 0000000000E053D4
TRACEBACK - Exception occurred during traceback processing
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=000000007BFCC7BC, PS=0000001B
mysqld buf0buf buf_chunk_init 0 0000000000ED89EC 0000000000ED89EC
TRACEBACK - Exception occurred during traceback processing
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=000000007BFCC7BC, PS=0000001B
mysqld buf0buf buf_pool_init_instance
0 0000000000ED8FC4 0000000000ED8FC4
TRACEBACK - Exception occurred during traceback processing
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=000000007BFCC7BC, PS=0000001B
mysqld buf0buf buf_pool_init 0 0000000000ED93B4 0000000000ED93B4
mysqld srv0start innobase_start_or_create_for_mysql
156533 0000000000003B7C 0000000000DDD51C
mysqld ha_innodb innobase_init 203858 0000000000008CB4 0000000000D78014
mysqld handler ha_initialize_handlerton
144411 0000000000006B94 00000000008244E4
mysqld sql_plugin plugin_initialize 135872 00000000000042DC 000000000096284C
mysqld sql_plugin plugin_init 136096 0000000000004A84 0000000000962FF4
mysqld mysqld init_server_components
158970 000000000000A3CC 0000000000A294AC
mysqld mysqld mysqld_main 159567 000000000000B2AC 0000000000A2A38C
mysqld main main 114 000000000000011C 00000000006E011C
mysqld main __MAIN 0 00000000000000AC 00000000006E00AC
mysqld 0 00000000010EBC8C 00000000010EBC8C
PTHREAD$RTL 0 0000000000057718 FFFFFFFF80A79718
PTHREAD$RTL 0 0000000000030444 FFFFFFFF80A52444
0 FFFFFFFF8038FC04 FFFFFFFF8038FC04
%TRACE-I-END, end of TRACE stack dump

issinoho,

> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 2000, PC=0000000000002000, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> image module routine line rel PC abs PC
> 0 0000000000002000 0000000000002000
> DECC$SHR_EV56 0 00000000001E23E4 FFFFFFFF80C7C3E4

Use $ SET PROC/DUMP before invoking @run_mysqld

A process dumpfile (imagename.DMP) will be written, which could be analyzed using $ ANALZYE/PROC imagename.DMP or $ ANALYZE/CRASH imagename.DMP

The access violation happens when trying to access virtual address 2000 to execute the next insturction, which is pointed to by the PC value of 2000. Either stack corruption or some wrong target address for a call...

Try to find out from the stack, which routine tries to call/access that invalid PC.

Volker.

On Sunday, January 16, 2022 at 4:14:31 PM UTC-5, issinoho wrote:
> AXPbox 1.1.0
> VSI AXPVMS VMS V8.4-2L1
> VSI AXPVMS TCPIP V5.7-13ECO5F
> VSI AXPVMS SSL111 V1.1-1K
> VSI AXPVMS CSWS V2.4-38D
> PHP 7.2.29 (Zend Engine v3.2.0)
> MariaDB Ver 15.1 Distrib 5.5.64-MariaDB, for OpenVMS (Alpha)
>
> This is the first time I've tried to get this working on AXPbox and I'm getting the access violation noted below. Any thoughts? TIA
>
> AXPBOX::@run_mysqld
> 220116 21:08:49 [Note] DKA0:[MYSQL055.][bin.alpha]mysqld.exe;1 (mysqld 5.5.64-Ma
> riaDB) starting as process 1062 ...
> 220116 21:08:50 InnoDB: The InnoDB memory heap is disabled
> 220116 21:08:50 InnoDB: Mutexes and rw_locks use VMS atomic functions
> 220116 21:08:50 InnoDB: Compressed tables use zlib 1.2.11
> 220116 21:08:56 InnoDB: Initializing buffer pool, size = 128.0M
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 2000, PC=0000000000002000, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> image module routine line rel PC abs PC
> 0 0000000000002000 0000000000002000
> DECC$SHR_EV56 0 00000000001E23E4 FFFFFFFF80C7C3E4
> DECC$SHR_EV56 0 00000000001E4EA4 FFFFFFFF80C7EEA4
> DECC$SHR_EV56 0 00000000001E36B8 FFFFFFFF80C7D6B8
> DECC$SHR_EV56 0 000000000013C3A8 FFFFFFFF80BD63A8
> DECC$SHR_EV56 0 000000000013BA3C FFFFFFFF80BD5A3C
> mysqld os0proc os_mem_alloc_large 38797 0000000000000104 0000000000E053D4
> TRACEBACK - Exception occurred during traceback processing
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 0000, PC=000000007BFCC7BC, PS=0000001B
> mysqld buf0buf buf_chunk_init 0 0000000000ED89EC 0000000000ED89EC
> TRACEBACK - Exception occurred during traceback processing
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 0000, PC=000000007BFCC7BC, PS=0000001B
> mysqld buf0buf buf_pool_init_instance
> 0 0000000000ED8FC4 0000000000ED8FC4
> TRACEBACK - Exception occurred during traceback processing
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 0000, PC=000000007BFCC7BC, PS=0000001B
> mysqld buf0buf buf_pool_init 0 0000000000ED93B4 0000000000ED93B4
> mysqld srv0start innobase_start_or_create_for_mysql
> 156533 0000000000003B7C 0000000000DDD51C
> mysqld ha_innodb innobase_init 203858 0000000000008CB4 0000000000D78014
> mysqld handler ha_initialize_handlerton
> 144411 0000000000006B94 00000000008244E4
> mysqld sql_plugin plugin_initialize 135872 00000000000042DC 000000000096284C
> mysqld sql_plugin plugin_init 136096 0000000000004A84 0000000000962FF4
> mysqld mysqld init_server_components
> 158970 000000000000A3CC 0000000000A294AC
> mysqld mysqld mysqld_main 159567 000000000000B2AC 0000000000A2A38C
> mysqld main main 114 000000000000011C 00000000006E011C
> mysqld main __MAIN 0 00000000000000AC 00000000006E00AC
> mysqld 0 00000000010EBC8C 00000000010EBC8C
> PTHREAD$RTL 0 0000000000057718 FFFFFFFF80A79718
> PTHREAD$RTL 0 0000000000030444 FFFFFFFF80A52444
> 0 FFFFFFFF8038FC04 FFFFFFFF8038FC04
> %TRACE-I-END, end of TRACE stack dump
That address (1E23E4) is in the SETLOCAL memory manager (according to the MAP and LIS files) where it
calls SYS$GETSYIW to retrieve SYI$_PAGE_SIZE. Looks boring. However, I don't see how we got to a PC
of 2000.

On Monday, January 17, 2022 at 12:36:55 PM UTC-5, xyzz...@gmail.com wrote:
> On Sunday, January 16, 2022 at 4:14:31 PM UTC-5, issinoho wrote:
> > AXPbox 1.1.0
> That address (1E23E4) is in the SETLOCAL memory manager (according to the MAP and LIS files) where it
> calls SYS$GETSYIW to retrieve SYI$_PAGE_SIZE. Looks boring. However, I don't see how we got to a PC
> of 2000.

Well 0x2000 = 8192 _is_ the expected return value for SYI$_PAGE_SIZE. Coincidence?

Hein

On Monday, January 17, 2022 at 1:21:40 PM UTC-5, Hein RMS van den Heuvel wrote:
> On Monday, January 17, 2022 at 12:36:55 PM UTC-5, xyzz...@gmail.com wrote:
> > On Sunday, January 16, 2022 at 4:14:31 PM UTC-5, issinoho wrote:
> > > AXPbox 1.1.0
> > That address (1E23E4) is in the SETLOCAL memory manager (according to the MAP and LIS files) where it
> > calls SYS$GETSYIW to retrieve SYI$_PAGE_SIZE. Looks boring. However, I don't see how we got to a PC
> > of 2000.
> Well 0x2000 = 8192 _is_ the expected return value for SYI$_PAGE_SIZE. Coincidence?
>
> Hein
Interesting observation. I double/tripled checked the itemlist to GETSYIW to see if the service accidentally
overwrote the saved return address on the stack. The CRTL code looks fine (the local is a 4-byte long and the
itemlist should have the address and a size of 4).

On 2022-01-16, issinoho <iain@issinoho.com> wrote:
> AXPbox 1.1.0
> VSI AXPVMS VMS V8.4-2L1
> VSI AXPVMS TCPIP V5.7-13ECO5F
> VSI AXPVMS SSL111 V1.1-1K
> VSI AXPVMS CSWS V2.4-38D
> PHP 7.2.29 (Zend Engine v3.2.0)
> MariaDB Ver 15.1 Distrib 5.5.64-MariaDB, for OpenVMS (Alpha)
>
> This is the first time I've tried to get this working on AXPbox and I'm getting the access violation noted below. Any thoughts? TIA
>

Have you got this exact installation sequence and set of software
versions working on another Alpha emulator or real hardware ?

Given that PC value, I am wondering if this is actually a problem
in the kit itself or if it's an emulation problem.

Simon.

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

On Monday, January 17, 2022 at 2:11:37 PM UTC-5, Simon Clubley wrote:
> On 2022-01-16, issinoho <ia...@issinoho.com> wrote:
> > AXPbox 1.1.0
> > VSI AXPVMS VMS V8.4-2L1
> > VSI AXPVMS TCPIP V5.7-13ECO5F
> > VSI AXPVMS SSL111 V1.1-1K
> > VSI AXPVMS CSWS V2.4-38D
> > PHP 7.2.29 (Zend Engine v3.2.0)
> > MariaDB Ver 15.1 Distrib 5.5.64-MariaDB, for OpenVMS (Alpha)
> >
> > This is the first time I've tried to get this working on AXPbox and I'm getting the access violation noted below. Any thoughts? TIA
> >
> Have you got this exact installation sequence and set of software
> versions working on another Alpha emulator or real hardware ?
>
> Given that PC value, I am wondering if this is actually a problem
> in the kit itself or if it's an emulation problem.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

To follow up with what Simon asked.

I can test this on Stromasys' Charon emulator. Contact me offline to arrange this if interested.

Dan

Simon Clubley schrieb am Montag, 17. Januar 2022 um 20:11:37 UTC+1:
>
> Given that PC value, I am wondering if this is actually a problem
> in the kit itself or if it's an emulation problem.
>

No need to speculate. Create a process dump and follow the instruction stream, which leds to this ACCVIO using the debugger or SDA. If that cannot explain, how the code could have hit that ACCVIO, then it's time to question the emulation.

Volker.

On 1/17/22 10:05 PM, Volker Halle wrote:
> Simon Clubley schrieb am Montag, 17. Januar 2022 um 20:11:37 UTC+1:
>>
>> Given that PC value, I am wondering if this is actually a problem
>> in the kit itself or if it's an emulation problem.
>>
>
> No need to speculate. Create a process dump and follow the instruction stream, which leds to this ACCVIO using the debugger or SDA. If that cannot explain, how the code could have hit that ACCVIO, then it's time to question the emulation.

It is almost certainly the emulation since the same code works fine on
real hardware.

Mark Berryman

Please first create a process dump and follow the instruction stream. If following the instruction stream does not lead to the attempt of executing the next instruction at a PC value of 2000, then you may start to consider this an emulation issue.

I'm willing to help, if you can make the process dump available.

Volker.

On Tuesday, 18 January 2022 at 16:10:53 UTC, Volker Halle wrote:
> Please first create a process dump and follow the instruction stream. If following the instruction stream does not lead to the attempt of executing the next instruction at a PC value of 2000, then you may start to consider this an emulation issue.
>
> I'm willing to help, if you can make the process dump available.
>
> Volker.

Thanks, everyone.

@simon @mark I have this exact same stack running on the FreeAXP emulator and it works fine.

@volker I will create a dump and PM you a link to download if you can help analyze.

Interestingly, the mysql.exe CLI also dumps an access violation.

So, yes, it's almost certainly the emulation - I wonder if Tomáš (if he's reading) would have any comments?

On Tuesday, 18 January 2022 at 20:06:51 UTC, issinoho wrote:
> On Tuesday, 18 January 2022 at 16:10:53 UTC, Volker Halle wrote:
> > Please first create a process dump and follow the instruction stream. If following the instruction stream does not lead to the attempt of executing the next instruction at a PC value of 2000, then you may start to consider this an emulation issue.
> >
> > I'm willing to help, if you can make the process dump available.
> >
> > Volker.
> Thanks, everyone.
>
> @simon @mark I have this exact same stack running on the FreeAXP emulator and it works fine.
>
> @volker I will create a dump and PM you a link to download if you can help analyze.
>
> Interestingly, the mysql.exe CLI also dumps an access violation.
>
> So, yes, it's almost certainly the emulation - I wonder if Tomáš (if he's reading) would have any comments?

@volker let me know how best to get a link to you; thanks.

You can find a valid mail address on my DECUServe home page https://eisner.encompasserve.org/~halle/

Volker.

Mark Berryman schrieb am Dienstag, 18. Januar 2022 um 16:31:22 UTC+1:

> It is almost certainly the emulation since the same code works fine on
> real hardware.

Mark,

are you running your myslqd process with DECC$SHR_EV56 linked 21-DEC-2016 13:36:58.27 ?

The exception is happening in DECC$SHR_EV56 code.

Volker.

The exception is actually happening on return from the following call in [ACRTL]SETLOCALE_MEMMGR_EV56

status = sys$getsyiw(EFN$C_ENF, 0, 0, itmlst, (void *)&iosb, 0, 0);

SYS$GETSYIW_C+000B0: LDQ R28,#X0060(FP) <<< load R28
SYS$GETSYIW_C+000B4: LDQ R2,#X0068(FP)
SYS$GETSYIW_C+000B8: LDQ R7,#X0070(FP)
SYS$GETSYIW_C+000BC: LDQ R8,#X0078(FP)
SYS$GETSYIW_C+000C0: LDQ R13,#X0080(FP)
SYS$GETSYIW_C+000C4: LDQ FP,#X0088(FP)
SYS$GETSYIW_C+000C8: LDA SP,#X0090(SP)
SYS$GETSYIW_C+000CC: LDQ_U R31,(SP)
SYS$GETSYIW_C+000D0: RET R31,(R28) <<< return

SDA> SHOW PROC/REGISTER shows
....
R27 = 00000000.00000000 R28 = 00000000.00002000 FP = 00000000.7AE420F0
PC = 00000000.00002000 PS = 10000000.0000001B
....

Puzzled...

Volker.

On 1/20/22 4:09 AM, Volker Halle wrote:
> Mark Berryman schrieb am Dienstag, 18. Januar 2022 um 16:31:22 UTC+1:
>
>> It is almost certainly the emulation since the same code works fine on
>> real hardware.
>
> Mark,
>
> are you running your myslqd process with DECC$SHR_EV56 linked 21-DEC-2016 13:36:58.27 ?
>
> The exception is happening in DECC$SHR_EV56 code.

MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
against is:

Image Identification Information

image name: "DECC$SHR_EV56"
image file identification: "V8.4-00"
image file build identification: "XE6K-0100140000"
link date/time: 22-MAY-2017 22:49:13.75
linker identification: "A13-04"

However, the version I am currently using on my system is:

Image Identification Information

image name: "DECC$SHR_EV56"
image file identification: "V8.4-00"
image file build identification: "XE80-F4N-000054"
link date/time: 22-AUG-2020 07:02:43.80
linker identification: "A13-04"

Mark Berryman

On Thursday, 20 January 2022 at 18:38:53 UTC, Mark Berryman wrote:
> On 1/20/22 4:09 AM, Volker Halle wrote:
> > Mark Berryman schrieb am Dienstag, 18. Januar 2022 um 16:31:22 UTC+1:
> >
> >> It is almost certainly the emulation since the same code works fine on
> >> real hardware.
> >
> > Mark,
> >
> > are you running your myslqd process with DECC$SHR_EV56 linked 21-DEC-2016 13:36:58.27 ?
> >
> > The exception is happening in DECC$SHR_EV56 code.
> MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
> against is:
>
> Image Identification Information
>
> image name: "DECC$SHR_EV56"
> image file identification: "V8.4-00"
> image file build identification: "XE6K-0100140000"
> link date/time: 22-MAY-2017 22:49:13.75
> linker identification: "A13-04"
>
> However, the version I am currently using on my system is:
>
> Image Identification Information
>
> image name: "DECC$SHR_EV56"
> image file identification: "V8.4-00"
> image file build identification: "XE80-F4N-000054"
> link date/time: 22-AUG-2020 07:02:43.80
> linker identification: "A13-04"
>
> Mark Berryman

From my system...

Image Identification Information
image name: "DECC$SHR_EV56"
image file identification: "V8.4-00"
image file build identification: "XE3T-0100120000"
link date/time: 21-DEC-2016 13:36:58.27
linker identification: "A13-04"

On 1/20/22 11:06 AM, Volker Halle wrote:
> The exception is actually happening on return from the following call in [ACRTL]SETLOCALE_MEMMGR_EV56

Maybe try running under a different locale?

On 1/20/2022 2:53 PM, issinoho wrote:
> On Thursday, 20 January 2022 at 18:38:53 UTC, Mark Berryman wrote:
>> On 1/20/22 4:09 AM, Volker Halle wrote:
>>> Mark Berryman schrieb am Dienstag, 18. Januar 2022 um 16:31:22 UTC+1:
>>>
>>>> It is almost certainly the emulation since the same code works fine on
>>>> real hardware.
>>>
>>> Mark,
>>>
>>> are you running your myslqd process with DECC$SHR_EV56 linked 21-DEC-2016 13:36:58.27 ?
>>>
>>> The exception is happening in DECC$SHR_EV56 code.
>> MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
>> against is:
>>
>> Image Identification Information
>>
>> image name: "DECC$SHR_EV56"
>> image file identification: "V8.4-00"
>> image file build identification: "XE6K-0100140000"
>> link date/time: 22-MAY-2017 22:49:13.75
>> linker identification: "A13-04"
>>
>> However, the version I am currently using on my system is:
>>
>> Image Identification Information
>>
>> image name: "DECC$SHR_EV56"
>> image file identification: "V8.4-00"
>> image file build identification: "XE80-F4N-000054"
>> link date/time: 22-AUG-2020 07:02:43.80
>> linker identification: "A13-04"
>>
>> Mark Berryman
>
> From my system...
>
> Image Identification Information
>
> image name: "DECC$SHR_EV56"
> image file identification: "V8.4-00"
> image file build identification: "XE3T-0100120000"

XE3T is V8.4-2L1
XE6K is V8.4-2L2 (the EV6 optimized version of -2L1)

--
-- Rob

On 1/20/2022 3:00 PM, Robert A. Brooks wrote:
> On 1/20/2022 2:53 PM, issinoho wrote:
>> On Thursday, 20 January 2022 at 18:38:53 UTC, Mark Berryman wrote:
>>> On 1/20/22 4:09 AM, Volker Halle wrote:
>>>> Mark Berryman schrieb am Dienstag, 18. Januar 2022 um 16:31:22 UTC+1:
>>>>
>>>>> It is almost certainly the emulation since the same code works fine on
>>>>> real hardware.
>>>>
>>>> Mark,
>>>>
>>>> are you running your myslqd process with DECC$SHR_EV56 linked 21-DEC-2016
>>>> 13:36:58.27 ?
>>>>
>>>> The exception is happening in DECC$SHR_EV56 code.
>>> MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
>>> against is:
>>>
>>> Image Identification Information
>>>
>>> image name: "DECC$SHR_EV56"
>>> image file identification: "V8.4-00"
>>> image file build identification: "XE6K-0100140000"
>>> link date/time: 22-MAY-2017 22:49:13.75
>>> linker identification: "A13-04"
>>>
>>> However, the version I am currently using on my system is:
>>>
>>> Image Identification Information
>>>
>>> image name: "DECC$SHR_EV56"
>>> image file identification: "V8.4-00"
>>> image file build identification: "XE80-F4N-000054"
>>> link date/time: 22-AUG-2020 07:02:43.80
>>> linker identification: "A13-04"
>>>
>>> Mark Berryman
>>
>> From my system...
>>
>> Image Identification Information
>> image name: "DECC$SHR_EV56"
>> image file identification: "V8.4-00"
>> image file build identification: "XE3T-0100120000"
>
>
> XE3T is V8.4-2L1
> XE6K is V8.4-2L2 (the EV6 optimized version of -2L1)
>
>
>

Just wondering, does AXPbox support EV6 instructions?

--
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 1/20/2022 6:53 PM, Dave Froble wrote:
> On 1/20/2022 3:00 PM, Robert A. Brooks wrote:
>> On 1/20/2022 2:53 PM, issinoho wrote:
>>> On Thursday, 20 January 2022 at 18:38:53 UTC, Mark Berryman wrote:
>>>> On 1/20/22 4:09 AM, Volker Halle wrote:
>>>>> The exception is happening in DECC$SHR_EV56 code.
>>>> MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
>>>> against is:
>>>>
>>>> Image Identification Information
>>>>
>>>> image name: "DECC$SHR_EV56"
>>>> image file identification: "V8.4-00"
>>>> image file build identification: "XE6K-0100140000"
>>>> link date/time: 22-MAY-2017 22:49:13.75
>>>> linker identification: "A13-04"
>>>>
>>>> However, the version I am currently using on my system is:
>>>>
>>>> Image Identification Information
>>>>
>>>> image name: "DECC$SHR_EV56"
>>>> image file identification: "V8.4-00"
>>>> image file build identification: "XE80-F4N-000054"
>>>> link date/time: 22-AUG-2020 07:02:43.80
>>>> linker identification: "A13-04"
>>>
>>>  From my system...
>>>
>>>          Image Identification Information
>>>                    image name: "DECC$SHR_EV56"
>>>                  image file identification: "V8.4-00"
>>>                  image file build identification: "XE3T-0100120000"
>>
>>
>> XE3T is V8.4-2L1
>> XE6K is V8.4-2L2 (the EV6 optimized version of -2L1)
>
> Just wondering, does AXPbox support EV6 instructions?

AXPbox emulate ES40 that is EV67 based, so it should.

Arne

On Thursday, January 20, 2022 at 7:04:22 PM UTC-5, Arne Vajhøj wrote:
> On 1/20/2022 6:53 PM, Dave Froble wrote:
> > On 1/20/2022 3:00 PM, Robert A. Brooks wrote:
> >> On 1/20/2022 2:53 PM, issinoho wrote:
> >>> On Thursday, 20 January 2022 at 18:38:53 UTC, Mark Berryman wrote:
> >>>> On 1/20/22 4:09 AM, Volker Halle wrote:
> >>>>> The exception is happening in DECC$SHR_EV56 code.
> >>>> MariaDB is built /ARCH=EV56. The version of DECC$SHR_EV56 it was linked
> >>>> against is:
> >>>>
> >>>> Image Identification Information
> >>>>
> >>>> image name: "DECC$SHR_EV56"
> >>>> image file identification: "V8.4-00"
> >>>> image file build identification: "XE6K-0100140000"
> >>>> link date/time: 22-MAY-2017 22:49:13.75
> >>>> linker identification: "A13-04"
> >>>>
> >>>> However, the version I am currently using on my system is:
> >>>>
> >>>> Image Identification Information
> >>>>
> >>>> image name: "DECC$SHR_EV56"
> >>>> image file identification: "V8.4-00"
> >>>> image file build identification: "XE80-F4N-000054"
> >>>> link date/time: 22-AUG-2020 07:02:43.80
> >>>> linker identification: "A13-04"
> >>>
> >>> From my system...
> >>>
> >>> Image Identification Information
> >>> image name: "DECC$SHR_EV56"
> >>> image file identification: "V8.4-00"
> >>> image file build identification: "XE3T-0100120000"
> >>
> >>
> >> XE3T is V8.4-2L1
> >> XE6K is V8.4-2L2 (the EV6 optimized version of -2L1)
> >
> > Just wondering, does AXPbox support EV6 instructions?
> AXPbox emulate ES40 that is EV67 based, so it should.
>
> Arne

Actually, depending upon which variant of the ES40 was emulated, it may be based on the EV6 only and NOT EV67 which came later.

The variants that know are listed below:

AlphaServer ES40 6/500 {EV6}
AlphaServer ES40 6/667 {EV6}
AlphaServer ES40 67/667 {EV67}
AlphaServer ES40 68/883 {EV68}

Not being familiar with the AXPbox setup, I don't know which instruction set is emulated. The EV67 introduced the CIx instructions which are not likely to be relevant here, but could be an issue with a true EV6 implementation.

The discussion about EV6 instruction emulation by AXPbox is moot in the context of this thread. The process crash happens on a VSI OpenVMS V8.4-2L1 system, which is not the EV6 optimized version.

The ACCVIO happens on a return from executing SYS$GETSYIW, code which probably did not change for the last 25 years...

I've asked issinoho to step through the failing routine with the debugger and/or try to write a little reproducer of the c$$get_page_mask call to SYS$GETSYIW.

Volker.

Volker Halle schrieb am 21.01.2022 um 08:49:
> The discussion about EV6 instruction emulation by AXPbox is moot in the context of this thread. The process crash happens on a VSI OpenVMS V8.4-2L1 system, which is not the EV6 optimized version.
>
> [snip]
Beyond that, I'm pretty sure that V8.4-2L2 would not even boot if the
EV6 instructions are not available.

Hans.

On Friday, January 21, 2022 at 5:08:07 PM UTC-5, Hans Bachner wrote:
> Volker Halle schrieb am 21.01.2022 um 08:49:
> > The discussion about EV6 instruction emulation by AXPbox is moot in the context of this thread. The process crash happens on a VSI OpenVMS V8.4-2L1 system, which is not the EV6 optimized version.
> >
> > [snip]
> Beyond that, I'm pretty sure that V8.4-2L2 would not even boot if the
> EV6 instructions are not available.
>
> Hans.

Subtle but distinct difference here. EV67 introduced additional instructions that as I stated and Volker also stated are not the issue here. But... it is important to note that if AXPbox is a true EV6 implementation, there is the possibility that an EV67 code base COULD fail because of a missing instruction encoding. Again, not likely in code that would allow the system to boot properly in any case.