Chapter 3
LP7000 FC Host Adapter

The "SF" family of vendor-supplied FC Host Adapter firmware supports the LP7000E model of the FC Host Adapter (also known as the V4 board type) from Emulex®.

This document supports the newest release and the previous release of SF firmware qualified for use with the DYNIX/ptx V4.4.x operating systems.

Current Release: Section 3.1

Previous Release: Section 3.2

See Table 1-1 for the latest recipe for the best set of SAN FC firmware to run on a given operating system.


3.1 Current Release SF3.22a0 for DYNIX/ptx V4.4.10, V4.4.9, V4.4.8, and V4.4.7

This section contains the following subsections:


3.1.1 SF3.22a0 Compatibility Information

Version SF3.22a0 of the FC Host Adapter firmware is compatible with:


3.1.2 SF3.22a0 Changes Since the Previous Releases

Generally, the SF3.x code family is streamlined and optimised for the LP7000E model by removing unnecessary code inherited from the older LP6000 family.

Compared to the SF2.23 and SF2.22 releases previously qualified for DYNIX/ptx V4.4.8 and V4.4.7, the SF3.22a0 contains the same major features plus the following improvements:


3.1.3 SF3.22a0 Firmware Open Problem Reports

The following Serious problem has been reported against the SF3.22a0 firmware. (See "FC I/O Subsystem-Level Problem Reports," Chapter 2 for possible I/O subsystem-level problems involving FC Host Adapters.)

Host Adapter Fails to Report EMC Port Logouts to the OS Driver (255217)

When an EMC Symmetrix storage subsystem sends a port logout (LOGO) to all FC Host Adapters previously logged in to that particular port, those Host Adapters fail to notify the OS FC driver so that it can unregister that port. Subsequently, sequence timeout errors pile up in the ktlog until hard errors occur and all paths to that EMC storage port get marked down.

Workaround: Recover the paths by deconfiguring (devctl -d sdx) all of the sd devices behind that EMC port and then reconfigure them from the fabric parent (devctl -c fabricx). This will cause the Host Adapters to relogin to the EMC port without relogging into the fabric.


3.2 Previous Release SF2.23 for DYNIX/ptx V4.4.8

This section contains the following information:


3.2.1 SF2.23 Compatibility Information

Version SF2.23 of the FC Host Adapter firmware is compatible with:


3.2.2 SF2.23 Changes Since the Previous Release

Version SF2.23 is a maintenance release. It has the same feature set as the previous release SF2.22.


3.2.3 SF2.23 Firmware Open Problem Report

The following problem has been identified in SF 2.23 on DYNIX/ptx 4.4.x hosts. See "FC I/O Subsystem-Level Problem Reports," Chapter 2 for possible I/O subsystem-level problems involving FC Host Adapters.

FF (FC Host Adapter) Warning Message During DYNIX/ptx V4.4.x System Boot Up

ff (FC Host Adapter) Warning messages displayed on the system console during DYNIX/ptx V4.4.x system boot sometimes appear more serious than they are, thereby causing unnecessary system administrator actions.

(In the following example message, the quad, bus, and slot numbers represent typical FC Host Adapter locations in a system:)

WARNING: ff:quad 1, bus 1, slot 6:mailbox cmd failed - cmd
code 0x16 status 0x1601

Workaround: Ignore this message. The ff driver has received an interrupt to service a Link Attention while it is already servicing an earlier Link Attention Interrupt. All interrupts are serviced in the order in which they are received. When the system boot has completed, use the dumpconf | grep ff command to verify that all FC Host Adapters are logically connected to the expected fabrics. If one or more FC Host Adapters are still missing, probe them directly with the following commands:

devctl -d ffx
(Repeat for each missing FC Host Adapter)
devctl -c quadx
(Repeat for each quad containing a missing FC Host Adapter)


3.3 FC Host Adapter Software Installation

Possible CD-ROM media sources for FC-device software are:

  1. Insert the appropriate distribution CD for the host operating system into the CD-ROM drive in the boot Pbay that is connected to CQuad0 or SQuad 0 or Quad 0 of the system.

  2. Log in as root.

  3. Referring to a version of the DYNIX/ptx V4.4.x and Layered Products Software Installation Release Notes appropriate for the host system, use the ptx/ADMIN® menu system and the ptx/INSTALL utility to load the FC Host Adapter software package named "emulex4" in the INSTALL menu listing.

  4. Remove the distribution CD-ROM.

  5. Upgrade all LP7000E FC Host Adapters only with the downloading procedure described in the next section .


3.4 FC Host Adapter Firmware Download


ATTENTION

The following procedure requires that the system must be at the single-user level while its FC Host Adapters are being upgraded.


Use this procedure to perform either of the following tasks for an LP7000E FC Host Adapter:

Use the utility named ffutil located in /usr/service/bin to download the new software and flash the firmware PROM on a Host Adapter board. This utility is intended for use by Customer Support personnel only. See the manpage ffutil (1) for an explanation of the options to the ffutil command.

