- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Crash Dump Reset
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 01:07 AM
тАО08-29-2007 01:07 AM
We are having crashes after a recent hardware upgrade so we have a pretty good idea on what changed. We had no crashes for like a year or more before that, and the crash last year was when the swap/page file disk died a horrible death. No problems in understanding there, and prior to that, the last crash was 2001. Very stable system. So it is clear that the new hardware is the culprit.
The problem is that our crash dump won't update. I can't give the tech guys details on the crash dump because I don't have them.
We are NOT set up to use the page file for crash dumps. We have a separate SYS$SYSTEM:SYSDUMP.DMP file. DUMPSTYLE is set to 9 (selective, compressed, use system disk) We took a crash dump a couple of days ago but we have crashed at least twice since then without another crash dump being written.
I have heard there is some sort of interlock file but I don't know where it is and wading through the manuals has (so far) produced no joy. I've looked in System Manager's Manual, System Management Utilities Manual, and a few other miscellaneous places. I see a lot about how to analyze the dump. I see a lot about copying a dump from the page file via the CDA utility. But if there is a free-standing crash dump file in a valid path, why won't a crash overwrite the previous contents?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 02:20 AM
тАО08-29-2007 02:20 AM
Re: Crash Dump Reset
What kind of hardware upgrade was done? If it was something that might have an effect on the I/O bus (especially a drive controller or disk drive), it is quite possible that whatever is causing the crash is also preventing any further I/O to the system disk. It could be a problem with the system disk itself - maybe even a bad spot within SYSDUMP.DMP. If you have enough space, you might try creating a new dumpfile (rename the old one, create a new one, reboot) and see if the behavior changes.
Allan in Atlanta
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 02:21 AM
тАО08-29-2007 02:21 AM
Re: Crash Dump Reset
may be the system died a death without being able to write to the dumpfile, e.g. ane error on the main board etc.
Are any messages on the console or in the error log (DIAGNOSE)?
regards Kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 02:35 AM
тАО08-29-2007 02:35 AM
Re: Crash Dump Reset
We are looking at the IOD board, the chance of having a DOA memory card, and the fact that S3 cards with a big memory & a 64-bit interface can hang a system. The KGPSA we use for our SAN fits that bill perfectly. Our tech guy has found some memories to swap out and he is also bringing a new IOD board.
The DIAGNOSE command reveals some correctable ECC on the original crash, but later crashes go straight from a TIMESTAMP entry to a reboot entry. I can't check for more than that right now because the hardware tech has the system even as I type this.
The crash dump from two days ago was calling out a machine check from KERNEL mode and the K-stack was indicating (a) no currently runnning process and (b) The ECC_CORRECTABLE routine was referenced in the bowels of the stack.
We are confident that this problem is either a bad memory or a bad IOD board. (For those who don't know: IOD translates addresses from PCI bus to Alpha memory bus. That's the short answer and don't whack me for simplifying. I know it does more than that.)
My issue remains that I'm disturbed about not getting a crash dump. No, no bad spots reported on the disk. I can do an analyze RMS telling it to verify the blocks of the file and it passes that test, so the SYSDUMP.DMP isn't bad that I know of. I just am worried that I can't provide better info to my tech support guys when they ask me "What's up?" (Though the correct answer is more often "Well, we're not.")
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 02:55 AM
тАО08-29-2007 02:55 AM
Re: Crash Dump Reset
For the following bugchecks:
UNKRSTRT
KRNLSTKNV
INVSCBB
HALT
DBLERR
INVPTBR
MCHECKPAL
the dumptile will not be written unless auto_action is set to "RESTART".
Check with
$ write sys$output f$getenv("AUTO_ACTION")
or
>>> show auto_action
To change in a supported way:
>>> set auto_action RESTART
If that is already set to restart, then please provide the output of
$ mcr sysgen show dumpbug ! should be 1
$ mcr sysgen show dumpstyle
$ mcr sysgen show savedump
example:
$ write sys$output f$getenv("AUTO_ACTION")
RESTART
$ mcr sysgen show dumpbug ! should be 1
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
DUMPBUG 1 1 0 1 Boolean
$ mcr sysgen show dumpstyle
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
DUMPSTYLE 9 0 0 -1 Bitmask D
$ mcr sysgen show savedump
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
SAVEDUMP 0 0 0 1 Boolean
$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 03:05 AM
тАО08-29-2007 03:05 AM
Re: Crash Dump Reset
Then set bit 1 of DUMPSTYLE which will give verbose console output on crashdump.
e.g. if current value of DUMPSTYLE is 9 (2^0 + 2^3) change to 11 (2^0 + 2^1 + 2^3)
Good Luck,
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 03:29 AM
тАО08-29-2007 03:29 AM
Re: Crash Dump Reset
This might be due to having an S3 Trio board in the system. Our tech tells me this can cause a HANG, not a crash, and therefore you don't get a crash dump. Two days ago we had a crash dump that led to replacing one of our CPU cards. That didn't bother be because that crash dump occurred. My concern was never that we crashed... I sort of expected problems after a hardware upgrade. It was the lack of a crash dump.
Auto-Action is RESTART so that's why I rather expected a crash dump, but of course if this is a HANG and my ops guys just hit the INIT button, that would do it too. I need to communicate with them the urgency of knowing when the INIT button is hit.
Thanks for the concern, guys. We are going to replace the console video board and see if that clears up the last nagging problem. I won't close this right away, but I'll check in if our system stabilized.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2007 02:28 PM
тАО08-31-2007 02:28 PM
SolutionIf I recall, correctly, you can violate this configuration rule if you have 2 GB or less of memory. Since you have a recent memory upgrade, please check the location of HBAs and the video card.
Andy Bustamante
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-02-2007 08:23 PM
тАО09-02-2007 08:23 PM
Re: Crash Dump Reset
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-06-2007 04:20 AM
тАО09-06-2007 04:20 AM
Re: Crash Dump Reset
As to the DUMPFILE - we are currently running a compressed selective dump until I can go to the remote site to issue some console commands. I have a full-sized dump file ready to go but I have to use DOSD, hence the console operations.
As of Saturday, we have had no more problems. I think our issue is resolve. Thanks to all who replied.