- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: REBOOT AFTER PANIC
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-19-2003 01:02 PM
тАО08-19-2003 01:02 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2003 01:18 PM
тАО08-19-2003 01:18 PM
Solutionlooks 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2003 01:29 PM
тАО08-19-2003 01:29 PM
Re: REBOOT AFTER PANIC
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2003 01:30 PM
тАО08-19-2003 01:30 PM
Re: REBOOT AFTER PANIC
http://forums.itrc.hp.com/cm/QuestionAnswer/0,,0x3dccd7d96cbad711900a0090279cd0f9,00.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2003 04:23 PM
тАО08-19-2003 04:23 PM
Re: REBOOT AFTER PANIC
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