topic Re: ioscan in Disk Enclosures

ioscan

Mike_21 — Thu, 05 Jul 2001 18:20:22 GMT

The results of an ioscan -fnC disk is as follows:

/dev/dsk/c8t0d3 /dev/rdsk/c8t0d3
disk 29 8/8.8.0.3.0.0.4 sdisk NO_HW DEVICE HP

bla..bla..bla...

The NO_HW is kind of starnge!

Re: ioscan

Paul R. Dittrich — Thu, 05 Jul 2001 19:13:42 GMT

Is it possible that drive has failed?

Re: ioscan

Michael Tully — Thu, 05 Jul 2001 22:25:46 GMT

Hi Mike,

I had this problem recently with this exact message
appearing in the ioscan output. I'm not sure if
your set up is the same, but we have ours set up this
way.

N4000 --> EMC brocade switch --> A4688 F/C bridge
--> 20/700 HP tape library. We were getting the
NO_HW message as well.

From this very same switch we also had it with disk
drives into a EMC Clariion FC4500 disk array.
Our solution was to replace the F/C bridge and
change the switch port on the EMC switch.

Hope this helps with your problem.

Whilst I am writing this reply, we have just had
the problem again with this switch. I've attached
a partial output of our ioscan for your humour....

ext_bus 11 1/12/0/0.8.0.255.1 fcpdev NO_HW INTERFACE FCP Device Interface
target 112 1/12/0/0.8.0.255.1.9 tgt NO_HW DEVICE
autoch 0 1/12/0/0.8.0.255.1.9.0 schgr NO_HW DEVICE HP A5597A
/dev/rac/c11t9d0
tape 1 1/12/0/0.8.0.255.1.9.1 stape NO_HW DEVICE QUANTUM DLT8000
/dev/rmt/1m
/dev/rmt/1mb
/dev/rmt/1mn
/dev/rmt/1mnb
/dev/rmt/c11t9d1BEST
/dev/rmt/c11t9d1BESTb
/dev/rmt/c11t9d1BESTn
/dev/rmt/c11t9d1BESTnb
tape 2 1/12/0/0.8.0.255.1.9.2 stape NO_HW DEVICE QUANTUM DLT8000
/dev/rmt/2m
/dev/rmt/2mb
/dev/rmt/2mn
/dev/rmt/2mnb
/dev/rmt/c11t9d2BEST
/dev/rmt/c11t9d2BESTb
/dev/rmt/c11t9d2BESTn
/dev/rmt/c11t9d2BESTnb
tape 3 1/12/0/0.8.0.255.1.9.3 stape NO_HW DEVICE QUANTUM DLT8000
/dev/rmt/3m
/dev/rmt/3mb
/dev/rmt/3mn
/dev/rmt/3mnb
/dev/rmt/c11t9d3BEST
/dev/rmt/c11t9d3BESTb
/dev/rmt/c11t9d3BESTn
/dev/rmt/c11t9d3BESTnb
tape 4 1/12/0/0.8.0.255.1.9.4 stape NO_HW DEVICE QUANTUM DLT8000
/dev/rmt/4m
/dev/rmt/4mb
/dev/rmt/4mn
/dev/rmt/4mnb
/dev/rmt/c11t9d4BEST
/dev/rmt/c11t9d4BESTb
/dev/rmt/c11t9d4BESTn
/dev/rmt/c11t9d4BESTnb
ctl 42 1/12/0/0.8.0.255.1.9.5 sctl NO_HW DEVICE HP A4688A
/dev/rscsi/c11t9d5
ctl 43 1/12/0/0.8.0.255.1.9.6 sctl NO_HW DEVICE HP A4688A
/dev/rscsi/c11t9d6
ctl 44 1/12/0/0.8.0.255.1.9.7 sctl NO_HW DEVICE HP A4688A
/dev/rscsi/c11t9d7

Regards
Michael

Re: ioscan

JAYAMOHAN.V.D — Fri, 06 Jul 2001 06:03:23 GMT

