%SYSTEM-F-ACCVIO after fresh VMS installation

[MG]

After a fresh [re]installation of VMS Alpha V8.4 on a DS10 (with the
latest V7.3-1 firmware, as can be seen below), I got multiple access
violation errors. See the below console log:
------------------[ begin ]------------------
AlphaServer DS10 466 MHz Console V7.3-1, Feb 27 2007 13:17:58

CPU 0 booting

(boot dya1.0.0.15.0 -flags 0)
block 0 of dya1.0.0.15.0 is a valid boot block
reading 1230 blocks from dya1.0.0.15.0
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 99c00(629760)
initializing HWRPB at 2000
initializing page table at 3fd2a000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.4
© Copyright 1976-2010 Hewlett-Packard Development Company, L.P.

%DECnet-I-LOADED, network base image loaded, version = 05.17.00

%DECnet-W-NOOPEN, could not open SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT


Installing required known files...
%SYSTEM-F-OPCDEC, opcode reserved to OpenVMS fault at
PC=0000000000044E94, PS=00
00001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000003
Name = 000000000000043C
0000000000044E94
000000000000001B

Register dump:
R0 = 000000007FFCF87C R1 = 00000000000107F0 R2 = 00000000000102B0
R3 = 00000000000200B4 R4 = 000000007FFCF814 R5 = 000000007FFCF974
R6 = 000000007FFA0ED0 R7 = 000000007FFA0ED0 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 000000007FFCDA98 R13 = 000000007AEFF360 R14 = 0000000000000000
R15 = 000000007AEFE970 R16 = 000000007FFCF884 R17 = 000000007AF02318
R18 = 000000007FFCF814 R19 = 000000007FFCF974 R20 = 0000000000000028
R21 = 0000000000000008 R22 = 0000000000000000 R23 = 0000000000000000
R24 = 00000000000102B0 R25 = 0000000000000000 R26 = 0000000000030074
R27 = 0000000000015958 R28 = 0000000000000000 R29 = 000000007AE4BA00
SP = 000000007AE4BA00 PC = 0000000000044E94 PS = 000000000000001B
%DCL-W-SKPDAT, image data (records not beginning with "$") ignored

Configuring devices...

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=000000000000
0033, PC=0000000000030000, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000000033
0000000000030000
000000000000001B

Register dump:
R0 = 000000007FFCF87C R1 = 0000000000000050 R2 = 0000000000000000
R3 = 000000007AFBE412 R4 = 000000007FFCF814 R5 = 000000007FFCF974
R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 000000007FFCDA98 R13 = 000000007AEFF360 R14 = 0000000000000000
R15 = 000000007AEFE970 R16 = 000000007FFCF884 R17 = 000000007AF02318
R18 = 000000007FFCF814 R19 = 000000007FFCF974 R20 = 0000000000000028
R21 = 0000000000000018 R22 = 0000000000000000 R23 = 0000000000000000
R24 = 00000000000102B0 R25 = 0000000000000006 R26 = 000000007AF8D378
R27 = 00000000000102B0 R28 = 0000000000310003 R29 = 000000007AE4BBB0
SP = 000000007AE4BBA0 PC = 0000000000030000 PS = 200000000000001B
%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:41.59 %%%%%%%%%%%
Operator _LETHUC$OPA0: has been enabled, username SYSTEM

%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:41.59 %%%%%%%%%%%
Operator status for operator _LETHUC$OPA0:
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, CLUSTER, SECURITY,
LICENSE, OPER1, OPER2, OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9,
OPER10,
OPER11, OPER12

%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:42.96 %%%%%%%%%%%
Logfile has been initialized by operator _LETHUC$OPA0:
Logfile is LETHUC::SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1

%SYSTEM-I-BOOTUPGRADE, security auditing disabled
%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:42.96 %%%%%%%%%%%
Operator status for operator LETHUC::SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, CLUSTER, SECURITY,
LICENSE, OPER1, OPER2, OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9,
OPER10,
OPER11, OPER12