Upgrade the firmware with this procedure:

  1. From the PTX Console window on the console PC, take the system to the single-user level.

  2. Issue the /etc/showcfg command to locate all of the "FF" device names in the system. Use these device names in the downloading procedure in this section.


    ATTENTION

    The listing will show "FF" devices with different hardware versions. Take care to capture the names of the hw ver4 types only.

    Other DYNIX/ptx utilities will list the firmware version label in different ways. The /etc/versionlog file will list the firmware with a leading "v." The showcfg command will list it with "FF" as the leading characters even when the hardware type is ver 4. The numbers of the firmware version will be consistent in all places.


  3. Issue the devdestroy -a command to destroy all virtual devices on the system.

  4. Make sure that you are in the correct directory containing the LP7000E FC-Host Adapter software:

    # cd /usr/ssw/fw/ha_fc/emulex4

  5. For the case of a CLARiiON DASS RAID storage subsystem, you must explicitly deconfigure each disk drive (rdn) before running ffutil. The ffutil command will not deconfigure these devices. Refer to Appendix B for some example scripts for deconfiguring the large number of rd devices typically found in this type of storage subsystem.

    Note that the rd devices are restored automatically to their old names when they are discovered during the reconfiguration of their parent fabric.


    ATTENTION

    PR 250754 documents a problem when upgrading to a new SF3.x firmware level from an SF2.x level. The new SF3.x firmware changes the way that the LP7000 (SuperFly-4) FC Host Adapter reports its name, thus causing the naming database (ndb) of the OS to assign a new name to the upgraded device when it is probed the first time following the upgrade from an SF2.x level.

    Rather than require customers to re-annotate their physical system maps with new configuration names for the FC Host Adapters, the newly upgraded SuperFly-4 adapters must be renamed to their old configuration graph names immediately after they have been reconfigured.


  6. To upgrade all hw ver4 boards with a single command, start at Step 12.

    To upgrade a specific hw ver4 board, start with the next step.

  7. To update a particular LP7000E FC Host-Adapter board, as in the case of a field replacement, issue the following full-path command with options, arguments, and filename:

    # /usr/service/bin/ffutil -l -D -d /dev/ff/ffn -f fc_sf_ha.bin

    where:

    The -l option specifies a download operation.

    The -D option deconfigures all devices in the fabric below the designated FC Host Adapter.

    The -d option specifies a particular FC Host Adapter (ff device) and ffn is the device identity of the particular Host Adapter board to be upgraded.

    The -f option specifies a file as the source and fc_sf_ha.bin is the name of the new software file.


    ATTENTION

    Before the ffutil utility downloads a specified firmware file into a specified device, it checks the device type for compatibility with the firmware version. If the firmware file revision does not support the hardware revision of the named device, ffutil will put out a warning message and will not download firmware to that device. For example:

    ffutil: WARNING: Rev 4 firmware file not downloadable 
    to Rev 2/3 device /dev/ff/ff5
    

    If this error message occurs, check the device name in the downloading command for typing accuracy. Also check that you are in the intended source directory.

    The program will continue executing (downloading to any other specified devices) or exit to the system prompt.


  8. When the devctl-c command eventually completes, it will report the devices that it has found. Compare the "found" temporary ff device name to the "erasing flash" name in the first line of the ffutil output. Restore the original name as described in the next step.

    ffutil: Erasing flash on /dev/ff/ff0
    .
    .
    .
    devctl: Found +ff8, fabric0, sd4, sd5, sd6, sd7, sd813, sd14, sd15, sd16
    Download was successful on device ff0
    #
    
  9. Immediately following the download completion, change the temporary name back to the original name that was specified in the downloading command:

    #devctl -D ffoldname
    #devctl -n +ffnewname ffoldname
  10. Verify that the SuperFly-4 FC Host Adapter named in the devctl -ncommand has been correctly upgraded and renamed. For example:

    # /etc/showcfg| grep FF
     System Configuration: 
    type       no 
    FF         0   on quad 0, hw ver FireFly-3, sw ver FF2.30
    FF         4   on quad 0, hw ver FireFly-3, sw ver FF2.30
    FF         2   on quad 1, hw ver SuperFly-4, sw ver FF3.22a0
    FF         3   on quad 1, hw ver SuperFly-4, sw ver FF3.22a0
    
    

  11. Repeat Step 7 through Step 10 for each LP7000E FC Host Adapter in the system to bring them all to the same release level.

  12. To update all of the LP7000E FC-Host Adapter boards in a system from this directory with a single command, issue the following full-path command and options:

    # /usr/service/bin/ffutil -l -a -D -f fc_sf_ha.bin

    where:

    The -a option specifies that all FC Host Adapters (ff) devices found that match the file type are to be updated by the utility.

  13. When the ffutil command eventually completes, it will report the devices that it has found. Compare the "found" temporary ff device names to the "erasing flash" names in the first line of the ffutil output. Restore the original names as described in the next step.

    ffutil: Erasing flash on /dev/ff/ff0
    .
    .
    .
    devctl: Found +ff8, fabric0, sd4, sd5, sd6, sd7, sd813, sd14, sd15, sd16
    Download was successful on device ff0
    #
    
  14. Immediately following the download completion, change the temporary names back to the original names that were specified in the downloading command:

    #devctl -D ffoldname
    #devctl -n +ffnewname ffoldname
  15. When the download command completes, verify that the SuperFly-4 FC Host Adapters named in the devctl -ncommand have been correctly upgraded and renamed. For example:

    # /etc/showcfg| grep FF
     System Configuration: 
    type       no 
    FF         0   on quad 0, hw ver FireFly-3, sw ver FF2.30
    FF         4   on quad 0, hw ver FireFly-3, sw ver FF2.30
    FF         2   on quad 1, hw ver SuperFly-4, sw ver FF3.22a0
    FF         3   on quad 1, hw ver SuperFly-4, sw ver FF3.22a0
    
    

  16. Issue the devbuild -a command to build all virtual devices and make them available to the system.

  17. Reboot the system to the multi-user level.


    ATTENTION

    Occasionally, a system command used by ffutil to configure devices (devctl -c) will leave devices with temporary names, even though those particular devices actually have permanent names in the naming database. If there are temporary names after booting to multi-user, the command devctl -N will reassign the original permanent names to those devices.


  18. When the reboot is complete, use the information in the dumpconf output, created before starting this procedure, to confirm that the naming database has renamed them as before and to restore any custom names for any device at this time.