bad dumpfile

[Willem Grooters]

Sorry, forgot the attachement....

Willem

[Dale A. Marcy]

To create a new dumpfile, use the following command procedure and follow directions:

@sys$update:swapfiles

[Willem Grooters]

I hoped it would all help....
But no - but I may have made a mistake (though the system should handle it).

* I created a new dumpfile using @sys$update:swapfiles.
* rebooted
* during reboot, ^P and CRASH on prompt (this I should not have done?)
* boot
* examine CLUE output:

$ type clue*.LOG

SYS$SYSROOT:[SYSMGR]CLUE$STARTUP_DIANA.LOG;21

$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))

OpenVMS (TM) system dump analyzer
%SDA-E-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha dump

OpenVMS (TM) system analyzer

%CLUE-I-CLEANUP, housekeeping started...
%CLUE-I-MAXBLOCK, maximum blocks allowed 5000 blocks
%CLUE-I-STAT, total of 8 CLUE files, 504 blocks.
SYSTEM job terminated at 10-AUG-2004 20:47:23.53

Accounting information:
Buffered I/O count: 136 Peak working set size: 11472
Direct I/O count: 229 Peak virtual size: 180416
Page faults: 803 Mounted volumes: 0
Charged CPU time: 0 00:00:01.11 Elapsed time: 0 00:00:07.77
$

ANA/CRASH didn't do much good either, the very same message.
Now ANA/CRASH/OVER shows:

$ ANA/crash SYS$SYSTEM:SYSDUMP.DMP/OVER

OpenVMS (TM) system dump analyzer
%SDA-W-NOTALPHADUMP, dump file does not contain an OpenVMS Alpha dump
%SDA-W-DUMPEMPTY, dump file contains no valid dump
%SDA-W-INCDUMPFORM, dump file format incompatible with this version of SDA
...analyzing an Alpha full memory dump in override mode...

%LIB-F-BADBLOSIZ, bad block size

I'll try to OPCCRASH from VMS (then there SHOULD be a valid dump, I guess...)

Willem

[Willem Grooters]

... and that did the trick. I now have a valid dumpfile, which can be analyzed.

To summarize:

In case of an invalid dumpfile like above, do this:

1. $ @SYS$UPDATE:AUTOGEN GETDATA TESTFILES NOFEEDBACK
2. Keep the size of SYSDUMP.DMP
3. if SYSDUMP.DMP is smaller than this calculated size:
3.a. $ @SYS$UPDATE:SWAPFILES
3.a.1 leave pagefile sizes unchanged
3.a.2 Enter new (calculated) size of DUMPFILE.DMP
3.b I assume (haven't tried) that if SYSDUMP.DMP is larger than calculated, you won't need to re-create a new dumpfile. But here I may be wrong
4. Reboot the system
5. After system has come up:
6. $ MCR OPCCRASH
7. Boot the system

If step 6 isn't done, I think the dumpfile will NOT be created properly. CRASH on the SRM prompt didn't work (but I may have issued it too early (during boot), I may have neded to wait until system was up).

Anyway, so far so good. Now wait for the next (real) crash...

Thanx to all.

Willem

[Volker Halle]

Willem,

your attachment shows, that you had a good and big enough (443600. blocks) dumpfile on that system disk. It had been written to under V7.3-2 (you'll see the string V7.3-2 and the nodename, process name and system type in the first block). The file was also perfectly contiguous (just 1 retrieval pointer with the length of the file).

If you want to look just at the file header, use DUMP/HEADER/BLOCK=COUNT=0 !

In your first attempt to create a dump with CTRL-P CRASH, you may have been too early during boot. Once STARTUP executes, the system is ready to write a dump. Did you capture the console output ? It would have told you, if a dump has been written.

Note that you can have AUTOGEN create the dumpfile for you. Just let it run beyond the GENFILES phase. If AUTOGEN creates a new (smaller) dumpfile, don't forget to purge the old one AFTER the next reboot.

As you observed MACHINECHK crashes in ERRLOG.SYS, be aware that there may be situations (due to hardware errors), which prevent the dumpfile write to complete ! This may well explain the message from SDA:

%SDA-F-DUMPINCOMPL, the dump file write was not completed

There is no need to run OPCCRASH to 'create' the dumpfile. @AUTOGEN or @SWAPFILES creates the file. And if the system crashes, it writes the dump into SYSDUMP.DMP.

Now let's wait for the real crash...

Volker.

[Antoniov.]

Willem,
thank you for information.
Will be useful next time.

Antonio Vigliotti

[Jan van den Ende]

Anyway, so far so good. Now wait for the next (real) crash...
/quote>

wishing you (and expecting) a looooooooooooong wait!

jpe

[Helmut Ammer]

Willem,

now there are more questions than answers.
DUMPSTYLE is set to 9 which means selective and compressed dump (bit 0 and 3). See
HELP SYS_PARA DUMPSTYLE in SYSGEN.
But SDA in your log says "...analyzing an Alpha full memory dump in override mode...". Also you get the message %SDA-W-INCDUMPFORM.
But in CLUE logfile you can see "...analyzing an Alpha compressed selective memory dump...".
This looks like your ANA/CRASH is using a different file as CLUE?!?
Please can you provide the console log of a crash and the line with the dumpfile from SHOW DEVICE/SYS SYS$SYSDEVICE:!

Helmut

[Willem Grooters]

Helmuth,
the CLUE logging is created during startup - and SDA was started using SYS$SYSTEM:SYSDUMP.DMP. So I am puzzled as well now.

[Willem Grooters]

Not exactly, but I think I found the solution in the fact that there is now an idea what happened: Something went wrong during writing the dumpfile (see thread on memory problems).
Helmuth's suggestion is woirthwhile but first I need to find some machine where I can actually DUMP the screen....