%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:43.38 %%%%%%%%%%%
Message from user SYSTEM on LETHUC
%JBC-E-OPENERR, error opening SYS$COMMON:[SYSEXE]QMAN$MASTER.DAT;

%LICENSE-F-EMTLDB, license database contains no license records
%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:43.38 %%%%%%%%%%%
Message from user SYSTEM on LETHUC
-RMS-E-FNF, file not found

%SYSTEM-I-BOOTUPGRADE, security server not started
%SYSTEM-I-BOOTUPGRADE, ACME server not started
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=000000000029
1613, PC=0000000000030000, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000291613
0000000000030000
000000000000001B

Register dump:
R0 = 000000007FFCF87C R1 = 0000000000000050 R2 = 0000000000000000
R3 = 000000007AFBE412 R4 = 000000007FFCF814 R5 = 000000007FFCF974
R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 0000000000000000 R13 = 000000007AEFF360 R14 = 00000000002915E0
R15 = 000000007AEFE970 R16 = 000000007FFCF884 R17 = 000000007AF02318
R18 = 000000007FFCF814 R19 = 000000007FFCF974 R20 = 0000000000000028
R21 = 0000000000000018 R22 = 0000000000000000 R23 = 0000000000000000
R24 = 00000000000102B0 R25 = 0000000000000006 R26 = 000000007AF8D378
R27 = 00000000000102B0 R28 = 0000000000310003 R29 = 000000007AE4BBB0
SP = 000000007AE4BBA0 PC = 0000000000030000 PS = 200000000000001B
*********************************************************
%SYSTEM-W-ERREX, error executing @SYS$STARTUP:TDF$UTC_STARTUP.COM
%SYSTEM-I-SETTZ, to set your local time zone use:

$ @SYS$MANAGER:UTC$TIME_SETUP.COM

*********************************************************
NET$STARTUP, Network not started due to UPGRADE boot
%SYSTEM-W-NOSUCHDEV, no such device available
%%%%%%%%%%% OPCOM 28-JAN-2012 22:19:46.44 %%%%%%%%%%%
Message from user SYSTEM on LETHUC
%LICENSE-E-NOAUTH, DEC OPENVMS-ALPHA use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager


%LICENSE-E-NOAUTH, DEC OPENVMS-ALPHA use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
Startup processing continuing...

%SYSTEM-I-BOOTUPGRADE, Coordinated Startup not performed
%DCL-W-ACTIMAGE, error activating image SECURESHRP
-CLI-E-IMGNAME, image file
LETHUC$DKA1:[SYS0.SYSCOMMON.][SYSLIB]SECURESHRP.EXE;1
-SYSTEM-F-PROTINSTALL, protected images must be installed
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=000000000029
1613, PC=0000000000030000, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000291613
0000000000030000
000000000000001B

Register dump:
R0 = 000000007FFCF87C R1 = 0000000000000050 R2 = 0000000000000000
R3 = 000000007AFBE412 R4 = 000000007FFCF814 R5 = 000000007FFCF974
R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 0000000000000000 R13 = 000000007AEFF360 R14 = 00000000002915E0
R15 = 000000007AEFE970 R16 = 000000007FFCF884 R17 = 000000007AF02318
R18 = 000000007FFCF814 R19 = 000000007FFCF974 R20 = 0000000000000028
R21 = 0000000000000018 R22 = 0000000000000000 R23 = 0000000000000000
R24 = 00000000000102B0 R25 = 0000000000000006 R26 = 000000007AF8D378
R27 = 00000000000102B0 R28 = 0000000000210002 R29 = 000000007AE4BBB0
SP = 000000007AE4BBA0 PC = 0000000000030000 PS = 200000000000001B


