make_recovery error, with disk or SCSI card?

[James Ellis_1]

While running make_recovery, I got this error:

The specified path does not correspond to physical volume attached to this group
vgdisplay: Warning: could not query all of the physical device
vgdisplay: Warning: couldn't query physical volume /dev/dsk/c7t15d0

I ran these commands

pvdisplay /dev/dsk/c7t15d0 and got these msg.
pvdisplay: warning: couldn't query physical volume /dev/dsk/c7t15d0
The specified path does not correspond to physical volume attached to this group.
pvdisplay:warning:couldn't query all of the physical volumes.
pvdisplay: couldn't retrieve the names of the physical volumes belonging to volume group /dev/vg02.
pvdisplay: cannot display volume "/dev/dsk/c7t15d0".

I also ran diskinfo /dev/rdsk/c7t15d0 and got these messages:
diskinfo: can't open /dev/dsk/c7t15do: I/O error.

From these messages, this looks like a bad disk but could it be a bad SCSI card? I want to place an order to get a new disk installed by our HW support, but wanted to verify this is not a SCSI issue. Any of you know how to verify this is a disk and not a SCSI problem?

Thanks.

[Pete Randall · Accepted solution]

James,

The quickest, easiest way to test for a bad disk is:

dd if=/dev/rdsk/c7t15d0 of=/dev/null bs=1024k


If you get any I/O errors, it's a bad disk.


Pete

[Jeff Schussele]

Hi James,

Are there any other disks or tape drives on the c7 HBA?
If it's a bad SCSI HBA, then these would be giving you trouble as well.


Rgds,
Jeff

[Steven E. Protter]

Its almost certainly a bad disk.

I'm attaching a script that tests all disks found in /etc/lvmtab and reports bad or nonresponsive disks.

SEP

[James Ellis_1]

Pete,

The message after the commands you suggested apparently shows this is a bad disk.

The error messages are shown below:

dd read error: Invalid argument
0+0 records in
0+0 records out

This would mean that the SCSI card is working ok then?

Thanks, Jim

[Helen French]

To determine if that's a SCSI card or Disk issue:

1) Run STM. Run information and verification tools on SCSI card and the suspected disk. It will tell you which one is bad

2) Run 'ioscan -fn'. If the SCSI card is connected to any other device (disk, tape etc) do a diskinfo or pvdisplay on it. If that also fails, it could be the SCSI card problem. If only one disk fails on the same SCSI card, it's a disk problem.

3) Check syslog.log for information about SCSI errors or disk errors

[Pete Randall]

James,

That indicates an error in the command syntax. Looking back I see a space between "bs=" and "1024k" which should not be there. The other possibility is that you might have misread the "if" parameter - it's letter "eye".

dd if=/dev/rdsk/c7t15d0 of=/dev/null bs=1024k


If you can, cut and paste the above and try it again.


Pete

[James Ellis_1]

Pete,

I did as you suggest, and got the same error. I did a man dd and see that the command uses if so I did this:

dd if=/dev/rdsk/c7t15d0 of=/dev/null bs=1024

What is it that I am doing wrong?

[Pete Randall]

Jim,

I'm not sure where we're going wrong here. I just cut and pasted the command and tried it on my workstation - of course I had to change the device file to a disk I have but, other than that, it works fine.

Can you post the output of "ll /dev/rdsk" for me?


Pete

[James Ellis_1]

Pete,

The output is attached. Thanks.

[Pete Randall]

Jim,

OK, I was worried that maybe there was no device file. I'm stumped for the time being. Hopefully someone else can spot something that I'm missing!


Pete

[Pete Randall]

Jim,

What version of HP-UX are you running? I tried the dd command but transposed if (eye eff) to lf (ell eff) and got "dd: bad arg lf=/dev/rdsk/c1t5d0" on an 11i box. Are you 10.20 by any chance? Maybe the error message syntax was different back then.


Pete

[James Ellis_1]

Pete,

We are running the 11.0 version. This has gotten me puzzled also. I see the c7t15d0 listed in the attached file, and am not sure what the problem is. It looks like it is a command issue?

Jim

[Pete Randall]

Jim,

OK, let's attack this from a different angle:
try "vgdisplay -v vg02" and post the output.


Pete

