1752369 Members
5981 Online
108787 Solutions
New Discussion юеВ

deciphering POWERFAIL

 
Frank Quinteros
Advisor

deciphering POWERFAIL

looking at the syslog.log, got a POWERFAIL pointing to :
0x1f052200...
How is the cxtxdx info extracted?
8 REPLIES 8
A. Clay Stephenson
Acclaimed Contributor

Re: deciphering POWERFAIL

0x1f052200
The First two hex digits (1f - 31 decimal) denote the major device number. If you do an lsdev, you will note that 31 is the scsi disk block device.

After that it decodes as follows the following hex digits:
05 - c5
2 - t2
2 - d2
00 - the last two minor device digits are driver specific
But yours is: SCSI Block Disk Device, c2t2d2



If it ain't broke, I can fix that.
Sridhar Bhaskarla
Honored Contributor

Re: deciphering POWERFAIL

Frank,

I would simply do the following trick.

ll /dev/dsk |grep 052200

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
S.K. Chan
Honored Contributor

Re: deciphering POWERFAIL

Not sure what else is needed here as Clay pretty much answered your question already. I'll throw in a bit more ..

Typically POWERFAILED log in syslog.log has the format ..

VG[#]: pvnum=# (dev_t=##) POWERFAILED

The dev_t value would be like this for example ..
0x1f052200 (so it's c5t2d2)
05 = instance #
5 = SCSI addr #
0 = LUN #

If the error has something like ..

pv[#] returned to vg[#]

then the error is usually due to low timeout value on the disk driver (30 sec is default). You can increase the timeout up to the max of 180 secs. For ex:

# pvchange -t 180 /dev/dsk/

Also a few more thing to check ..
1) IO, by runing ..
# sar -d

2) If the error does not include
pv[#] returned to vg[#]
then the error is usually hardware related. IN this case you need to go into STM to determine the error.

3) If error has ..
SCSI: Request Timeout -- lbolt ...
then check SCSI controller connection/termination.
Helen French
Honored Contributor

Re: deciphering POWERFAIL

Hi Frank:

To add other excellent answers:

If you are using a fibre channel, then look at this document for better understanding the defenitions(TKB #KBRC00000407):

http://us-support.external.hp.com/cki/bin/doc.pl/sid=01f9a02114aae37e08/screen=ckiDisplayDocument?docId=200000057130733

and a solution for powerfail on fibre channel systems (TKB# KBRC00008956):

http://us-support.external.hp.com/cki/bin/doc.pl/sid=77fbf5f5091ad138de/screen=ckiDisplayDocument?docId=200000058957937

HTH,
Shiju
Life is a promise, fulfill it!
S.K. Chan
Honored Contributor

Re: deciphering POWERFAIL

Sorry.. typo .. it should be ..

05 = instance #
2 = SCSI addr #
2 = LUN #

T G Manikandan
Honored Contributor

Re: deciphering POWERFAIL

Hello,

FYI

We had POWERFAILED errors on the disk several times and the server stops responding after the errors.
We logged a call to HP.
THe HP service engineer told us the model of the hard disks were SEAGTATE and the firmware version for the hard disk was HP01.He told us an upgrade to disk firmware version to HP04 should solve the problem.Just last week we upgraded the disk firmware.
The disk is to be examined again.

Thanks
Nick Weaver_3
Advisor

Re: deciphering POWERFAIL

This is a message for T G Manikandan.

Did you have any problems updating the firmware on these Seagate disks?

Iam having problems updateing the firmware on 'some' L Class systems, but I have an L Class that the update works on OK.

The problem is that when the update utility tries to talk to the disk to do the update, it says the disk is in an unknown state.

Thanks.
T G Manikandan
Honored Contributor

Re: deciphering POWERFAIL

Nick,
We did not face any problems during the firmware upgradation.
We downloaded the disk firmware file from itrc.We copied it into a tape and made it bootable.(There were some procedures at itrc about this)
During startup we boot from the tape which automatically identified the lower firmware disks and updated it.

Thanks