CDSA-I-InitCDSA, Initializing CDSA...
MDS installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
Module installed successfully.
%LIB-E-ACTIMAGE, error activating image
LETHUC$DKA1:[SYS0.SYSCOMMON.][SYSLIB]CDS
A$INHRSDUMMY_SHR.EXE;1
-IMGACT-F-ISD_SIZ, image section descriptor length is invalid
Could not find RegisterCDSAModule function in
/sys$share/cdsa$inhrsdummy_shr.exe
!
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when CDSA$INHRSEMM_SHR referenced DECC$SHR
%LIB-E-ACTIMAGE, error activating image CDSA$INHRSEMM_SHR
Could not find RegisterCDSAModule function in
/sys$share/cdsa$inhrsemm_shr.exe!
Module installed successfully.
CDSA-I-InitCDSA, CDSA Initialization complete

CDSA-I-InitSecDel, Initializing Secure Delivery...
Install completed successfully.
Install completed successfully.
Module installed successfully.
Module installed successfully.
CDSA-I-InitSecDel, Secure Delivery Initialization complete

%DCL-W-ACTIMAGE, error activating image SECURESHRP
-CLI-E-IMGNAME, image file
LETHUC$DKA1:[SYS0.SYSCOMMON.][SYSLIB]SECURESHRP.EXE;1
-SYSTEM-F-PROTINSTALL, protected images must be installed
%DCL-W-IVVALU, invalid value syntax - see command documentation
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\
SYSTEM job terminated at 28-JAN-2012 22:20:52.54

Accounting information:
Buffered I/O count: 12114 Peak working set size:
10800
Direct I/O count: 6030 Peak virtual size:
192480
Page faults: 7343 Mounted volumes:
0
Charged CPU time: 0 00:00:09.37 Elapsed time: 0
00:01:16.41
-------------------[ end ]-------------------

This is new for me and, before this, nothing like this has happened
so far. I have another, near identical DS10 (with largely the same
hardware configuration, except for different PCI options; like a NEC
USB controller and different type video card) and nothing like this
happened so far.

I did recently add a larger (68-pin) SCSI disk, which earlier also
gave me access violations, so I thought of installing VMS on another
disk (on the same channel and SA 5300A, with "DYA0" and "DYA1" being
two logical RAID level 0 disks) controller. The access violations
have not decreased.

I also performed the SRM tests, which all passed successfully. So, I
have no idea what's going on. Could it be that the disk is 'upsetting'
the controller?

Does this look familiar? Any help will be greatly appreciated.

- MG

[Phillip Helbig---undress to reply]

In article <4f24836c$0$6988$e4fe...@news2.news.xs4all.nl>, MG

<marc...@SPAMxs4all.nl> writes:

> After a fresh [re]installation of VMS Alpha V8.4

Presumably no patches?

[MG]

On 29-1-2012 10:24, Phillip Helbig---undress to reply wrote:
> Presumably no patches?

Yes, nothing, a fresh installation of vanilla V8.4. (Which never
before gave me problems.)

- MG

[MG]

On 29-1-2012 0:23, MG wrote:
> I did recently add a larger (68-pin) SCSI disk, which earlier also

> gave me access violations [...]

The above phrase is a bit too suggestive, what I meant rather is that
with and since that disk, I've been getting access violations. Though,
I can't say with absolute certainty that the disk is the culprit. I'm
going to put the disk in my other DS10 today, to see what will happen.

- MG

[MG]

On 29-1-2012 0:23, MG wrote:

> [...]

I have swapped out the disk I had thought to be defective, but errors
remain! I don't have too many 68-pin disks and when I booted from an
80-pin (SCA) disk with a converter, it installed fine and such, but
during the startup it would hang each time at the MSCP disk serving
configuration ("%MSCPLOAD-I-CONFIGSCAN").

What else could be going on? The RAM can't be it, at least I really
don't think so, as I've been running the system with the same RAM for
quite some time now and only until recently I've been getting these
strange and very frustrating errors.

- MG

