Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
cancel
Showing results for 
Search instead for 
Did you mean: 

I/O error

viks
Advisor

I/O error

hi all..i have got a 12H disk array with two K-360 servers in a cluster.suddenly one volume showed I/O error when bdf is typed.then momentarily the node2 in the cluster gave the error"x controller failed" and it told couldnt access a disk at a specified address.here i have attached the dmesg output.this is an SOS.kindly suggest the possible problem.the dmesg output is of node 2.node1 dmesg output i didnt get.awaiting reply.
thanks in advance.
viks
regard
2 REPLIES
Mark van Hassel
Respected Contributor

Re: I/O error

Hi,

It looks as if one of the controllers of the autoraid failed. Because you have Alternate paths to your luns configured the kernel switches to that alternate patchs when the primary patch fails (that's why you see the switch messages). You can check the autoraid with the following commands:
/opt/hparray/bin/arraydsp -i
this will give the serial number which is needed with the next commands:
arraydsp -a [serialnr] # for all info
arraydsp -c [serialnr] # for controller info

Check the status of the controllers. Also, if possible, check the display on the 12H itself.
If there are problems contact HP ...
The surest sign that life exists elsewhere in the universe is that none of it has tried to contact us
Insu Kim
Honored Contributor

Re: I/O error

Did you take a look at the front panel on HP AutoRAID ?
Did it show nothing ?

"Dmesg output" explained that there is a failure in the hardware path for /dev/dsk/c2t1d5 so the ownership of the LUN automatically switches to the alternate path for /dev/dsk/c3t0d5 because alternate links are configured.

For some reason, the problem has been disappeared naturally so the ownership of the LUN for /dev/dsk/c3t0d5 switches to the primary path again.

Dmesg shows this procedure over and over which means that there must be something wrong on AutoRAID.

Check out controller and host bus adaptor !
It's a good idea to issue ARM (Array Management) commands to get a clue as follows:

# arraydsp -i ( To get a serial number )
# arraydsp -a
# logprint -a

Hope this helps.
Never say "no" first.