Summary: 	1) Unknown LS_Commands are normal events in A5000
		   operation and are not a cause for concern.  
		2) ELS reties are usually ok.  ELS timeouts should be looked
		   into further.
		   
* What is an LS_Command ?

An LS_Command is a Link Service (LS) or Extended Link Service (ELS) command.
Link Service commands are defined in ANSI specification FC-PH X3.230.  Link
Services are part of the signalling protocol (FC-2) layer of the Fibre Channel
structure.  FC-2 provides the mechanisms needed to transfer blocks of data end
to end.  When a FCAL node is initialized onto a loop or a FCAL node exits a
loop, a Login or Logout process is required.  Login and Logout are defined as
Extended Link Services.

* What does the numeric identifier following "unknown LS_Command" or ELS mean ?
	
	0000000	or 0X0	loosely translates to a SCSI inquiry command
	3000000	or 0X3	LOGIN
	5000000	or 0X5	LOGOUT
	
	see /usr/include/sys/fc4/fc.h & fcal_linkapp.h for more detail
		
* Why are unknown LS_Commands generated ?  

If you have two adapters connections to each loop, whenever a loop is
re-initialized, it will be reflected twice, one for each host connection.
During boot up, the host adapters are initialized sequentially so there will
often be several OFFLINE/ONLINE sequences during the boot process.

Once a loop is "ONLINE", the drivers determine the devices types
and WWN's for nodes on the loop. Part of this "discovery" process
includes the host bus adapter issuing a "PLOGI" (login) command to each device 
on the loop.  Since the host bus adapter issues the PLOGI, the host adapter is 
acting in the role of intitiator; however, when the other host adpaters on the 
loop recieve the PLOGI command, they recieve the command as if it were a target.

Currently our host adapters do not support a "target" mode and hence, do not
have code paths to process PLOGI commands and the drive will reject the login.
A PLOGI is an Extended Link Service (ELS) command as defined in the Fibre
Channel Specification.  The command code is 3000000 (or 0x3).  This phenomenon
is not harmful and should happen as a result of a loop init on a loop with more
than one active host adapter or when the expert mode of the luxadm command
(luxadm -e rdls /dev/es/sesn) is issued on a loop with more than one host bus
adapter.

As mentioned, unknown LS_Commands are generated in multi-initiator environments
after an online/offline sequence occurs (which includes bootup).  Numerous (more
than 3 online/offline sequences per loop per day) online/offline sequences will
in turn generate numerous unkown LS_Commands in a multi-initiator configuration.
In this situation, of more concern is the numerous online/offline messages and
further investigation is warranted.  Note that unknown LS_commands follow an
online/offline sequence.  If I/O is occurring during the online/offline
sequence, the pending I/O is put "on hold" and outstanding I/O may require
retries.  It can take time for I/O to retry and for the backed up I/O to be
issued.  The impact of this behavior at the application / user level is that
things slow down or pause for a short period of time (approximately 30-120
seconds).  While things are paused, unkown LS_Commands may register in the
messages file.  Note that the system pause is not caused by the unknown
LS_commands.  The pause is a result of the online/offline sequence.

In summary, unkown LS_Commands are messages which normally should not raise 
concern.

* What is an ELS ?

ELS is an acronymn for extend link services.  ELS are related to Link Services; 
however ELS commands are more sophisticated than link services.

* What do these messages mean and what causes them ?

	ELS 0x0 to target 0x1d retrying
	
ELS time outs and retries can be expected from time to time.  There are specific 
cases during boot up (or when using luxadm in expert mode) in multi-initiator 
environments where "busy" signals can be encountered.  When a "busy" signal is 
encountered, the command is retried.  If something is not operating optimally, 
eventually the drivers will stop retrying and timeout:

	ELS 0x5 to target 0x7d timed out

Timeouts can be indicative of an issue which requires further investigation.

### MI boot sequence

The sequence below is an excerpt from the /var/adm/messages file of a host which 
is connected to a loop of A5000s.  Also connected to this loop of A5000s is 
another host.  Notice the unknown LS_Command and ELS retries.  These messages 
are expected in the multi-initator environment and should not raise concern.