[MG]

On 29-1-2012 12:23, MG wrote:
> [...]

After yet another reinstallation, more and different errors!

------------------[ begin ]------------------
AlphaServer DS10 466 MHz Console V7.3-1, Feb 27 2007 13:17:58

CPU 0 booting

(boot dya0.0.0.15.0 -flags 0)
block 0 of dya0.0.0.15.0 is a valid boot block
reading 1230 blocks from dya0.0.0.15.0

bootstrap code read in
base = 200000, image_start = 0, image_bytes = 99c00(629760)
initializing HWRPB at 2000
initializing page table at 3fd2a000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.4
© Copyright 1976-2010 Hewlett-Packard Development Company, L.P.

%DECnet-I-LOADED, network base image loaded, version = 05.17.00

%DECnet-W-NOOPEN, could not open SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT

%RMS-W-RTB, 23352 byte record too large for user's buffer
%RMS-W-RTB, 29555 byte record too large for user's buffer


%DCL-E-OPENIN, error opening
SYS$SYSROOT:[SYS$STARTUP]VMS$CONFIG-050_OPCOM.COM;
as input
-RMS-E-FNF, file not found
%SYSTEM-I-BOOTUPGRADE, security auditing disabled

%JBC-E-OPENERR, error opening SYS$COMMON:[SYSEXE]QMAN$MASTER.DAT;

-RMS-E-FNF, file not found

%LICENSE-F-EMTLDB, license database contains no license records

%SYSTEM-I-BOOTUPGRADE, security server not started
%SYSTEM-I-BOOTUPGRADE, ACME server not started

NET$STARTUP, Network not started due to UPGRADE boot
%SYSTEM-W-NOSUCHDEV, no such device available

%LICENSE-E-NOAUTH, DEC OPENVMS-ALPHA use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
Startup processing continuing...

%SYSTEM-I-BOOTUPGRADE, Coordinated Startup not performed

%SYSTEM-F-OPCDEC, opcode reserved to OpenVMS fault at

PC=000000000001C9E4, PS=00

00001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000003
Name = 000000000000043C

000000000001C9E4
000000000000001B

Register dump:
R0 = 0000000000000001 R1 = 0000000000000005 R2 = 00000000008FB0C8
R3 = 000000000097A115 R4 = 000000000097A530 R5 = 000000000097A094
R6 = 00000000008FAB1C R7 = 0000000000000200 R8 = 000000000097A000
R9 = 000000000097A910 R10 = 0000000000000005 R11 = 0000000000000001
R12 = 000000000097A110 R13 = 0000000006BA8001 R14 = 0000000000000005
R15 = 000000000097A510 R16 = 000000007AE4B158 R17 = 0000000000000000
R18 = 000000000097A115 R19 = 000000000097A536 R20 = 0000000000000002
R21 = 000000007AE4B204 R22 = 000000007AE4B274 R23 = 0000000000000070
R24 = 000000007AE4B148 R25 = 0000000000000001 R26 = 00000000008EFEA4
R27 = 00000000009F44E0 R28 = 0000000000000000 R29 = 000000007AE4B140
SP = 000000007AE4B140 PC = 000000000001C9E4 PS = 000000000000001B


CDSA-I-InitCDSA, Initializing CDSA...
%DCL-W-ACTIMAGE, error activating image CMA$OPEN_RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]CMA$OPEN_RTL.EXE

;1
-IMGACT-F-ISD_SIZ, image section descriptor length is invalid

%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use

CDSA-I-InitCDSA, CDSA Initialization complete

CDSA-I-InitSecDel, Initializing Secure Delivery...

%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use
%DCL-W-ACTIMAGE, error activating image PTHREAD$RTL
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]PTHREAD$RTL.EXE;
1
-SYSTEM-F-VA_IN_USE, virtual address already in use

CDSA-I-InitSecDel, Secure Delivery Initialization complete

