Problem with second F/C card

[Robert S. Wright_1]

In an N4000/440 4-way system, running HP-UX 11.11 with June 2003 patches, 2 ea. A5158A F/C cards and direct connected RAID, we get this error message when booting:

1/0/0/0 td
td: claimed Tachyon TL/TS Fibre Channel Mass Storage card at 1/0/0/0
1/0/0/0.8 fcp
1/0/0/0.8.0.1.0 fcparray
1/0/0/0.8.0.1.0.0 tgt
1/0/0/0.8.0.1.0.0.0 sdisk
1/0/0/0.8.0.1.0.0.7 sdisk
1/0/0/0.8.0.1.0.1 tgt
1/0/0/0.8.0.1.0.1.0 sdisk
1/0/0/0.8.0.1.0.2 tgt
1/0/0/0.8.0.1.0.2.0 sdisk
1/0/0/0.8.0.1.0.3 tgt
1/0/0/0.8.0.1.0.3.0 sdisk
1/0/0/0.8.0.255.0 fcpdev
1/0/0/0.8.0.255.0.1 tgt
1/0/0/0.8.0.255.0.1.0 sctl
1/2 lba
1/2/0/0 td
td: claimed Tachyon TL/TS Fibre Channel Mass Storage card at 1/2/0/0
1/2/0/0.8 fcp
1/2/0/0: WARNING: It appears that there are (or were) more than one device with
the same address (nport ID) setting of 0x0. One of them will be ignored.

Note that the first card works fine. Second card in this boot DID NOT HAVE ANYTHING CONNECTED TO IT. We have tried different cards, different slots, connected to the RAID and not connected to the RAID.

Also get these warnings on console during boot:

WARNING! /stand/krs/_stand_vmunix.krs and /stand/krs_lkg//stand_vmunix.krs are identical

and

WARNING! /stand/krs/system.krs and /stand/krs_lkg//system.krs are identical

Any ideas? Thanks for your help.

Robby W.

[Ted Ellis_2]

are the cards attached to the same disks.. or separate? Run fcmsutil on each card:

fcmsutil /dev/td0
fcmsutil /dev/td1

the tdx may be different on your system
are the N_Port_ID values different?

here is a bit of info that may indicate what is going on...

Event 52

Severity: Critical
Description: Address conflict encountered by device at nport id 0x!
Cause: HA is the "hard address" (port ID), configured via a switch or console, that the device is trying to acquire. Our adapter cards themselves don't have hard addresses.
Action: It appears that there are (or were) more than one device with the same address (loop ID) setting. One of them will be ignored. Look for two (or more) devices on the loop which have the reported address setting.Change the address settings so that all devices on the loop have a unique addresses, or remove the overlapping devices. Even after you change the address settings on the devices, it may be necessary to reset or power-cycle both the devices whose settings have been changed, and any remaining device with the address setting which encountered the conflict.

[Michael Steele_2]

Disable the problem HBA until you can remove it 'fcmsutil -f disable'. For example:

# fcmsutil -f /dev/td1 disable

-or-

# fcmsutil /dev/td1 disable

Note: -f is optional and retains messages. No -f destroys all messages.

I would also remove the problem device file. Use 'rmsf -kH path' for this.

# rmsf -kH 0/0/2.4.0.0.1 (* I don't believe a reboot is needed for this *)

[Ted Ellis_2]

your warning message for the /stand/krs files seems to point to changes possibly made to dynamic kernel parameters... any chance you made some changes and possibly did not use SAM or kmtune properly? Check this thread.. may help.

http://forums1.itrc.hp.com/service/forums/parseCurl.do?CURL=%2Fcm%2FQuestionAnswer%2F1%2C%2C0x8adba848deccd61190050090279cd0f9%2C00.html&admit=716493758+1065733767743+28353475

[Michael Steele_2]

Please attach:

# ioscan -fnkC fc

Thanks!

[Robert S. Wright_1]

Ted - The interfaces are not connected to the same switch or device or loop. In fact, right now, the interface at 1/2/0/0 is not connected at all, but is still giving the error messages. I did the fcmsutil command on both and they essentially look identical.

Michael - Right now, the problem interface is not connected to anything and does not appear to be causing any problems other than it won't work. Would you please explain how disabling the card would help? I am not sure I understand.

Here is the ioscan for the f/c interfaces:

fc 1 1/0/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
/dev/td1
fc 3 1/2/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
/dev/td3

[Ted Ellis_2]

go with Michael's initial recommendation and remove the device files for the 1/2/0/0... then recreate them with insf -e or insf -H 1/2/0/0

[Ted Ellis_2]

when I say go with recommendation, I agree with you that you do not seem to have faulty hardware, so don't disable the card or remove it. These cards can be difficult to seat, but seems that the system can see the card OK and it is struggling with a definition in the device.... so just take the latter part of his recommendation

[Michael Steele_2]

What happens if you remove device files without disabling them first? The kernel and ioconfig will still report them. Maybe causing a panic.

Don't fool around with the /dev sub directory without following proceedure.

You can also try to reset the HBA, but these are read only devices that require configuration information to be transmitted to them from a SAN switch or end device.

There should be no light in the fiber since "...the problem interface is not connected to anything...".

So all you're doing here is disabling a warning message and the device files will be recreated on reboot.

No worries.

It's just an irritation.

[Michael Steele_2]

Here's the man page for 'fcmsutil'.

[Robert S. Wright_1]

Thanks all for your help. Turns out that the RAID controller had a problem. It looked good from the RAID side, and looked good from the F/C side, but was not able to communicate correctly between the I/O section and the controller's computer. We replaced the controller and the problem was fixed.

[fuqiang]

Hello All,
I have the same error with my rp3440.
The server was connected to MSA1000 though a fabric hub, and the hub also connected a SC10.