graphs and report creation failure

[FELIX WONG_1]

Hi,

I've had an OVMS server 800 (1Gb memory)running OVMS v7.32
with vms_732_update_v0800 installed recently.
Before the above patch installation , my graphs and reports creation was working ok.

Unfortunately after the vms732_update_v0800 was installed, my graphs and reports creation starts failing.

It returns with the following errors and my batch job was aborted.

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
201C, PC=FFFFFFFF808C2378, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
000000000000201C
FFFFFFFF808C2378
000000000000001B

Register dump:
R0 = 0000000040000000 R1 = 0000000000000056 R2 = 00000000005695EE
R3 = 0000000000645D58 R4 = 000000007B5E00E0 R5 = 0000000000645D58
R6 = 0000000000000000 R7 = 000000000000000D R8 = 0000000000000001
R9 = 00000000002C4650 R10 = 00000000000347E8 R11 = 000000007FFCDBE0
R12 = 000000007FFCDA60 R13 = 000000007AC2E7E0 R14 = 0000000000000000
R15 = 000000007AC2DE20 R16 = 000000000000201C R17 = 0000000000000001
R18 = 0000000000000020 R19 = 0000000000000000 R20 = 00000000003822B8
R21 = 0000000000000000 R22 = 0000000000000000 R23 = 0000000000000001
R24 = 000000007B5EA508 R25 = 0000000000000001 R26 = FFFFFFFF808F05C0
R27 = 000000007B5DE910 R28 = 0000000000000001 R29 = 000000007AB4CB80
SP = 000000007AB4CAF0 PC = FFFFFFFF808C2378 PS = 300000000000001B


I tried to use the system account to re-submit my job again, also increase the quota limit of the system account couple of times and it doesn't help.

Maxjobs: 0 Fillm: 4096 Bytlm: 400000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 10 DIOlm: 150 WSdef: 2048
Prio: 4 ASTlm: 250 WSquo: 4096
Queprio: 0 TQElm: 100 WSextent: 16384
CPU: (none) Enqlm: 2000 Pgflquo: 1048576

As soon as I uninstall the vms732_update_v0800 and back to the original vms732_update_v0600,it worked ok.


Graphs & reports creation was under 3rd party tools (Computer Associate CA Advise IT) using DCL command (see sample below)

$advise performance report performance
/process_statistics=focus=(traditional)-
/beg=04-DEC-2006:00:00
/end=04-DEC-2006:23:58-
/output=output_directory:TEST2_processtraditional_2006DEC04.rpt


Since vms732_update_v0800 is a bundle of patches, which one is causing the problem

Doesn't anyone has any idea ?

Thanks

Felix Wong

[Volker Halle]

Felix,

consider to enable a process dump:

$ SET PROC/DUMP
$ ADVISE ...

This should write an imagename.DMP file in the current directory. You need to replace 'imagename' with the name of your image in the following commands:

$ ANAL/CRASH imagename.DMP
SDA> EXA/INS 808C2378
SDA> EXIT

will show you the failing instruction and the execlet it's in.

$ ANAL/PROC imagename.DMP
DBG> SHOW CALL

will show the call stack.

With this information, we may be able to guss what went wrong.

Volker.

[FELIX WONG_1]

One thing I forgot to mention.
My command procedure contains numerous of
($advise ...) command lines to generate the graphs & reports.

When I ran the failed portion in interactive mode, it worked ok.
However, it failed only when I put all these together and submit to batch.


The way the command file works is to look into a data file which contains different machines, then it runs numerous ($advise...)
command to generate the graphs & reports.
It ran ok for the first few nodes, then failed.

I guess it's an issue with the process quota,
or resources related. Not sure which one.

[Volker Halle]

Felix,

the ADVISE command failed with ACCVIO, when the code was trying to access virtual address 201C (@R16). The suggested process dump would be the ideal tool to capture more information about this bug, as it saves the complete process context and information at the time the problem happens. It should be easy to find out, if there may be a process quota problem leading to the ACCVIO.

Volker.

[Hein van den Heuvel]

You should really ask CA for help.
You paid good money for the product no?
Get the support you deserve!

Anyways... just imagine they have some problem with the error handling passing by value where an address was expected. In that case the 201C could have been intende to be an error code. It translates to:
$ exit %x201c
%SYSTEM-F-SHARTOOBIG, new version of shareable image too big; relink all images


Given the scenatio this could be a reasonable problem to have if the advise image happens to be dynamically activating images.

I would use
$SET PROC/PRIV=CMKRNL
$SET WATCH FILE /CLA=MAJOR
$ADVISE...

Now see whether the last file access before the dump is in fact a shared file. (.EXE) lookup.

Still... it would be up to CA to help you (relink).

Maybe there are alternate (lower) versions of the (shareable) images involved available which happen to work?

Good luck,
Hein.

[Hein van den Heuvel]

Hmm... not knowing how CA Advise installs myself, you might want to try a re-install.
It may do a relink in that process.

fwiw,
Hein.