%DCL-W-ACTIMAGE, error activating image SMI$OBJSHR
-CLI-E-IMGNAME, image file
LETHUC$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SMI$OBJSHR.EXE;1
-IMGACT-F-BAD_FIXUPVEC, the fixup vector contains inconsistent data

%DCL-W-IVVALU, invalid value syntax - see command documentation
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\PARAMETERS\

SYSTEM job terminated at 30-JAN-2012 01:14:02.73

Accounting information:
Buffered I/O count: 7367 Peak working set size:
7584
Direct I/O count: 3936 Peak virtual size:
188560
Page faults: 9635 Mounted volumes:
0
Charged CPU time: 0 00:00:04.77 Elapsed time: 0
00:00:15.63
-------------------[ end ]-------------------

I have absolutely no idea what's going on...

- MG

[VAXman-]

In article <4f25e1cd$0$6893$e4fe...@news2.news.xs4all.nl>, MG <marc...@SPAMxs4all.nl> writes:
>On 29-1-2012 12:23, MG wrote:
>> [...]
>
>After yet another reinstallation, more and different errors!
>------------------[ begin ]------------------
>AlphaServer DS10 466 MHz Console V7.3-1, Feb 27 2007 13:17:58
>
>CPU 0 booting
>
>(boot dya0.0.0.15.0 -flags 0)

-------^^^^

Have this SmartArray configured properly?

What firmware is installed?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[MG]

On 30-1-2012 1:38, VAXman- @SendSpamHere.ORG wrote:
> What firmware is installed?