[James Ellis_1]

Here is vgdisplay...

--- Volume groups ---
VG Name /dev/vg02
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 4
Act PV 3
Max PE per PV 4342
VGDA 6
PE Size (Mbytes) 16
Total PE 1557
Alloc PE 1557
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg02/lvol12
LV Status available/syncd
LV Size (Mbytes) 42256
Current LE 2641
Allocated PE 2641
Used PV 3


--- Physical volumes ---
PV Name /dev/dsk/c8t0d1
PV Name /dev/dsk/c10t0d1 Alternate Link
PV Status available
Total PE 519
Free PE 0
Autoswitch On

PV Name /dev/dsk/c8t4d0
PV Name /dev/dsk/c10t4d0 Alternate Link
PV Status available
Total PE 519
Free PE 0
Autoswitch On

PV Name /dev/dsk/c8t4d1
PV Name /dev/dsk/c10t4d1 Alternate Link
PV Status available
Total PE 519
Free PE 0
Autoswitch On

[Pete Randall]

That's interesting.

From your original message "pvdisplay: couldn't retrieve the names of the physical volumes belonging to volume group /dev/vg02.
pvdisplay: cannot display volume "/dev/dsk/c7t15d0".", I expected that c7t15d0 would belong to vg02.

How about doing "vgdisplay -v"? You don't need to post the whole output, just the section before and after any errors.


Pete

[Steven E. Protter]

This part of the output

Cur PV 4
Act PV 3

Indicates that one of your physical volumes is not responding.

You are going to need to replace that disk in order to get working again.

If there are other disks on the scsi card or cable that are working, I doubt its the card.

It could be an issue with a bad drive cage, thourgh which data and power flow.

The output clear indicates a disk has gone south though. Take a look at it physically and see if there are any lights on it.

Consider running mstm or xstm(In X) These utilities contain exercize functions that lets you tests disks and controllers. Test the controller, if it passes, test the disk. If it comes up dead, you should be pretty sure.

SEP

[James Ellis_1]

Pete,

I ran the vgdisplay -v command, and saved the results to the file. Looking in the file shows no errors, but on the telnet section to the server it shows errors like the original errors I posted. The vgdisplay file is attached... Thanks.

[James Ellis_1]

Steven,

I'll do that, but right now my Exceed is not running. In another post, I got a new PC and requested to have Exceed installed. Then I am not able to configure it, got no books with it and something is not running right. Running stm related functions would be better with exceed. I am connecting via telnet now...and is not GUI friendly...

Thanks.

[Steven E. Protter]

mstm will work in telnet, I hate it, which is why I use xstm.

If you are in a hurry, mstm will do the job, it just lacks the point and click easy to scroll interface.

SEP

[James Ellis_1]

Steven,
I agree with you. Telnet has caused me problems when I need to "see the whole picture". I will be leaving soon as my daughter is a little sick.

I hope we can follow up on this Monday, and get to the root of where the problem is, disk or SCSI card. I am thinking its the disk, but since peripherals cost a bundle, I want to verify before I go ahead and put in a request for HW to come and swap out.

Thanks guys and we will talk about this on Monday.

[James Ellis_1]

Guys and Gals,

I am still having this problem. I realized I gave everyone points, and everyone ran away for the weekend and never came back to the forum. My bad...ok...I should have never given points until the problem is solved. My fault...okay, lets gather around the campfire and get to the bottom of this.

I went and talked to the folks responsible for the EMC disks and told him I thought the dev/dsk/c7t15d0 disk was a EMC disk. He checked it out and said it does not look like its a problem with an EMC disk.

To make matters worse, one developer says he is having problems ftp to a volume group, and that volume group uses the dev/dsk/c7t15d0 disk so this is another problem.

I checked that the ~ was not in /etc/fstab and don't know what else to do. I believe it is a configuration problem. When I run this

vgdisplay -v /dev/vg02 (the directory where the ftp is causing problems)

I see all of the error messages.

But when I run

vgdisplay -v /dev/vg02 > /home/mydir (to save the file and attach to this forum so you all can see the message)

I then do a cat /home/mydir and the result is a file without errors! What the heck?

Any more ideas what could be the problem with these errors? Is this some kind of disk configuration issue?

Thanks!