Solaris Reports: Fp(n): ADISC To xxyyzz Failed, Cmd_flags=1 State=Packet Transport Error

Asset ID:	1-71-1984000.1
Update Date:	2018-03-07
Keywords:

Solution Type Technical Instruction Sure

Solution 1984000.1 : Solaris Reports: Fp(n): ADISC To xxyyzz Failed, Cmd_flags=1 State=Packet Transport Error

Applies to:

Sun Fire 15K Server - Version All Versions and later
Solaris SPARC Operating System - Version 8.0 and later
Qlogic FC HBA - Version Not Applicable to Not Applicable [Release N/A]
Emulex FC HBA - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.

Goal

This is a Solaris 10 sparc server and with no apparent reason we see this isolated errors on the messages files

Feb 15 20:02:02 server01 fp: [ID 517869 kern.info] NOTICE: fp(3): ADISC to 1e416d failed, cmd_flags=1 state=Packet Transport error, reason=No Connection
Feb 15 22:58:31 server01 fp: [ID 517869 kern.info] NOTICE: fp(3): ADISC to 28d1b6 failed, cmd_flags=1 state=Packet Transport error, reason=No Connection
Feb 16 16:12:48 server01 fp: [ID 517869 kern.info] NOTICE: fp(3): ADISC to 1e8154 failed, cmd_flags=1 state=Packet Transport error, reason=No Connection
Feb 17 16:01:34 server01 fp: [ID 517869 kern.info] NOTICE: fp(3): ADISC to 1e416d failed, cmd_flags=1 state=Packet Transport error, reason=No Connection

We want to know that these error mean and if there is any action to take.

Solution

The definition of Discover Address (ADISC) is :
"Discover Address (ADISC) is sent by an initiator to a drive after loop initialization to verify addresses have not
changed or to verify the drive was able to obtain the hard address select through the interface connector (SEL Lines) during loop initialization."

First we need to see what devices are connected to that FC HBA port.

On this case, fp3 instance correspond to a FC HBA port with path /pci@23c,600000/SUNW,qlc@1,1/fp@0,0

# grep fp /etc/path_to_inst
...
"/pci@23c,600000/SUNW,qlc@1,1/fp@0,0" 3 "fp" <<-- fp3
...

That FC HBA port that has six tape devices configured :

# luxadm -e dump_map /devices/pci@23c,600000/SUNW,qlc@1,1/fp@0,0:devctl
Pos Port_ID Hard_Addr Port WWN         Node WWN         Type
0    1e416d 1e416d    5005076300xxxx33 5005076300xxxx33 0x1 (Tape device)
1    1e42a9 1e42a9    5005076300xxxx17 5005076300xxxx17 0x1 (Tape device)
2    1e8154 1e8154    5005076300xxxx41 5005076300xxxx41 0x1 (Tape device)
3    2801cb 2801cb    5005076300xxxx12 5005076300xxxx12 0x1 (Tape device)
4    28d1b6 28d1b6    5005076300xxxx0c 5005076300xxxx0c 0x1 (Tape device)
5    28d346 28d346    5005076300xxxx4c 5005076300xxxx4c 0x1 (Tape device)
6    28bc80 0         210100e0xxxxxx32 200100e0xxxxxx32 0x1f (Unknown Type,Host Bus Adapter)

More in detail, from fptrace output we can see the following:

[Sun Feb 15 2015 20:02:02:469:034:280] 24466=>fp(3)::fp_unsol_cb: s_id=fffffd, d_id=28bc80, type=1, r_ctl=22, f_ctl=290000 seq_id=0, df_ctl=0, seq_cnt=0, ox_id=ffff, rx_id=ffff ro=0, buffer[0]:61
[Sun Feb 15 2015 20:02:02:469:126:840] 24467=>fp(3)::fp_handle_unsol_rscn: s_id=fffffd, d_id=28bc80,type=1, f_ctl=290000 seq_id=0, ox_id=ffff, rx_id=ffff ro=0
[Sun Feb 15 2015 20:02:02:469:149:400] 24468=>fp(3)::RSCN with D_ID page; port=600587b5000, d_id=1e416d, pd=30108b7fc00
[Sun Feb 15 2015 20:02:02:473:284:680] 24469=>fp(3)::fp_unsol_cb: s_id=fffffd, d_id=28bc80, type=1, r_ctl=22, f_ctl=290000 seq_id=0, df_ctl=0, seq_cnt=0, ox_id=ffff, rx_id=ffff ro=0, buffer[0]:61
[Sun Feb 15 2015 20:02:02:473:309:960] 24470=>fp(3)::NS Query response, cmd_code=112, xfer_len=8
[Sun Feb 15 2015 20:02:02:473:313:800] 24471=>fp(3)::GPN_ID results; 50 5 7 63 0
[Sun Feb 15 2015 20:02:02:473:344:520] 24472=>fp(3)::NS Query Response for D_ID page; rev=1, in_id=0, cmdrsp=8002, reason=0, expln=0, rval=0
[Sun Feb 15 2015 20:02:02:473:590:760] 24473=>fp(3)::fp_adisc_intr: Perform LOGO.cmd_flags=0, fp_retry_count=5, ulp_pkt=0
[Sun Feb 15 2015 20:02:02:478:580:360] 24474=>fp(3)::fp_adisc_intr: Dev change notification to ULP port=600587b5000, pd=30108b7fc00, map_type=1 map_state=1 map_flags=0 initiator=1
[Sun Feb 15 2015 20:02:02:478:624:200] 24475=>fp(3)::fp_ulp_devc fired; port=600587b5000, len=1
[Sun Feb 15 2015 20:02:02:478:656:440] 24476=>fp(3)::PLOGI succeeded: no skip(2) for D_ID 1e416d

The fp driver gets a unsolicited request (an RSCN) probably from FC switch (source portID fffffd) for the destination device on portID 28bc80 (our FC HBA port)
The RSCN is asking for the device on portID 1e416d , that is one of the tape devices.
The device respond and it does a PLOGI into the FC switch.

Conclusion:
The most probable scenario on this particular case is that the FC tape has been reset or rebooted and
now it logs again into the fabric (PLOGI)

Check on the Tape Library where this tape device belongs if there was any problem,
or check if the Backup software made some operation on that tape device.

Attachments

This solution has no attachment