topic REBOOT AFTER PANIC in Operating System - HP-UX

REBOOT AFTER PANIC

Andrew Luis Arruza — Tue, 19 Aug 2003 20:02:13 GMT

Can anyone give me some direction on this message that is in the /etc/shutdownlog after the panic reboot:

11:45 Tue Aug 19 2003. Reboot after panic: , isr.ior = 0'240012.0'20c82218

Any/all help greatly appreciated and points will be assigned.
Andy

Re: REBOOT AFTER PANIC

John Bolene — Tue, 19 Aug 2003 20:18:42 GMT

isr is interrupt service routine

looks like trouble with an I/O device to me

anything else disk related in the log like a scsi reset?

It would help to know which OS, what disk devices are attached, and if you are current on patch levels.

Re: REBOOT AFTER PANIC

A. Clay Stephenson — Tue, 19 Aug 2003 20:29:40 GMT

You really don't give us much to work with. At a minimum: Model & OS Version.

The first place to start is in /var/tombstones. Look for a file tsNN with a timestamp near your time of crash. This is probably a hardware problem so search the tombstone file for "HPMC" (High-Priority Machine Check) and that will give you a clue.

You really need to use the q4 utility (or have HP do it) to examine the crash dump.

One other thought: Is this box part of an MC/SG cluster? If so, you might be the victim of a ServiceGuard induced TOC (Transfer of Control).

Re: REBOOT AFTER PANIC

GK_5 — Tue, 19 Aug 2003 20:30:39 GMT

Here is similar forum article. This may help.

http://forums.itrc.hp.com/cm/QuestionAnswer/0,,0x3dccd7d96cbad711900a0090279cd0f9,00.html

Re: REBOOT AFTER PANIC

Kent Ostby — Tue, 19 Aug 2003 23:23:03 GMT

Andy --

An isr.ior "panic" is caused by one of three things.

#1) HPMC -- As mentioned above, check the file /var/tombstones/ts99 to see if the date INSIDE the file is valid for around the time of the failure.

#2) If you run MC/Serviceguard, it could be caused by MC/Servicguard losing connection between the nodes. Look at the OLDsyslog.log on the node that crashed or the syslog.log on the node that didn't crash for that time frame and see if you see messages related to losing contact with each other.

#3) If someone forced a TOC either via the TOC button or the cntl-b> TC entry at the console, you would get a line like this as well.

Check #1 first. If the date INSIDE the file is from the timeframe then you have a HW problem and probably need to low a HW call with HP or whoever your vendor is.

If #1 doesnt show a valid timestamp (shows an older date or no valid timestamp) then if you have MC/SG and think that noone did #3 then you are probably looking at a Serviceguard TOC.

There are many causes of a SG TOC.

Generally it is either that there was a problem that disrupted the LAN and prevented SG from talking between the two nodes or that the system was in some sort of hang or "mini-hang" that prevented the two nodes from talking.

Post us what you find and we may be able to help further here although some SG TOC issues generally require more detailed analysis.

Best regards,

Kent M. Ostby