Reboot after panic: Data page fault

[Bharat Katkar]

We have HP N Class server running with HPUX 11.0. Server suddenly got panicked giving Data page fault error and rebooted. Please let me know the possible causes of the event. I was unable to view any kind of log regarding the same except the one mentioned above in /etc/shutdownlog.

[Pete Randall]

I would guess that a program overstepped its bounds and wrote over a bit of memory that didn't belong to it. Writing past the end of an array, for example.


Pete

[Uday_S_Ankolekar]

The ts99 file in /var/tombstones may provide you some more informations about cause of data page fault
There are various reasons for data page fault error.
Do a string on ts99 file and see if you can get any more clues



-USA..

[melvyn burnard]

The ts99 is only usually useable for hardware panics,
As a DPF is 98% software, the ts99 will be relatively useless here.
I suggest you either log a software call wiht HP to get the dump read properly, or if you do not wish to do that , then load the latest patch bundle.
Your system should have put a crash dump for analysis in /var/adm/crash.

[Bill Hassell · Accepted solution]

As mentioned, this is very likely to be a kernel patch problem. A data page fault occurs when the kernel encounters an instruction that points to an invalid address, for instance storing an integer at an odd address. However, knowing this does not point to the actual cause and of course, no easy way to locate the right patch. There are dozens of patches for 11.0 relating to possible data page fault panics.

So there are two choices: bring your patch level current by using your SupportPlus CDROM (dated fall 2002 or later), or if you don't have a software support contract, you can download the latest SupportPlus image from: http://www.software.hp.com/SUPPORT_PLUS/

You can also contact your closest HP Response Center and ask them to analyze a crash dump for you. You'll need to setup /var/adm/crash to hold the dump (apx. 25% the size of your RAM will be needed in the directory). The Response Center can then find the correct patch.

[Bharat Katkar]

Hi,
Thanks for your replies but could you please help me in isolating the nature of problem i.e. whether it is application related or OS related.? Is there any way i can analyze the crash dump or i have to send it to HP only. (We have installed updated patches till 2002 already.)
Waiting for your valuable suggestions.

Thanks
Girish

[melvyn burnard]

without analyzing the dump, it is impossible to say.
There are ways for you to look at the dump, but if you do not know what you are looking for/at, and it may also be that it may turn out to be a new bug/feature.
If you want to try it yourself, hen search the forum pages for documents in this subject

[Zeev Schultz]

I'd use HP Response Center as they have the specific tools for that kind of task and knowledge of OS/kernel structures.
it's a tough task anyway:)
However,what can you do (in addition) is to:
1)check /var/adm/syslog/syslog.log for unusual/error messages
2)perform chronological check of what was changed in system before in panicked (like new patches installs,kernel builds,driver installs) and so long.

Zeev

[Bill Hassell]

A kernel panic is never due to an application problem, rather, it might be triggered by some combination of tasks requested by an applicattion that are perfectly fine but due to a bug in the kernel, it crashes. While you can use q4 to analyze the crash dump, it will be virtually meaningless except to possibly point out which module is causing the problem. That still does not identify the proper patch but does narrow it down. There is likely to be other patches required to completely fix the problem, which os why you'll need HP's help in decoding the crash dump.