Syslog and Dmesg error

[Uday_S_Ankolekar]

When I run dmesg and my syslog shows the following output

LVM: pv # has been returned to vg[1]
What is this mean and how do I solve this. There is no lbolt or scsi errors in my syslog. Pvdisply I/O time out is default.

[Rob Smith]

Hi, is there also a message saying that the disk is powerfailed? You may have a drive that is ready to die. Hope this helps.

Rob

[Pedro Sousa]

Hi Uday!
Do you use alternate links? Does your system have a storage array attached?
Several thing could be the cause of these messages.
1. vgreduce / vgextend
2. timeouts
3. others...

For start, a good idea is changing the timeout to +/- 100. default =30.

good luck.

[Uday_S_Ankolekar]

No there is no any errors related to Disk..
Any other clue??

[Magdi KAMAL]

Hi Uday,

You may also test the following :

# lvdisplay -v /dev/vg*/lv* ? more

and have a look. If any problem with disks, it will be reported here.

Good luck.
Magdi

[Uday_S_Ankolekar]

Does I/O parameter change require a reboot..??

[Bill McNAMARA_1]

No it doesn't need a reboot
pvchange -t 90 /dev/rdsk/cXtYdZ

You probably had some ioscan reinitiate a lip or scsi bus... I wouldn't worry about it unless you start seeing it more frequently.

Find out what PV1 is from looking at the order of entry in the strings /etc/lvmtab and then identify with ioscan -fnkCdisk where it is.

Then you can use MSTM to analyse the hardware.

Later,
Bill

[Uday_S_Ankolekar]

Bill,
The man page for pvchange says pcvhsge -t # sec /dev/dsk/# is it for dev/dsk or dev/rdsk..?

[Pedro Sousa]

hi again.

pvchange -t /dev/dsk/cxtxdx

[Pedro Sousa]

hi again.

pvchange -t 90 /dev/dsk/cxtxdx

[Jim Turner]

Hi Uday,

Do you have Fibre Channel between your server and its disks? If you have FC from server to disks or server to FC/SCSI MUX to disks, your most likely culprit(s) will be the FC adapter in the server or the FC adapter in the SCSI MUX or disk array.

Assuming you do have FC, here's a handy little proc to look for errors:
1. Run "ioscan -fnd fcT1_cntl"
2. Make note of the fcms devices (like /dev/fcms2, /dev/fcms3, etc)
3. Run "/opt/fcms/bin/fcmsutil /dev/fcms2 stat | grep -i bad" for each instance of fcms (fcms2 is just an example here)
4. Your bad FC adapter will have an astronomical number listed after "Bad Rx Char Count"
5. Good FC adapters will always have about 10 error listed (happens at start-up)
Note: Depending on your patch level, the output from step 4 may read "Bad Tx Char Count".

The laser diodes on the FC cards do degrade over time. I've faced this problem about three times now over a two-year period.

Cheers,
Jim

"Do not look into laser with remaining eye!"

[Uday_S_Ankolekar]

Thanks Jim,

/dev/fcmc2 is giving # 139652 for Bad Tx Char count. Rest all shows # 10. Is it a patch issue..? how did you solve this

-USA

[Manju Kampli]

Uday,

As per the HP's recommendation The Fibre disks timeout value should be set to 180 Seconds.. run "pvchange -t 180 /d/ev/dsk/cxtydz" command to set this. This does not require any outage OR reboot.
You might also look in to the fcms util described about .. and if you are getting lot of errors.. then it could be some thing wrong with the Fibre cards on your system OR at disk encloser end...

Hope this helps,
Manju

[Varghese Mathew]

Hi Uday,

I have faced similar problem in a K 570 with FC Cards and StorageTech Disk Arrays. The errors started occassionally like you are facing in your system and then it gradually increased - then finally ioscan gave NO_HW against the device names of Hard Disks.

We had to replace the FC cards, to get the problems resolved..

Cheers !!!
Mathew