Jun 16 10:15:21 voodoo unix: ID[SUNWssa.socal.driver.3010] socal0: host adapter 
fw date code: <not available>
Jun 16 10:15:21 voodoo unix: SUNW,socal0 at sbus0: SBus0 slot 0x1 offset 0x0 
and slot 0x1 offset 0x10000 and slot 0x1 offset 0x20000 SBus level 3 sparc9 ipl 
Jun 16 10:15:21 voodoo unix: 5
Jun 16 10:15:21 voodoo unix: SUNW,socal0 is /sbus@2,0/SUNW,socal@1,0
Jun 16 10:15:21 voodoo unix: ID[SUNWssa.socal.driver.3010] socal1: host adapter 
fw date code: <not available>
Jun 16 10:15:21 voodoo unix: SUNW,socal1 at sbus2: SBus2 slot 0x2 offset 0x0 
and slot 0x2 offset 0x10000 and slot 0x2 offset 0x20000 SBus level 3 sparc9 ipl 
Jun 16 10:15:21 voodoo unix: 5
Jun 16 10:15:21 voodoo unix: SUNW,socal1 is /sbus@a,0/SUNW,socal@2,0
Jun 16 10:15:21 voodoo unix: sf0 at SUNW,socal0: socal_port 0
Jun 16 10:15:21 voodoo unix: sf0 is /sbus@2,0/SUNW,socal@1,0/sf@0,0
Jun 16 10:15:22 voodoo unix: sf1 at SUNW,socal0: socal_port 1
Jun 16 10:15:22 voodoo unix: sf1 is /sbus@2,0/SUNW,socal@1,0/sf@1,0
Jun 16 10:15:22 voodoo unix: sf2 at SUNW,socal1: socal_port 0
Jun 16 10:15:22 voodoo unix: sf2 is /sbus@a,0/SUNW,socal@2,0/sf@0,0
Jun 16 10:15:22 voodoo unix: sf3 at SUNW,socal1: socal_port 1
Jun 16 10:15:22 voodoo unix: sf3 is /sbus@a,0/SUNW,socal@2,0/sf@1,0
Jun 16 10:15:22 voodoo unix: ID[SUNWssa.socal.link.6010] socal1: port 1: Fibre 
Channel Loop is ONLINE


Jun 16 10:15:22 voodoo unix: WARNING: ID[SUNWssa.socal.link.3010] socal1: 
unknown LS_Command, 3000000

^^^^^^^^^^^^^^^^^^

Jun 16 10:15:22 voodoo unix: ID[SUNWssa.socal.link.6010] socal0: port 1: Fibre 
Channel Loop is ONLINE
Jun 16 10:15:22 voodoo unix: WARNING: ID[SUNWssa.socal.link.3010] socal0: 
unknown LS_Command, 5000000
Jun 16 10:15:22 voodoo unix: WARNING: ID[SUNWssa.socal.link.3010] socal0: 
unknown LS_Command, 3000000
Jun 16 10:15:22 voodoo unix: WARNING: ID[SUNWssa.socal.link.3010] socal1: 
unknown LS_Command, 3000000
Jun 16 10:15:22 voodoo unix: WARNING: ID[SUNWssa.socal.link.3010] socal0: 
unknown LS_Command, 3000000

Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0xd retrying
					
					^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x2d retrying
Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x3d retrying
Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x7d retrying
Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x5d retrying
Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x4d retrying
Jun 16 10:15:23 voodoo unix: sf3:	ELS 0x0 to target 0x6d retrying
Jun 16 10:15:23 voodoo unix: sf1:	ELS 0x0 to target 0x4d retrying
Jun 16 10:15:23 voodoo unix: sf1:	ELS 0x0 to target 0x6d retrying
Jun 16 10:15:24 voodoo unix: sf1:	ELS 0x0 to target 0xd retrying
Jun 16 10:15:24 voodoo unix: sf1:	ELS 0x0 to target 0x1d retrying
Jun 16 10:15:24 voodoo unix: sf1:	ELS 0x0 to target 0x2d retrying
Jun 16 10:15:24 voodoo unix: sf1:	ELS 0x0 to target 0x3d retrying
Jun 16 10:15:25 voodoo unix: sf3:	ELS 0x0 to target 0x5d retrying
Jun 16 10:15:25 voodoo unix: sf3:	ELS 0x0 to target 0x6d retrying
Jun 16 10:15:25 voodoo unix: sf3:	ELS 0x0 to target 0x3d retrying
Jun 16 10:15:26 voodoo unix: sf1:	ELS 0x0 to target 0x3d retrying
Jun 16 10:15:26 voodoo unix: sf1:	ELS 0x0 to target 0x1d retrying      

This was taken from Bug 4149797