The latest, or latest available (that I'm aware of), for the DS10:
V7.3-1. Both my DS10s have this exact same firmware, but only one
of the two DS10s is giving me all of these extremely frustrating
errors (including the mind-boggling access violation errors).

(From the first post:
"AlphaServer DS10 466 MHz Console V7.3-1, Feb 27 2007 13:17:58")

- MG

[Jeremy Begg]

Hi MG,

I'd say your DS10 hardware is kaput. It could be anything in the path from
the disk to the CPU. And RAM can fail too.

Regards,

Jeremy Begg

[MG]

On 30-1-2012 3:40, Jeremy Begg wrote:
> I'd say your DS10 hardware is kaput. It could be anything in the path
> from the disk to the CPU. And RAM can fail too.

If that's so, how is it that the entire installation procedure goes
well, without a single error and that all the hardware passes the
tests and exercises in the SRM environment? If there would be some-
thing broken in the CPU and/or RAM, wouldn't things also go terribly
wrong there?

- MG

[joukj]

At least you have the ability to rule-out/prove hardware-failures. Since
you have 2 identical systems, you can swap i.e. the disks and see if the
installed version works on the other machine.

[John Wallace]

It's possible for only a small part of RAM to be broken, and for many
operations to not use this RAM. So if in one system config the broken
RAM is unused, no fault would be observed. In a different config the
RAM may be used, and symptoms would show.

"Opcode reserved to DEC" (aka "Opcode reserved to OpenVMS") doesn't
sound like the usual likely symptom, but...

I've lost track of whether the problem follows the memory or follows
the motherboard or follows the disk. Work that out and you may get
somewhere. This is joukj's suggestion wrt moving the disks. Bear in
mind that if dubious memory was in use when you did the OS install,
even if the current symptoms didn't show at that time, the resulting
installed image may be dubious too.

Another item I might add to the "To Do" list would be to put the
suspect RAM in a box where it can be tested with MemTestx86 or similar.

[John Wallace]

should read
"In a different config the RAM may be used, and symptoms may or may
not show immediately. If the RAM error led to an invalid instruction
being executed, that would show right away. If the RAM error led to
invalid data which propagated silently e.g. led to corrupt data on a
disk where VMS was being installed, that may not show until much
later."

It's a bit unlikely but not necessarily impossible.

[VAXman-]

It's a smart array. Build VMS on your other DS10 and then, boot this
errant one from that build.

[Bob Koehler]

In article <4f2606bc$0$6863$e4fe...@news2.news.xs4all.nl>, MG <marc...@SPAMxs4all.nl> writes:

The hardware passes wich tests? Power on tests prior to boot are
often quite summary. Try explicitly running some tests from the
console.

[MG]

On 30-1-2012 15:37, Bob Koehler wrote:
> The hardware passes wich tests? Power on tests prior to boot are
> often quite summary. Try explicitly running some tests from the
> console.

I did, all of them (well, all that I know of). If you have specific
tests and exercises that you would recommend me, then feel free to
do so.

Actually, I have just swapped the RAM (considering the suggestions),
from one DS10 to the other and I've just reinstalled VMS and booted
it. I'm still getting errors...
------------------[ begin ]------------------
CDSA-I-InitCDSA, Initializing CDSA...
MDS install failed (error 8).
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: (Code #0)!
Module: MDS Error (Init): 3117
(Code #3117)!
Module: (Code #0)!

CDSA-I-InitCDSA, CDSA Initialization complete

CDSA-I-InitSecDel, Initializing Secure Delivery...
Install completed successfully.
Install completed successfully.

Module: MDS Error (Init): 3117
(Code #3117)!
Module: MDS Error (Init): 3117
(Code #3117)!

CDSA-I-InitSecDel, Secure Delivery Initialization complete

-------------------[ end ]-------------------

I'll swap the 5300As. But, after that, I think I'll be running out
of ideas...

- MG

[MG]

On 30-1-2012 13:14, VAXman- @SendSpamHere.ORG wrote:
> It's a smart array. Build VMS on your other DS10 and then, boot this
> errant one from that build.

I use the 5300A for the internal disks (primarily for that it's U160; I
don't have anything like a Compaq/DEC BA disk shelf/cabinet).

- MG

[FrankS]

On Jan 30, 9:59 am, MG <marcog...@SPAMxs4all.nl> wrote:
> I use the 5300A for the internal disks (primarily for that it's U160; I
> don't have anything like a Compaq/DEC BA disk shelf/cabinet).
>

The DS10 has a dual IDE controller. Find the cable, find an IDE hard
drive of any flavor, and do the system build on that drive. I would
completely remove the SmartArray controller from the system. If you
can install and build it on the IDE drive, then install the patches
for v8.x, one of which I believe fixes a problem with the SmartArray
driver.

Once you have a working, up-to-date build on the IDE drive, then
reinstall the SmartArray controller and boot off the installation CD.
Perform an image backup from the IDE drive to the SmartArray drive.

If the problem happens again when booting off the IDE, or only when
booting off the SmartArray drive then you've narrowed things down a
bit. If the problem goes away after using an up-to-date build then
you know it was a software issue.

[Michael Moroney]

John Wallace <johnwa...@yahoo.co.uk> writes:

>> "Opcode reserved to DEC" (aka "Opcode reserved to OpenVMS") doesn't
>> sound like the usual likely symptom, but...

"Opcode reserved to DEC" is (was) correct. It originally meant machine
code on a VAX that didn't translate to any valid VAX instruction. It
didn't matter whether the VAX was running VMS, Unix or anything else, the
instruction still does not mean anything to the VAX. Since then
equivalents have been created for Alphas and Itanics.

The usual cause is attempting to execute data or corrupted instructions
or so forth.

[abrsvc]

On Jan 30, 2:07 pm, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:

I suppose that you could get into Xdelta and check the failing
instruction...

[MG]

On 29-1-2012 0:23, MG wrote:
> [...]

Latest update. I'll summarize what I roughly did:

o Removed/interchanged various SCSI disks;
o Removed/interchanged SCSI HBA's (Symbios & 5300A)
and flatcables;
o Tried various IDE-[P]ATA disks[*], on either IDE
controller ("DQAn" & "DQBn" on the DS10);
o Reinstalled VMS several times.

[*: I've tried both a 80 Gbyte and 250 Gbyte disk, since I remember
having read that certain sizes aren't supported/recognized correctly
by the controller.]

Conclusion so far: Nothing I've tried (and I've tried just about
anything, which has demanded a lot of time and energy) has been
entirely 'failure-free' so far. Also when booting from the IDE-
[P]ATA disks, I get errors and some very strange ones (in one case
also one access violation error, like with the SCSI disks and con-
trollers) and since yesterday, I can not even boot beyond to the
point it jumps to the bootstrap code (the system simply 'hangs'
there).

This is very frustrating and I'm frankly out of ideas.

- MG

[John Wallace]

Sorry to hear nothing is really helping. Sometimes these things
happen.

Have you actually tried a more extensive memory diagnostic than the
power up tests, which do little more than "the minimum you need
to" (tm) see how much memory is there? [Sadly an easy way of doing
this for a hobbyist might be to put the questionable memory in a PC
and use memtestx86]

Or have you a good logical reason for ruling it out as unnecessary?

[joukj]

> Since you have another working Alpha, you can perform a quick test by
setting up the suspicious machine as a satelite booting from the
"correct" installation of the working alpha (make a backup before you
start). If it fails to boot in this way you have a problem with memory,
CPU or mother board, if it boots you have a problem with the disk
controllers.

Jouk

[MG]

On 4-2-2012 18:42, John Wallace wrote:
> Sorry to hear nothing is really helping. Sometimes these things
> happen.

It's sad that it often happens with the systems I seem to most care
for and cherish at the moment.

(Like in the past, I had a Sun Ultra 10 that broke down on my during
a period I was heavily involved with software development and porting
projects.)

> Have you actually tried a more extensive memory diagnostic than the
> power up tests, which do little more than "the minimum you need
> to" (tm) see how much memory is there? [Sadly an easy way of doing
> this for a hobbyist might be to put the questionable memory in a PC
> and use memtestx86]
>
> Or have you a good logical reason for ruling it out as unnecessary?

Yes, actually, I do. I have performed an even more thorough test: I
have swapped the memory from the DS10 that never gave me any problems
and the same exact type of errors and failures arise. So, I think it
is therefore safe to conclude that the memory is not the culprit.

- MG

[MG]

On 7-2-2012 12:30, joukj wrote:
> Since you have another working Alpha, you can perform a quick test by
> setting up the suspicious machine as a satelite booting from the
> "correct" installation of the working alpha (make a backup before you
> start).

I guess I could do that! However... (I'll explain below).

> If it fails to boot in this way you have a problem with memory,
> CPU or mother board, if it boots you have a problem with the disk
> controllers.

The thing is, as I wrote in my previous reply to John Wallace, that
the memory would not seem like a likely culprit; considering that
the DIMMs from the 'broken DS10' appear to work flawlessly in the
'working DS10' and that the DIMMs from the 'broken DS10' work just
fine in the 'working DS10'.

Furthermore, as far as disk controllers go: I have removed all SCSI
HBAs and in the end tried with just IDE-[P]ATA disks. The SCSI disks
would actually give more and partially allow booting (accompanied with
a large amount of access violations and other errors), but the IDE-
[P]ATA disks would not even boot up and the systems hang at the boot-
strap code loading phase.

I'm not familiar with the types of CPU and motherboard failures. One
of the few things I could do, is vacuum, dust-bust and clean possible
contacts with alcohol-soaked swabs, see if that changes anything.

I remember I cleaned the contacts of the PCI riser board and individual
PCI cards, after which they'd work fine.

(The processor in DS10s is fixed onto the motherboard, isn't it? As
far as I can tell, it's not socketed.)

- MG

[abrsvc]

Where are you located? I have numerous spare DS10s here that can be
used to try to narrow this down. I would check for proper functioning
of the CPU fan. Check the temp reading. Also, try changing out hte
power supply with one from a working system. Marginal power levels
can cause strange behavior also. While not likely, it would prove a
point.

Keep use posted and Email me should you want to swap parts.

Dan

[MG]

On 7-2-2012 14:29, abrsvc wrote:
> Where are you located?

The Netherlands.

> I have numerous spare DS10s here that can be used to try to narrow
> this down. I would check for proper functioning of the CPU fan.

The CPU fan works, as far as I can tell. It spins in a similar way
and at the same frequency as the one in the other DS10.


> Check the temp reading.

It has never risen beyond ~45° C so far. (I believe it's configured
to automatically shutdown at 60° C.)

> Also, try changing out hte power supply with one from a working system.
> Marginal power levels can cause strange behavior also. While not likely,
> it would prove a point.

I will do that, thanks for the suggestion!

> Keep use posted and Email me should you want to swap parts.

I will. (Speaking of that: I assume by swap, you mean to sell?)

- MG

[John Wallace]

But we have already eliminated all the *likely* causes, have we not?

Therefore we are on to unlikely causes (or causes which are so obvious
that none of us can see them).

I still would like to see the memory tested with a proper memory
diagnostic. It is easy to do if you have an x86 box that will take the
memory in question, and it is FAR more definitive than "I put the
suspect memory in a different system with a different config and the
symptoms did not follow the memory". The fact that the problem did not
follow the memory tells you the memory does not have a gross fault
making it completely unusable, but we knew that anyway. If it has a
fault which is dependent on the address involved, one system may use
that address, the other may not. A decent memory diagnostic stands a
chance of finding such a fault, and giving you some hard information
to help you choose what to do next.

Or am I missing something? E.g. if you put some "known good" memory in
the questionable DS10, does the problem still appear, in which case
the memory is no longer a potential suspect, the problem likely lies
elsewhere? If you have already told us this, my apologies, but I
already know my memory has multiple faults :)

[MG]

On 7-2-2012 20:29, John Wallace wrote:
> But we have already eliminated all the *likely* causes, have we not?

I guess so...

> I still would like to see the memory tested with a proper memory
> diagnostic. It is easy to do if you have an x86 box that will take the
> memory in question, and it is FAR more definitive than "I put the
> suspect memory in a different system with a different config and the
> symptoms did not follow the memory".

Well, I don't have an x86 box that will accept the memory. But, that
won't be necessary (see below).

> Or am I missing something? E.g. if you put some "known good" memory
> in the questionable DS10, does the problem still appear, in which case
> the memory is no longer a potential suspect, the problem likely lies
> elsewhere? If you have already told us this, my apologies, but I
> already know my memory has multiple faults :)

That's correct, I did (several times).

- MG

[abrsvc]

All other things being constant, I'm leaning toward a bad power
supply. Not bad enough to completely fail, but marginal enough to
create odd behavior. These are relatively simple to change. If you
can, try that first. Just change the supply with the one from the
"good" system and see what happens. If that does not resolve it, I
would suspect a bad motherboard. I do have a spare working
motherboard (less the fan) that I could part with, but I'm in the US
and the shipping wouldn't be cheap.

Dan

[MG]

On 7-2-2012 20:52, abrsvc wrote:
> All other things being constant, I'm leaning toward a bad power supply.
> Not bad enough to completely fail, but marginal enough to create odd
> behavior. These are relatively simple to change. If you can, try that
> first. Just change the supply with the one from the "good" system and
> see what happens. If that does not resolve it, I would suspect a bad
> motherboard. I do have a spare working motherboard (less the fan) that
> I could part with, but I'm in the US and the shipping wouldn't be cheap.

That sounds plausible and it's definitely worth the try!

Tonight maybe, or else tomorrow, I'll try that out. Luckily the DS10
is easy to disassemble and reassemble! (If it was a typical PC/AT type
system, I would really not look forward to it.)

- MG