- Integrated Systems
- About Us
- Integrated Systems
- About Us
07-05-2001 11:20 AM
disk 29 8/126.96.36.199.0.0.4 sdisk NO_HW DEVICE HP
The NO_HW is kind of starnge!
Solved! Go to Solution.
07-05-2001 03:25 PM
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
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
tape 1 1/12/0/0.8.0.255.1.9.1 stape NO_HW DEVICE QUANTUM DLT8000
tape 2 1/12/0/0.8.0.255.1.9.2 stape NO_HW DEVICE QUANTUM DLT8000
tape 3 1/12/0/0.8.0.255.1.9.3 stape NO_HW DEVICE QUANTUM DLT8000
tape 4 1/12/0/0.8.0.255.1.9.4 stape NO_HW DEVICE QUANTUM DLT8000
ctl 42 1/12/0/0.8.0.255.1.9.5 sctl NO_HW DEVICE HP A4688A
ctl 43 1/12/0/0.8.0.255.1.9.6 sctl NO_HW DEVICE HP A4688A
ctl 44 1/12/0/0.8.0.255.1.9.7 sctl NO_HW DEVICE HP A4688A
07-05-2001 11:03 PM
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.
07-06-2001 01:01 AM
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
then you've got a problem on the fibrechannel side of the FC-SCSI mux
(have a look at the hub for blinking lights)
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
autoraid controller is offline or cable problem
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.
07-06-2001 02:21 AM
>if you see this show up as NO_HW
>then you've got a problem on the fibrechannel >side of the FC-SCSI mux
this should have read
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.
07-06-2001 05:06 AM
disk 29 8/188.8.131.52.0.0.4 sdisk NO_HW DEVICE HP A5277A
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/184.108.40.206.0.0.0 sdisk CLAIMED DEVICE HP A5277A
disk 4 8/220.127.116.11.0.0.1 sdisk CLAIMED DEVICE HP A5277A
disk 5 8/18.104.22.168.0.0.2 sdisk CLAIMED DEVICE HP A5277A
disk 28 8/22.214.171.124.0.0.3 sdisk CLAIMED DEVICE HP A5277A
Also strange is that the virtual targets show up:
target 4 8/126.96.36.199.0.4 tgt CLAIMED DEVICE
target 5 8/188.8.131.52.0.5 tgt CLAIMED DEVICE
target 6 8/184.108.40.206.0.6 tgt CLAIMED DEVICE
target 7 8/220.127.116.11.0.7 tgt CLAIMED DEVICE
target 8 8/18.104.22.168.0.8 tgt CLAIMED DEVICE
target 9 8/22.214.171.124.0.9 tgt CLAIMED DEVICE
target 10 8/126.96.36.199.0.10 tgt CLAIMED DEVICE
target 11 8/188.8.131.52.0.11 tgt CLAIMED DEVICE
target 12 8/184.108.40.206.0.12 tgt CLAIMED DEVICE
target 13 8/220.127.116.11.0.13 tgt CLAIMED DEVICE
target 14 8/18.104.22.168.0.14 tgt CLAIMED DEVICE
target 15 8/22.214.171.124.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.
07-06-2001 05:16 AM
disk 29 8/126.96.36.199.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.
07-06-2001 05:23 AMSolution
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)
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.
07-06-2001 05:31 AM
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.
07-06-2001 05:46 AM
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!