hi,
this message shows that the disk what is mentioned by the path, was available, but currently not able to detect. so it gives NO_HW.
it could be a disk sensing problem, or the communication problem between the disk array and the machine. in this case u have to check the cable / FC hub ( if u r using). Mostly it will be a hardware problem with ur hard disk / cables / FC hub. U may require the help of HP support.
i faced the same problem with the FC 30 disk array with FC AL Hub. we used to get the NO_HW in ioscan inyermittently and at that time the system response used to be very slow. after some days, we got the fault LED on one of the FC 30 disk and we had to replace the same.
regards
jayamohan

Re: ioscan

Bill McNAMARA_1 — Fri, 06 Jul 2001 08:01:17 GMT

8/8.8.0.3.0.0.4 sdisk

You've got a LUN4 problem on possibly an AutoRaid seen through controller with SCSI ID 0 connected to scsi card in slot 0 of an FC-SCSI mux through fc connector with loop id 3 on the fc loop 8/8.

if you see this show up as NO_HW
8/8.8.0.255.3.0.0
then you've got a problem on the fibrechannel side of the FC-SCSI mux
(have a look at the hub for blinking lights)

8/8.8 NO_HW
the fc card or the fc driver is in trouble
(try fcmsutil /dev/fcmsX reset)
(fcmsutil /dev/fcmsX (for status X=see ioscan)

if you see
8/8.8.0.3.0.0 NO_HW
autoraid controller is offline or cable problem

8/8.8.0.3.0.0.2 CLAIMED
then the problem is only with lun4 on the autoraid. Try arraydsp -a
(lun4 has probably been deleted since boot.

Post up the full ioscan -fnk

If you powered on the autoraid after the host you should run an ioscan -fn to update the kernel if it doesn't appear claimed at this point check cableing.

Later,
Bill

Re: ioscan

Bill McNAMARA_1 — Fri, 06 Jul 2001 09:21:29 GMT

ahh fc addressing
>if you see this show up as NO_HW
>8/8.8.0.255.3.0.0
>then you've got a problem on the fibrechannel >side of the FC-SCSI mux
this should have read
8/8.8.0.255.0.3.0

If you see all the ioscan -fnk|grep 255
show up as claimed you've no FC problem, otherwise it's a scsi problem on the FC->SCSI mux side or on the autoraid itself.

You need to find the first instance of no-hw in the ioscan to determine exactly which component is missing.

Later,
Bill

Re: ioscan

Mike_21 — Fri, 06 Jul 2001 11:22:48 GMT

Results of the ioscan -fnk in attached doc.

Re: ioscan

Bill McNAMARA_1 — Fri, 06 Jul 2001 12:06:36 GMT

No problem with anything other that
disk 29 8/8.8.0.3.0.0.4 sdisk NO_HW DEVICE HP A5277A
/dev/dsk/c8t0d4 /dev/rdsk/c8t0d4

The device A5277A is an FC60 Lun

The lun number is lun 4

now run amdsp -a
get the ID from amdsp -i

From this command we'll find out why lun 4 is in difficulty.

What is worrying is that you don't see it on the alternate link on 8/12 at all..

disk 3 8/12.8.0.4.0.0.0 sdisk CLAIMED DEVICE HP A5277A
/dev/dsk/c3t0d0 /dev/rdsk/c3t0d0
disk 4 8/12.8.0.4.0.0.1 sdisk CLAIMED DEVICE HP A5277A
/dev/dsk/c3t0d1 /dev/rdsk/c3t0d1
disk 5 8/12.8.0.4.0.0.2 sdisk CLAIMED DEVICE HP A5277A
/dev/dsk/c3t0d2 /dev/rdsk/c3t0d2
disk 28 8/12.8.0.4.0.0.3 sdisk CLAIMED DEVICE HP A5277A

Also strange is that the virtual targets show up:

target 4 8/8.8.0.3.0.4 tgt CLAIMED DEVICE
target 5 8/8.8.0.3.0.5 tgt CLAIMED DEVICE
target 6 8/8.8.0.3.0.6 tgt CLAIMED DEVICE
target 7 8/8.8.0.3.0.7 tgt CLAIMED DEVICE
target 8 8/8.8.0.3.0.8 tgt CLAIMED DEVICE
target 9 8/8.8.0.3.0.9 tgt CLAIMED DEVICE
target 10 8/8.8.0.3.0.10 tgt CLAIMED DEVICE
target 11 8/8.8.0.3.0.11 tgt CLAIMED DEVICE
target 12 8/8.8.0.3.0.12 tgt CLAIMED DEVICE
target 13 8/8.8.0.3.0.13 tgt CLAIMED DEVICE
target 14 8/8.8.0.3.0.14 tgt CLAIMED DEVICE
target 15 8/8.8.0.3.0.15 tgt CLAIMED DEVICE

which will never be occupied because the FC60 is limited to only 30 luns max. It may be normal and certainly won't cause a problem, but you should in investigate getting up to the latest SCSI/LVM and FC driver cumulative patch.... we'll worry about this later..
for the moment let's see what amdsp -a says.

Later,
Bill

Re: ioscan

Mike_21 — Fri, 06 Jul 2001 12:16:21 GMT

Thanks for the tips Bill, I have done this I think 20 times give or take a few to understand why. Regarding LUN 4, at first when I installed the disks, I used SAM to bind and create the LUN. After that was completed, and I noticed there was a few problems, I tried to unbind and remove LUN 4 and start over. I even went to the extreme of pulling the disks out, however, when I removed the disks and did an ioscan again the reference to LUN 4 still appears.

/dev/dsk/c8t0d3 /dev/rdsk/c8t0d3
disk 29 8/8.8.0.3.0.0.4 sdisk NO_HW DEVICE

Not sure why??????

I have logged a call with HP and they suggest first getting the box up to the current patch release (HP-UX 10.20), a few patches for the FC60, Fibre Channel, SAM, etc....

But still, LUNS have been created in the past, maybe the patch issue will solve the problem........

Maybe there is a problem using SAM to create the LUNS, still, how can I get the reference to LUN 4 gone, since it has been removed.

Thanks

Re: ioscan

Bill McNAMARA_1 — Fri, 06 Jul 2001 12:23:25 GMT

aahhh,
The 10 pointer ;)

on a system boot, the kernel ioinits all the hardware.
ie the kernel on kernel load discovers hw. If the hw is removed or failed or deleted.. the kernel still remembers it used to be there.
It won't dissapear until you reboot and the kernel reloads and never learns about the existance of lun4.
The state of NO_HW is lost on the reboot.

If you add h/w or a lun, its the same. the kernel disdn't know about it on boot so you must run a full ioscan (ie not kernel based)
ioscan -fn
and then insf the device files.

A reboot will do the same but means downtime.

There is no problem, just casually wait until your next reboot.

the kernel simly knows it used to exist now it doesn't.

Later,
Bill

Re: ioscan

Mike_21 — Fri, 06 Jul 2001 12:31:24 GMT

I kind of figured that, just didn't want to admit the Microsoft ways of the old "reboot"... he..he..

We do have a scheduled reboot tomorrow, but will this fix the NO_HW state????? Will the LUN configuration work ok after the reboot. I was under the impression that the FC60 could be configured on the fly and adding disks, creating LUN's could be done without rebooting the system.

Re: ioscan

Bill McNAMARA_1 — Fri, 06 Jul 2001 12:46:47 GMT

>We do have a scheduled reboot tomorrow, but >will this fix the NO_HW state?????
Yes, the lun 4 will vanish from the ioscan.

>Will the LUN configuration work ok after the >reboot.
Luns 0 to 3 will show up just fine.

>I was under the impression that the FC60 >could be configured on the fly and adding >disks, creating LUN's could be done without >rebooting the system.
Yes, you can add disks and luns on the fly.. but not exactly/cleanly delete h/w/luns.
There is a perculiar power sequence that must be followed when removing h/w from the fc60, but in most cases everything with a handle can be hotplugged. (just don't fail two disks in the lun at the same time)

A ha array needs a ha os. If your OS didn't support adding replacing and maintaining an ha array, you may as well have used windos as you say!

Later,
Bill