12h AutoRAID controller

[Josef Nordtome]

Hello All,

I'm kind of new to the 12h so please forgive me. We had an error with one of the dual contollers where the battery pack failed so I removed the controller and replaced the batteries. When I re-installed the controller and issued the arraydsp -c command I received the following message: "Controller X is installed, but not responding to this system"

I tried switching the X and Y controllers but the error message continues to refer to Controller X. Any help you can provide would be greatly appreciated.

Josef

[Helen French]

Hi Josef,

Look at this document. This may help you better:

http://www.hp.com/cposupport/manual_set/lpg28366.pdf

http://www.hp.com/cposupport/manindex/hpsurestor19162_eng_man.html

SW

[fg_1]

Josef

Usually when this happens it means that the backplane needs to be replaced.

I would place a HW call with support and have them check it out.

By the way, are you receiving any Event Number (DEC/hex) codes on the front display of the unit?

[Josef Nordtome]

Thanks everyone for your prompt responses. Come to find out, it was a bad SCSI cable that was causing the problem. The 12H was working just fine but the arraydsp command wasn't able to directly query the controller from the host. The 12H knew about the controller that's why it said that it was installed.

Thanks again,
Josef

[Bill McNAMARA_1]

Try:
/sbin/init.d/hparray stop
(won't unmount disks, just stops mgmt cli)
/sbin/init.d/hparray start
(restart ARMServer)
then
top

wait for all the ioscans to finish (will be 2)

make sure ARMServer runs.
(probably up to 5 minutes later)

Then
arraydsp -R

then
top

wait for all the ioscans to finish (will be 2)


then
arraydsp -i

then
arraydsp -a

Later,
Bill

[Bill McNAMARA_1]

Do you see the controller on an ioscan

ioscan -fnk
look for the target just before the C5447A lun

You should see the SCSI ID followed by the lun

The message does not necessarily mean the controller has failed, but that the ARMServer can't talk to it..

Does it show up in the control panel? under view Settings > controller >

Check the scsi id for example.

--

Try changing your primary controller (the one who manages the control pannel) to the other controller?

Does it work?

Does it switch the behaviour problem to the currently working controller?

If so, you've got an incorrrect config option set.
arramgr -(ooh I forget)
I think it's o and you want it off.. it's a windows thing where when removing a controller (or failing) it will assign the id of the failed controller to the remaining one.. only one controller can work in NT at any one time. It can't cope with a SCSI ID change - ie no alternate path.
Make sure this setting is off for hp-ux.
The two leds should be green on the controllers.

If not this is most likely the problem (once the c x didn't fail initialisation tests)

--

After that suspect a pin problem...

Take out the controller, inspect the pins (they're really badly designed I must say..) make sure none are missing or bent or short..

If it looks okay, and won't migrate a pb to the other slot, you may risk (I'll say risk because it's not cool to migrate a HW problem to a working slot) swapping C X and C Y slots. You won't have to change SCSI ID, as it's the slot position that's important not the settings on the firmware.

Later,
Bill

[Bill McNAMARA_1]

Ah, just read that you figured it out!

Hey, you never said you touched the SCSI cables!

What's that got to do with Controller manipulation!!?!

Well done anyway,
Later,
Bill