          iSCSI Driver for VMware ESXi 5.5
                   Release Notes

                  QLogic Corporation
                  All rights reserved


Table of Contents

1. Change History
2. Known Issues
3. Notices
4. Contacting Support



1. Change History

This section includes:

 * 1.1 Features Added
 * 1.2 Bug Fixes


1.1 Features Added

644.55.36.0
-----------

 * None

644.55.35.0
-----------

 * None

644.55.34.0
-----------

 * None

644.55.33.0
-----------

 * Removed support for 84XX series CNA.

644.55.31.0 - 644.55.32.0
-------------------------

 * None

644.55.30.0
-----------

 * Added support for new opcodes (RDDFE, RDMDIO, POLLWR) for the 84XX series
   CNA minidump.

 * Added support for the 82XX series CNA minidump PEX DMA feature.

644.55.29.0
-----------

* Added support for 83XX series CNA in the libraries used by the
  minidump extraction utility.

* Added support for 84XX series CNA in the minidump extraction utility.

644.55.25.0 - 644.55.28.0
-------------------------

 * None

644.55.24.0
----------

* Removed "-1vmw" from driver version as per ESX 5.5 Driver Version Policy.

644.55.19.0-1vmw - 644.55.23.0-1vmw
-----------------------------------

 * None

644.55.18.0-1vmw
----------------

 * Added support for 84XX series CNA.

634.55.18.0-1vmw
----------------

 * Added support for ESX 5.5
 * Added new IMA vib ima-qla4xxx-500.2.01.31-1vmw.0.3.040121.i386.vib
   in combined offline-bundle.
 * Updated BUILDTYPE to beta.

634.5.17.0-1vmw - 634.5.18.0-1vmw
---------------------------------

 * None

634.5.16.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	The current drivers do not support VMware's auto deploy feature
   SOLUTION:
	Add statelessReady to SCONS file to support auto deploy feature

 * PROBLEM DESCRIPTION:
	The current IMA plugin dependency '2.00.26' does not support 83XX cards.

   SOLUTION:
	Updated the IMA plugin dependency in the SCONS file to '2.01.31'.

634.5.15.0-1vmw
---------------

 * None

634.5.14.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	The minidump extraction utility did not support 83XX series CNA.

   SOLUTION:
	Added support for 83XX series CNA.

634.5.13.0-1vmw
---------------

 * PROBLEM DESCRIPRION:
	QLA4xxx and 82XX firmware may assert if given more IOCBs
	than it can handle.

   SOLUTION:
	The driver was updated to throttle the number of active
	IOCBs based on the total # of IOCB buffers received from
	GetFirmwareStatus mbx_sts[2].

634.5.9.0-1vmw - 634.5.12.0-1vmw
--------------------------------

 * None

634.5.8.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	The ESX standalone utility ql4_dump (used to extract minidump)
	had a filename that was not standardized across the same utility
	used in other operating system distributions.

   SOLUTION:
	The standardized minidump filename format is now
	qla4xxx_fw_dump_<inst>_<timestamp>.bin.

634.5.7.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	The qla4xxx driver needs to participate in loopback initiated by other
	drivers.
   SOLUTION:
	Added support for IDC (Inter-Driver Communication) Request Notify AEN


634.5.6.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	Update debug logs to be dynamically configurable and consistent
	across driver.
	Made the debug logging scheme consistent across the driver that
	includes ioctls and core driver. The logging scheme allows use
	of DEBUGX (where X = 1,2,3...) to specify component/level.
	Currently defined levels are as follows

	// DEBUG1 (0x01) - Unused
	// DEBUG2 (0x02) - General Debug Logs
	// DEBUG3 (0x04) - Connection Event Logs
	// DEBUG4 (0x08) - IOCTLs
	// DEBUG5 (0x10) - Verbose Logs/Messages
	// DEBUG6 (0x20) - Unused
	// DEBUG7 (0x40) - Unused
	// DEBUG8 (0x80) - Unused
	// DEBUG9 (0x100) - Mini Dump & Core Dump

	Single or multiple levels/components can be enabled by setting
	value for ql4xextended_error_logging. To enable multiple
	components, DEBUGX value should be OR'ed and assigned to
	ql4xextended_error_logging. e.g

	setting ql4xextended_error_logging=0x02 will only enable general
	debug logs setting ql4xextended_error_logging=0x0A will enable
	general debug logs + IOCTLs setting ql4xextended_error_logging=0x11E
	will enable all the currently defined log levels.

	NOTE: ql4xextended_error_logging should be assigned a hex value
	instead of an integer value.

	Each log level can be enable/disabled dynamically at runtime by
	writing ql4xextended_error_logging value to proc e.g

	echo ql4xextended_error_logging=0x08 > /proc/scsi/qla4xxx/yy
	(where yy is the device number assigned to your device)

	NOTE: ql4xextended_error_logging should be assigned a hex value
	NOTE: Updating ql4xextended_error_logging value for any device
	will update it globally for all devices.

634.0.5.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	IDC (Inter-Driver Communication) feature of bringing back a slower
	driver into IDC participation mode not present.

	According to IDC spec, if a driver does not acknowledge a reset
	request within reset ack timeout, the reset owner would mark this
	driver function as invisible (clear_drv_active()) and continue with
	the reset recovery. This marks the non acking function in a
	non-participating mode. That function needs to enter IDC once
	it is in a position to gracefully continue.

   SOLUTION:
	Add dynamic detach-reattach support for 83XX IDC

	For iSCSI driver, this is handled as follows,
	The presence bit will be checked from timer/watchdog context and
	the detach would be scheduled from dpc(). (can't detach from
	timer/interrupt context). This will put rest of processing
	on hold.
	From dpc(), detach would complete, which means the driver is in
	'idle' state, waiting to reattach.
	The driver would try to reattach right away (to expedite the
	process), as soon as the FW state is RDY.


 * PROBLEM DESCRIPTION:
	Currently, there is no mechanism to capture the driver version
	information from the firmware.
   SOLUTION:
	Add OCBB support(support for pushing the driver version to the)
	firmware for 82XX/83XX.

 * PROBLEM DESCRIPTION:
	Challenge to distinguish between an IOCTL call invocation
	by a QLogic application vs a non-QLogic application in the
	field.
   SOLUTION:
	Display invalid ioctl magic number received when driver debug
	is enabled.
	The "invalid ioctl magic number received" indicates that a
	non-QLogic IOCTL was encountered. These logs do not indicate
	a problem. They are informational. However, it's unnecessary
	for the driver to display this message on a non-debug driver
	and could cause unnecessary alarm, so the driver will be
	updated to display this message only if debug is enabled.

634.0.4.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	No way of debugging IDC lock contention failures.
   SOLUTION:
	Added idc_lock() debug messages to display lock ownership
	info for 82XX.


634.0.3.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	Driver does not attach to the HBA because of IDC version
	mismatch.

	83XX IDC assumes that if IDC version is set already, only a
	driver that complies with the version can load. Also, the IDC
	version that is set by a driver will only get cleared when
	the system power cycles. Under the circumstances, it is best
	that when the last driver attached to the HBA unloads, it
	clears the version so that for the next session, if a driver
	with a greater IDC version gets loaded, it can attach to the
	hardware and operate.
   SOLUTION:
	Last driver to unload clears IDC version.

 * PROBLEM DESCRIPTION:
	Driver does not take into consideration a target's response
	time while queuing IO requests.

	Different targets have different performance capabilities. If
	a particular target is not able to handle X amount of
	outstanding commands, we should throttle down the queue depth
	to ensure that we do not have to perform error recovery
	frequently.
   SOLUTION:
	Add change_queue_depth API support change_queue_depth will
	adjust device queueudepth upon receiving "SAM_STAT_TASK_SET_FULL"
	scsi status from the target. Also added ql4xqfulltracking command
	line param to enable or disable queuefull tracking. One can
	disable queuefull tracking to ensure user set scsi device
	queuedepth is not altered.

634.0.2.0-1vmw
--------------

 * Added changes to complete 83XX feature support.

634.0.1.0-1vmw & Previous Releases
----------------------------------

 * Improved proc display of driver runtime information.
 * Add support for modifying module parameter.
 * Added support for Async PDU based device discovery.
 * Added support for LUN change notification via Unit Attention.
 * Added support to send dynamic LUN change into to GUI.
 * Increase AEN queue depth to handle MAX_TARGETs.
 * Added support for External loopback.
 * Register the generic MSI handler to the PCI subsystem.
 * Support for returning chip revision to the Application.
 * Enable Minidump by default
 * Added Beaconing support



1.2 Bug Fixes

The following fixes were made to the iSCSI adapter driver
for ESXi 5.5 between versions 5.01.03.1-9vmw and 644.55.36.0

644.55.36.0
-----------

 * PROBLEM DESCRIPTION:
    VMK_ASSERT() condition for lun ids more than 255 in second level lun support. 

   SOLUTION:
    VMK_ASSERT condition is removed. 

 * PROBLEM DESCRIPTION:
    Lun reset is failing for lun ids greater than 255.

   SOLUTION:
    Current lun_reset mailbox interface takes only single byte for
    lun_id, its changed to accept 2 byte lun_id.

 * PROBLEM DESCRIPTION:
    IOs are getting timed out on slow targets, causing
    abort commands from scsi-mid layer.

    Abort commands are also getting timed out casuing ISP reset.
    The cycle continues and host is stuck.

   SOLUTION:
    Use mailbox IOCB interface fo sending Abort commands instead of
    mailbox command.
    Support is added for 10G adapters(P3+ and Hilda), support for 1G
    is already added in 5.35 release.


644.55.35.0
-----------

 * PROBLEM DESCRIPTION:
    We are trying to remove iSCSI session in same context for which a
    recovery_timedout handler is called which results in PSoD.

   SOLUTION:
    Removing the stale DDB in DPC. We mark ddb_state as DF_REMOVE and we queue
    the work.

 * PROBLEM DESCRIPTION:
    IOs are getting timed out on slow targets, causing abort commands from scsi-mid layer.
    Abort commands are also getting timed out casuing ISP reset.
    The cycle continues and host is stuck.

   SOLUTION:
    Use mailbox IOCB interface fo sending Abort commands instead of
    mailbox command.

644.55.34.0
-----------

   * PROBLEM DESCRIPTION:
	PSOD is observed while qla4xxx driver is initializing.

	While initializing qla4xxx if qla4xxx_get_ifcb fails
	we are calling dma_free_coherent twice which causes PSOD.

   SOLUTION:
	Make sure memory is freed only once to avoid PSOD.
	Remove unnecessary dma_free_coherent call.

644.55.33.0
-----------

  * PROBLEM DESCRIPTION:
	iSCSI functions doesn't print proper message if valid dump already exists
	and does not take save the latest dump.

   SOLUTION:
	Print a message indicating the Minidump was not collected because a
	valid dump already exists.

  * PROBLEM DESCRIPTION:
	The description associated with module parameter "ql4xextended_error_logging"
	is not accurate.

	Not all supported options are currently listed.

   SOLUTION:
	Add description of all possible values/bits.

644.55.32.0
-----------

  * PROBLEM DESCRIPTION:
	Extraction utilities collect corrupt minidump.

	Parser script fails to parse the captured minidump because of invalid
	header info.  There is a mismatch between common structure used in
	extraction library and iscsi driver.  This causes initial 3 bytes of
	header information written to wrong address.

   SOLUTION:
	Driver structure is made in sync with extraction library.

644.55.31.0
-----------

 * PROBLEM DESCRIPTION:
	When iterative loopback test is initiated from FCoE function,
	the iSCSI targets go offline.

	The driver disables and restore ACB to enter and exit loopback mode
	respectively.  When back to back loopback is performed, the bottom half
	could have both disable ACB & restore ACB tasks queue up.
	The problem is, currently, the driver processes disable ACB first
	followed by restore ACB, causing mailbox command failures.

   SOLUTION:
	Correct the order of handling disable & restore ACB calls.

644.55.30.0
-----------

 * PROBLEM DESCRIPTION:
	System hangs during boot with 82XX in MSI mode on Dell R720 & M620.
	[ER109001]

	It seems like when the driver loads, there is an outstanding
	interrupt pending to be processed, which is generated before
	the driver registers its interrupt handler (pci_enable_msi
	triggers the interrupt), because of which when the driver
	transitions from polling to the interrupt mode, it waits for
	an interrupt to be generated, while the firmware waits for
	the outstanding interrupt to be cleared.
	It is not very clear at this point on why the pending
	interrupt scenario is only observed on some Dell architectures.

   SOLUTION:
	Cleanup outstanding interrupts during driver load.

	As part of adapter initialization, once interrupts are
	disabled, cleanup any pre-existing legacy interrupts for
	82XX adapters.

 * PROBLEM DESCRIPTION:
	iSCSI recovery taking too long when detached from IDC. [ER114765]

	When iSCSI function is forcefully detached from IDC, it was
	not following detach-reattach procedure, instead going for
	recovery which takes more time.

	While recovering, if detached forcefully from IDC iSCSI driver
	is clearing corresponding DPC bit without handling detach-reattach
	routine. Instead it was going for one more recovery cycle which
	affects all protocols.

   SOLUTION:
	When detached from IDC, follow detach-reattach procedure.

	If DPC_83XX_HANDLE_DETACH_REATTACH is set, not setting presence
	bit and clearing the bit once reattach is successfully complete.
	Clearing RISC interrupt after disable_intrs.

644.55.29.0
-----------

 * PROBLEM DESCRIPTION:
	Driver incorrectly attempted to relogin device on LINK_UP
	while the initiator IP was unconfigured. [ER111678]

	When the initiator IP transitioned to an UNCONFIGURED state,
	the IP State was not updated in the driver; therefore, the
	state was inaccurate when checked.

   SOLUTION:
	Update IP state in the driver when the IP transitions to an
	UNCONFIGURED state.

	QLA83xx and QLA84xx firmware provide the IP index, which identifies
	the actual IP whose state is changing, in mailbox 5 of AEN 8029.
	QLA82xx and QLA4xxx firmware do not provide the IP index, so the
	driver queries the firmware via get_dhcp_ip to obtain the IP index.

  * PROBLEM DESCRIPTION:
	Capturing minidump on multiple ports results in reduced capture mask.

	When the system is low on memory, and we attempt to allocate memory
	for minidump on both adapter ports, one of them gets a very small
	memory buffer.  When the minidump is captured on that port, the
	resulting dump captures information using a capture mask that is
	lower than the recommended value, limiting the debug information
	collected.

   SOLUTION:
	Capture minidump only on the lower iSCSI function.

	There is no minidump buffer allocation for the higher function
	if lower function is present.

644.55.28.0
-----------

 * PROBLEM DESCRIPTION:
	LINK_DOWN during recover_adapter prevented SendTarget discovery.
	[ER113786]

   SOLUTION:
	Added retries of reinit_ddb_list, invoked after LINK UP and IP
	configuration.

 * PROBLEM DESCRIPTION:
	Minidump collection on Helga adapters is failing with
	datasize mismatch error. [ER114306]

	Minidump size allocated and minidump captured is not same.

   SOLUTION:
	Datasize for skipped entries is properly calculated.

	Size of entry headers with not supported capture mask
	value is not be included in skip size.

644.55.27.0
-----------

 * PROBLEM DESCRIPTION:
	Display readable board revision id in proc.

	Current proc information for hba adapter shows the numeric
	revision id, it would be better to display the related
	revision string.

   SOLUTION:
	Revision id to revision string mapping is created and revision
	string is printed instead of revision id.

 * PROBLEM DESCRIPTION:
	Some of the entries in proc files were showing incorrect values
	e.g. isr_count, request_out etc.

   SOLUTION:
	Corrections done to show exact values in proc and some of the unused
	entries are removed.

 * PROBLEM DESCRIPTION:
	Do not block session for DEAD devices.

	When marking devices missing, DEAD devices are bypassed.
	However, there is common code to block the session.

   SOLUTION:
	Only block session when marking device MISSING.

	Moved the block_session code to only invoke within the
	context of marking the device MISSING.  No action is
	taken if a device is DEAD.

 * PROBLEM DESCRIPTION:
	AEN 8014, mbx_sts[1] = 0, indicates global database change and
	it has never been implemented in the firmware.

   SOLUTION:
	Remove references to it in the driver.

	Also updated 8014 AEN print statements to be more user friendly

 * PROBLEM DESCRIPTION:
	Currently there is no logic to remove a stale DDB.

	A stale DDB is one which has been deleted from the storage side and
	it's fw_ddb_index has been reused by another DDB.  Currently this
	type of DDB is still displayed in proc when it is actually not
	present.

   SOLUTION:
	Added logic to remove stale DDBs.

	1. Changed stale DDB representation from fw_ddb_index=0xDEAD to
	fw_ddb_index=INVALID_ENTRY
	2. Created single function qla4xxx_mark_ddb_stale to handle stale ddb
	functionality and state transitions.
	3. Created single function qla4xxx_mark_device_removed to handle state
	change to REMOVED.

 * PROBLEM DESCRIPTION:
	A target was marked DEAD even after it came back ONLINE (Mbx 56 failure)

	A target was removed then re-added from the Storage Array, then all
	Static Discovery targets were deleted from VSpehre leaving the Dynamic
	Discovery targets configured, and then a rescan was issued via VSpere.

	During the rescan, Mbx 56 (Close Connection + free ddb) failed during
	IOCTL Logout, therefore the DDB was never marked REMOVED and the
	target_destroy never came down (marked FREE).  Since the old DDB was
	never FREE'd, the new DDB was never marked online.

	The Mbx 56 failed because the behaviour of Mbx 56 (Close Connection)
	changed and the change was not documented in the spec.  In previous
	firmware, a Mbx 56 (Close Connection + free ddb) would free the DDB
	regardless of the previous connection state of the DDB (i.e. SESSION_
	ACTIVE, FAILED, NO_CONNECTION, etc.).  Now, Mbx 56 (Close Connection)
	will only succeed if there is an ACTIVE DDB connection with or without
	the free ddb option specified.

  SOLUTION:
	Updated driver to reflect new firmware behaviour

	Both the driver and firmware spec were updated to reflect the new
	behaviour of the Mbx 56 (Close Connection) described above.

 * PROBLEM DESCRIPTION:
	Currently, there are no installation instructions for ql4_gdmp
	minidump extraction utility.

   SOLUTION:
	Added README file containing installation instructions for ql4_gdmp

	Also, moved all ql4_gdmp related files to extras/ql4_gdmp/ subdirectory.

 * PROBLEM DESCRIPTION:
	The ka_timeout command line parameter is not used [ER111388]

	The driver writes the value specified in the ka_timeout parameter to
	the ifcb->ka_timeout during driver load, but does not save it to flash.
	When ddbs are created, the default_ddb ka_timeout value is taken from
	the default ifcb ka_timeout (from flash). Since the ddb ka_timeout
	value supersedes the ifcb timeout value, the ka_timeout value which was
	written to the ifcb->ka_timeout during driver load is never utilized.

   SOLUTION:
	Remove the unused ka_timeout command line parameter.

	For active I/O, the cmd_timeout parameter is used. Otherwise, the NOP
	timeout (ka_timeout) specified in the ddb is used to detect connection
	loss.

644.55.26.0
-----------

 * PROBLEM DESCRIPTION:
	Application fails to access target entry while attempting to change
	IP address

	When administrator removes a target entry and re-adds a new one (in a
	single operation), the newly added entry gets written into the same
	index in persistent memory if it is the first empty location.
	In this case the driver's internal target database goes out of sync
	with it's lookup table which is used by the application for various
	operations e.g. IP address change.

   SOLUTION:
	Ensure that lookup table and target database are in sync at all times.

	In free_ddb call do not clear the ddb entry from fw_ddb_map for the
	ddbs which are already in DDB_STATE_REMOVED, because it is already
	cleared while setting ddb to removed state.

644.55.25.0
-----------

 * PROBLEM DESCRIPTION:
	Continuous FW Reset Recovery on changing IP after remove and add Targets

	The fw_ddb_index is getting marked 0xDEAD, but an I/O is still being
	sent to the target. After FW Reset Recovery, the relogin_all_ddbs
	function did not check for the fw_ddb_index of 0xDEAD, hence, marked
	the stale ddb back online. This allowed I/O to be issued to a device
	that was technically unavailable.

   SOLUTION:
	Skip 0xDEAD targets when reloging in targets after FW Reset Recovery

 * PROBLEM DESCRIPTION:
	After removing an existing target and simultaneously adding a
	different target, the new target is marked DEAD.

	The old fw_ddb_index was not marked stale (fw_ddb_index=0xDEAD)
	prior to adding the new ddb that reused the same fw_ddb_index.
	Therefore, when the old ddb was finally freed, the entry into
	the driver's ddb array was also removed. After a reset occurred
	and the driver attempted to rebuild the ddb list, it marked the
	ddb stale (fw_ddb_index=0xDEAD) because the there was no longer
	an entry into the ddb array for that ddb.

   SOLUTION:
	When adding a new target that reuses the same index as an
	existing target, mark the old target DEAD.

644.55.24.0
-----------

 * PROBLEM DESCRIPTION:
	PSOD on proc invocation when duplicate targets are
	configured in the BIOS. [ER110424]

	When same LUN is configured for primary and secondary
	boot in bios BFS settings; at boot time driver detects
	a duplicate target entry but still tries to add iscsi
	session for duplicate one which fails and we goto
	remove_adaptor. But complete clean up does not happen
	in this case and entry for this port still shows up in
	proc filesystem. An attempt to open that file results
	in PSOD.

   SOLUTION:
	Prevent duplicate target sessions from being added.

	Check if a particular target is made online or not
	before calling qla4xxx_add_sess; if not online skip it.

 * PROBLEM DESCRIPTION:
	The driver load fails if adding an iscsi session for
	a target fails.

	Currently if qla4xxx_add_sess fails for a particular
	target, we goto remove_adapter and that port becomes
	inactive for any operation till next boot.

   SOLUTION:
	Do not fail driver load if adding iscsi session fails.

	If qla4xxx_add_sess fails for a target we should move
	on to the next one in the ha->ddb_list

644.55.23.0-1vmw
----------------

 * PROBLEM DESCRIPTION:
	We are not dumping outgoing mailbox registers in case of system error
	(8002) which is mandatory as per firmware specification

   SOLUTION:
	Dumping mailbox and some other registers now which will be helpful
	for debugging.

 * PROBLEM DESCRIPTION:
	Sometimes a target does not come back online after a reset

	If the keepalive timer expires while the driver is waiting the
	mandatory time-between-relogin period, a timer was being cleared that
	triggered future relogins. Therefore, relogins stopped occurring if
	both of the above conditions were met. [ER103850]

   SOLUTION:
	Do not prevent relogins after the keepalive timeout has exhausted.

	Removed the code that cleared the relogin timers during recovery_
	timedout.

 * PROBLEM DESCRIPTION:
	vmkernel shows DEVICE_UNAVAILABLE when running add-target tests
	[ER110235]

	A logout was issued to the target during an IOVP test and the target
	was marked REMOVED. Then an AEN 8014 was received transitioning the
	state from FAILED to NO_CONNECTION_ACTIVE. The driver incorrectly
	re-added the target with NO_CONNECTION_ACTIVE state, which resulted
	in multiple DEVICE_UNAVAILABLE errors when the OS attempted to
	communicate with the target.

   SOLUTION:
	Do not add targets that have non-active sessions.

	Added a test for SESSION_ACTIVE prior to re-adding a target.

  * PROBLEM DESCRIPTION:
	Observed a PSOD while collecting minidump with capture mask
	of 0xff with Hilda adapter. [ER109556]

	The PSOD is because of the vmkernel detecting a possible
	PCPU Lockup. This happens because the minidump routine, when
	run with capture mask of 0xff without pex-dma, takes a significant
	amount of time.

    SOLUTION:
	There is no workaround possible for this issue, hence we are
	documenting it in the Readme.

  * PROBLEM DESCRIPTION:
	Driver holds rom-lock for too long during reset recovery.

	During Peg halt testing, it was found that the driver
	holds the rom-lock for too long, because of which other
	drivers fail to acquire the rom-lock, leading to reset
	failures.
	The primary cause is, in the bootstrap code, while
	holding the rom-lock, the driver checks if the peg is
	halted, causing a 2 second contention.

    SOLUTION:
	When a reset recovery starts, the driver deduces the cause, and
	sets appropriate flags in watchdog & recover_adapter routines.
	This flag should is used to determine if bootstrap is invoked
	from probe or reset context, reducing the rom-lock footprint of
	the drivers.

  * PROBLEM DESCRIPTION:
	System becomes unresponsive and continuous ABORTs are observed if a
	firmware system error (peg halt) occurs during recovery. [ER109776]

	In the recovery path, flags AF_RST_HDLR_ACTIVE and
	DPC_RESET_HA_FW_CONTEXT are set; so qla4_8xxx_watchdog is returned
	without checking qla4_8xxx_check_fw_alive.  So if there is another
	peg_halt(system error) during recovery it is not handled and adapter
	initialization completes without 'firmware ready'.  SCSI queries are
	not answered hereon and ABORT is issued which also does not succeed and
	iSCSI system becomes unresponsive and continuous ABORTs are observed.

    SOLUTION:
	Updated algorithm to cover the scenario where another peg_halt
	occurs during recovery when firmware is up but initialization is not
	completed.

	Now we will check flag AF_FW_RECOVERY only in qla4_8xxx_watchdog.
	This flag is reset as soon as firmware is up, so from that point
	on it is correct to check qla4_8xxx_check_fw_alive.

  * PROBLEM DESCRIPTION
	PSOD occurs after the driver attempts to free a target session
	that has not been added. [ER109903]

	After the driver encountered a problem adding the target session,
	it's failing the driver load. During this process, the driver attempts
	to free a target session that has not been added, and this is why the
	PSOD occurs. The driver had no way of determining if iscsi_add_session
	failed or succeeded for a particular target.

    SOLUTION
	Added a flag to indicate whether the target session was added
	and added logic to NOT free a target that had not been previously
	added.

	Set the DF_ISCSI_SESSION_ADDED bit in the ddb_entry structure if
	iscsi_add_session succeeds so that the driver can determine whether
	to call iscsi_free_session or not when destroy_session is invoked.

644.55.22.0-1vmw
----------------

 * None.

644.55.21.0-1vmw
----------------

 * PROBLEM DESCRIPTION:
	Multiple esxcfg-rescan needed for OS to discover LUNs
	after IP Address Change. [ER109194]

	The issue is we invoke add_device to add a new ddb,
	from the target_destroy context. On doing so,
	the scsi_scan seems to not work, due to which
	another esxcfg-rescan is needed to get the
	target online.

   SOLUTION:
	Instead of doing add_device in target_destroy call,
	we are doing it in dpc thread.

	Because free_device has to be with add_device in
	current algorithm, even that has been moved to dpc
	thread.  And now LUNs are seen after a single rescan.

 * PROBLEM DESCRIPTION:
	When IP address of host adapter is changed, logout is
	issued multiple times on connected targets. [ER109194]

	On first instance Mailbox command 'Connection Close'
	is fired and is successful. On the next logout mailbox
	fails.  On logout we are marking the target for removal
	but not clearing the entry from fw_ddb_index_map in
	the same context, instead we are doing it in
	free_ddb which gets called in target_destroy context.
	causing mailbox command to fail on next logout.

   SOLUTION:
	Properly mark target as removed to prevent multiple
	logout attempts.

	When logout is issued for the first time, we are now
	making the ddb_entry in fw_ddb_index_map as NULL
	while marking it for removal, so that no operations
	are performed on that entry henceforth.

644.55.20.0-1vmw
----------------

 * PROBLEM DESCRIPTION:
	iSCSI LUNs go into DEAD state on iSCSI parameter update. [ER 103586]
	Reworked original patch from 634.5.14.0-1vmw.

	The old algorithm preserved the fw_ddb_index (used to readd ddb after
	free) by encoding it with a mask and then decoding it several places
	in the code. This algorithm added unnecessary complexity to the code.

   SOLUTION:
	The new algorithm saves the fw_ddb_index (used to readd ddb after free)
	in a newly added variable in the driver's ddb entry structure.
	After the original ddb has been completely removed/frees, the saved
	fw_ddb_index is used to readd the ddb to the driver's database.

 * PROBLEM DESCRIPTION:
	DPC can get scheduled before AF_INIT_DONE is set for hilda/helga.
	In that case dpc returns w/o clearing AF_DPC_SCEDULED flag, which
	prevents further dpc invocations.

   SOLUTION:
	The fix is to clear AF_DPC_SCHEDULED flag if AF_INIT_DONE is not set.

 * PROBLEM DESCRIPTION:
	The ESX OS PSODs with heartbeat failure on the PCPU.

   SOLUTION:
	The fix ensures that driver sleeps for 2 msecs every 4 seconds,
	if it has been capturing minidump for more than 4 seconds.

 * PROBLEM DESCRIPTION:
	With higher capture mask (0x7f, 0xff), it takes significant time
	( > 10-15 sec) for minidump capture by iscsi driver.

	The RDMEM mdump-entry using indirect reg access reads 128b at a time.
	This slows the capture.

   SOLUTION:
	The fix is to use added pex-dma support for faster memory reads in
	the capture.

644.55.19.0-1vmw
----------------

 * PROBLEM DESCRIPTION:
	If LINK_UP occurs shortly after LINK_DOWN, target relogin
	may not occur.

	In order to have fast recovery of targets, the driver needs
	to immediately issue relogin upon LINK_UP. The firmware
	requires that the driver wait time2wait seconds between
	the target logging out before issuing a relogin; otherwise
	the firmware will return a 0x4005 error.  Since the driver
	has no knowledge of how long the link was down, it's
	possible that some 0x4005 error might occur in the corner
	case when LINK_DOWN -> LINK_UP occurs within the time2wait
	period. The driver did not retry a relogin in this case,
	resulting in the target not coming back online.

   SOLUTION:
	The driver now makes an additional attempt to relogin the target.

	If the driver receives a 0x4005 error after the initial
	relogin attempt, the driver will now wait time2wait seconds
	and then make an additional relogin attempt.

 * PROBLEM DESCRIPTION:
	Since ddb_changed AENs were flushed during driver reinitialization,
	any new ddb that would not be detected. Instead a debug message was
	printed.

   SOLUTION:
	If a new ddb is detected during scan of the firmware's ddb list
	then the ddb is added to the driver's internal database and then
	presented to the OS.

 * PROBLEM DESCRIPTION:
	The test proc parameter halt_on_connerr=0 does not unhalt the HBA
	as expected. [ER 106230]

	The IDC only transitions to NEED_RESET from READY state.
	Halting the HBA puts IDC in FAILED state, which prohibits
	transitioning to NEED_RESET state as required to recover the adapter.

   SOLUTION:
	Forced the appropriate state transition for this test code so that
	adapter recovery can occur.

	For the halt_on_connerr=0 test code only, we forced the IDC to RESET
	state to Unhalt HBA, so that adapter recovery can occur.

 * PROBLEM DESCRIPTION:
	An error condition encountered while searching for a ddb in the
	driver's internal database is also falsely interpreted as a
	non-existent ddb and could result in allocation of a duplicate ddb.

	The find_and_update_ddb function is called to search for an existing
	specified ddb in the driver's internal database. The function returned
	a NULL ddb_entry pointer if there was an error allocating temporary
	memory, or there was a mailbox command error, or if the specified ddb
	was not found. The calling functions were unable to distinguish between
	an error condition and a non-existent ddb, assumed the ddb was not
	found, and then proceeded to allocate a new ddb.

   SOLUTION:
	The driver was updated to properly distinguish between an actual error
	condition and a non-existent ddb in searching for a ddb in the driver's
	internal database.

	The find_and_update_ddb function was updated to return an error status
	in addition to the ddb_entry. The calling function can now distinguish
	between an error and a non-existent ddb, and NOT allocate a duplicate
	ddb.

 * PROBLEM DESCRIPTION:
	Deferring DDB free could lead to a PSOD Post target destroy return,
	the mid layer can free up the ddb_entry at any point of time,
	hence we should not de-reference it, which might lead to a PSOD.

	Currently, we defer the task to dpc, which might lead to this problem.

   SOLUTION:
	Free DDB immediately in .target_destroy handler

 * PROBLEM DESCRIPTION:
	In the event of a system error, only 16bits (of 32bit registers)
	are getting printed.

   SOLUTION:
	Change the readw() calls to readl() calls in functions responsible
	for dumping registers to read out the complete 32bit values.

 * PROBLEM DESCRIPTION:
	Driver unload lead to a PSOD if probe_adapter failed because of a PCI
	enumeration failure (on linux).

   SOLUTION:
	Ensure that we perform cleanup only if the pci device enumeration
	succeeded.

* PROBLEM DESCRIPTION:
	Delay in reset ACK results in initiating another reset [ER 86974]

	The storage drivers ACK for the reset from their respective bottom
	halves (whose scheduling is not deterministic).  Delay in the ACK
	led to the qlcnic initiating the reset. When the storage drivers
	eventually ACK, they do not realize that the reset had already
	completed, because of which they initiate the reset again.

   SOLUTION:
	Updated reset algorithm to improve reset ACK time.

634.55.18.0-1vmw - 644.55.18.0-1vmw
-----------------------------------

 * None.

634.5.18.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	The bug fix for Loopback diagnostics in the 634.5.16.0-1vmw release
	failed to free memory properly.

   SOLUTION:
	Updated the fix to free memory properly.

634.5.17.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	FW Hangs when it encounters a mismatch between the IOCB cound and
	total DSDs. [ER 103736]

	If free req_q count is close to 0, we will re-calculate the space
	in qla4xxx_space_in_req_ring based on the consumer index. And then
	we may add back the same free space when we get completion in the
	response path. So we end up accounting for the same entries twice.

   SOLUTION:
	1) Updated driver algorithm that determines the space is available on
	the firmware request queue to solely rely on the firmware's
	request_q_in and request_q_out pointer positions.

	Request q count should be modified based on one of the below conditions
	(and not both):
	  1. Based on the difference between the request_q_in and the request_q_out.
	  2. Based on command completions that the driver receives.
	We now use only mechanism 1.

	2) Also, updated the driver to use shadow registers to read the firmware
	registers, as they are less expensive reads and lead to significant
	performance improvement.

634.5.16.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	qla4xxx driver performing (multiple)back-to-back resets in case of
	firmware hang.

	qla4xxx PCI func 4 detect peg_hlt and PCI func 5 detected NEED_RESET.
	In this case func 5 do not call mailbox_premature_completion() so
	AF_FW_RECOVERY flag is not set.
	Because of this recover_adapter() is waiting for scsi_cmds to complete
	before issue chip_reset. This cause need_reset timed out and NIC driver
	removes presence bit of PCI func 5.
	On PCI func 5 as FW is in hung state and driver is waiting for scsi_cmds
	to complete, scsi_cmds timed out and issue abort command which cause
	abort_cmd MBOX to execute, abort_cmd MBOX timed out as FW is hung and
	issue another reset.

   SOLUTION:
	Call mailbox_premature_completion() when qla4xxx PCI func detect NEED_RESET.
	This will compete MBOX cmd if any as well set AF_FW_RECOVERY flag.
	As AF_FW_RECOVERY flag is set driver will not wait for scsi_cmd to complete
	and issue chip_reset.

 * PROBLEM DESCRIPTION:
	In BFS scenario with 1G 4032 adapter, the driver failed to load.

	Due to a possible firmware bug, in BFS case, if the first try of
	qla4xxx_initialize_adapter fails, driver does not retry adapter
	initialization because irqs are not allocated and driver fails to
	load.

	For ISP40XX, irqs are allocated after adapter initialization, so
	driver should retry adapter initialization if it fails the first time.

   SOLUTION:
	When retrying adapter initialization, check AF_IRQ_ATTACHED flag
	only for ISP80XX.

 * PROBLEM DESCRIPTION:
	Loopback diagnostic test fails when performed in a loop (1).

	After set_port_config call to restore the original configuration,
	driver was completing the loopback call before IDC completion AEN
	and LINK_UP. And driver was failing the next loopback call because
	the previous loopback call was still in progress.

   SOLUTION:
	Return to application only after IDC completion AEN and LINK_UP after
	doing set_port_config. This will prevent overlap of two loopback calls
	and prevent loopback failures.
	Wait for LINK_UP only if link was UP when loopback was started.

 * PROBLEM DESCRIPTION:
	Loopback diagnostic test fails when performed in a loop (2).

	During loopback test, the driver refuses to run multiple tests.
	For mbox failure for loopback port config, the fw completes IDC,
	w/o reporting any error and application as well does not cleanup
	the port config state. This leaves driver with AF_LOOPBACK bit set,
	preventing further loopback config changes.

   SOLUTION:
	The fix is to ensure that on set_port config failure, after the IDC
	is complete, restore the configs to ensure driver is in safe state.
	It is important that the IDC is completed before trying restore.

634.5.15.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	LUNs do not come back online after host recovery (even on issuing
	esxcfg-rescan).

	Root cause is delayed recovery, (recovery_timedout) changes stale ddb
	state to DEAD from REMOVED(which is a invalid state change) leading to
	incorrect handling of AENs after esxcfg-rescan is issued.

   SOLUTION:
	Ensure the ddb state does not change from REMOVED to any other state.


634.5.14.0-1vmw
---------------

 * PROBLEM DESCRIPTION
	System PSODs because of an invalid handle.

	A mailbox command timed-out during driver load and the driver accessed
	a handle that had not yet been initialized.

   SOLUTION
	Validate the qli4im_ha handle in the mailbox timeout path prior to
	accessing it.

 * PROBLEM DESCRIPTION:
	Mailbox registers were being displayed in log file for non-debug driver.

	The DBG_MSG macro was being used to encapsulate multiple lines of code
	to be invoked when the appropriate ql4xextended_error_logging level was
	set.  However, the DBG_MSG macro was not defined to handle multiple
	lines of code.

   SOLUTION:
	Defined the error logging macros to handle multiple lines of code.
	Encapsulated the macro variable in {}.

 * PROBLEM DESCRIPTION:
	Driver allocates memory which remains unused through the lifecycle.

	We allocate and read reset sequence for higher iscsi function as well,
	which increases host mem usage and init time.
	This is not required as, higher iscsi function will never perform reset.

   SOLUTION:
	Do not alloc/read reset sequence for higher iscsi function

 * PROBLEM DESCRIPTION:
	iSCSI LUNs go into DEAD state on iSCSI parameter update. [ER 103586]

	What seems to be happening is, the application calls a logout when
	the parameter is modified, and a reset follows. The target_destroy
	does not come down, and hence the DDB entry does not get freed.
	Post reset when the AEN come in, we think that there has been a DDB
	index switch, and we change the index(which was set to 0xDEAD) to
	a valid index and mark the device online. The OS is unable to use
	the patch because we called iscsi_remove_session on it, and hence
	targets remain DEAD.

	There are two problems in the driver here,
	1. When a ddb is setup for removal (DPC_REMOVE is set), we set the ddb
	   state to REMOVED (and call iscsi_remove_session), but we wait
	   till a later point of time for the driver to figure out that the
	   ddb_entry is stale and set ddb_entry->fw_ddb_index to 0xDEAD. This is
	   a problem, because at various places across the code, we iterate through
	   the ddb_list without looking at the ddb_state (which is set to
	   REMOVED).

	2. We assume that once the ddb is set for removal, its fw_ddb_index
	   is of no use (which implies that we think that there is no
	   condition where post logout, the ddb entry might still be present
	   in the firmware), and hence might need to be brought back. We hit
	   that case here, and the fw_ddb_index was needed to be preserved.
	   So instead of marking fw_ddb_index 0xDEAD to indicate that it is
	   stale, we use the upper 5 bits (as the lower 11 bits will be used
	   for 512 entries) to indicate the stale ddb, and we keep the
	   fw_ddb_index intact, which is reused.

   SOLUTION:
	1. We are marking the DDB Stale, when we set the Device for removal
	   (before context reset)
	2. We ignore the AEN updation and reinit processing if DDB is marked
	   as stale (but we set a flag to ADD the device back once it is freed).
	   If the fw_ddb_index for the same DDB (IP, IQN touple) changed, we
	   update it in the Stale ddb, so that once it is removed and the new
	   ddb gets allocated, it is allocated with the correct fw_ddb_index.
	3. After receiving target_destroy to complete removal, we add the device
	   dynamically.
	4. We need to preserve the old_fw_ddb_index, so instead of overwriting
	   0xDEAD as earlier, we are using macros to manipulate the ddb_index.
	5. NOTE: ha->tot_ddb indicates total ddbs in the driver including stale
	   ddbs.  This handles the case, where a ddb which is scheduled for
	   removal gets processed from AEN and reinit() before target_destroy()
	   is handled.

 * PROBLEM DESCRIPTION:
	A non-descriptive hex# was being displayed for the adapter type in proc
	i.e. QLogic iSCSI Adapter fa9f260(rev 0)

   SOLUTION
	Display the correct adapter name
	i.e. QLogic iSCSI Adapter 8032(rev 1)

 * PROBLEM DESCRIPTION:
	The utility does not clearly print the error encountered during
	minidump extraction.

   SOLUTION:
	Print verbose messages as info and error messages based on the
	error encountered during dump extraction.

634.5.13.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	esxcfg-rescan takes too long while adding LUNs.

	This was because the driver was scheduling a bottom half to process
	the rescan but failed to wake up the bottom half handler.

   SOLUTION:
	Wake up the bottom half handler from the timer routine when rescan
	(DPC_DYNAMIC_LUN_SCAN) is scheduled.

 * PROBLEM DESCRIPTION:
	Driver modifies a set of E-port registers to disabling pause frames
	to the switch on a firmware hang. If a firmware hang happens during
	initialization and we attempt to modify the E-port registers in the
	reset state, it might cause hw wedging needing a power cycle to
	recover from.

   SOLUTION:
	Before disabling pause frames ensure that eport is out of reset.

634.5.12.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	Device state is handled incorrectly while running loopback test.

	Devices relogin after link up and are not marked missing after link
	down during loopback test.

   SOLUTION:
	When loopback test is run from iscsi, the link state info is not
	handled correctly.  idc_info.info2 is set correctly to
	set AF_LOOPBACK, used in processing link UP and DOWN events.

 * PROBLEM DESCRIPTION:
	Failure on trying to reset the loopback configs leave the 83XX
	adapter in non-operational state.

   SOLUTION:
	To recover from such failure we try and reset chip.

 * PROBLEM DESCRIPTION:
	As per specs, loopback test requests on a physical port
	already running loopback test must not be permitted.

   SOLUTION:
	If loopback is in progress all other loopback requests would
	be ignored on a port.

 * PROBLEM DESCRIPTION:
	With Firmware v5.2.4 the driver fails to initialize successfully.

	Definition of mbox cmd get sys info changed invalidating old code
	using incorrect mbox registers for size check.

   SOLUTION:
	Fixed the get_sys_info function according to new changes at both
	the places the mbox cmd is used.

 * PROBLEM DESCRIPTION:
	The system PSODs occasionally, after long run of IOs and
	disruptive operations followed by a firmware crash.

	When a scsi passthru command times out, the driver does not
	attempt to recover the command. The firmware does not timeout
	some of these commands, which leads to the driver and the firmware
	holding on to stale SRBs. When multiple such entries are sitting
	on our outstanding command array, and a host reset is performed,
	we attempt to abort all active commands. Because all the passthru
	command share a single srb entry, this leads to the reference
	count on the srb to reach 0, invoking BUG() in the debug driver.

   SOLUTION:
	The device driver should perform an abort (followed by a LUN reset
	if the abort fails to recover the command) if the passthru command
	times out. This would indicate the firmware to return the command,
	based on which the driver can clean up the stale entry.

 * PROBLEM DESCRIPTION:
	PSOD while running loopback test.

	With loopback in progress, driver handles link up/down events, trying
	to relogin and mark devices invisible. This clashes with loopback test.

   SOLUTION:
	Quiesce all different activities performed by driver upon link events,
	while the loopback is in progress.


634.5.11.0-1vmw
---------------

 * PROBLEM DESCRIPTION:
	Minidump capture shows invalid data.

	The array_index always remained set to 0 and never got updated
	in poll_read_list()

   SOLUTION:
	The array_index was correctly updated while processing
	poll_read_list() during reset sequence.

 * PROBLEM DESCRIPTION:
	The reset sequence signature verifies validity, which was not used.
	Possible memory leak in read template failure.

   SOLUTION:
	Added signature and size checks on reading reset sequence.
	On failure free the reset_seq buffer before returning error.

 * PROBLEM DESCRIPTION:
	Incorrect/corrupt minidump template will cause invalid minidump
	capture, and will hold up host memory.

   SOLUTION:
	The minidump template is verified using the header checksum.

 * PROBLEM DESCRIPTION:
	The allocated minidump buffer for higher iscsi function in 83XX
	will never be used and hogs host memory.

   SOLUTION:
	The minidump allocation is only done for lower iscsi function.

 * PROBLEM DESCRIPTION:
	Minidump buffer allocation failure during init time,
	will cause minidump not be collected in the event of a fw crash.

   SOLUTION:
	In case of insufficient host memory for minidump buffer allocation,
	the driver retries with next best capture mask.

 * PROBLEM DESCRIPTION:
	ql4xmdcapmask parameter should be handled correctly.

   SOLUTION:
	For invalid ql4xmdcapmask parameter the capture mask is set to
	template capture mask (default value).

 * PROBLEM DESCRIPTION:
	Firmware state displayed in proc was incorrect.

   SOLUTION:
	The firmware state gets updated only during initialization
	and doesn't reflect the current fw state.  This is removed from
	proc file as it doesn't help with anymore info.


634.5.10.0-1vmw
---------------
 * PROBLEM DESCRIPTION:
	Mailbox command failure observed in the logs.

	If a device has previously been marked for relogin and then the
	device gets removed, the relogin was still attempted resulting
	in a mailbox command failure.
   SOLUTION:
	Prevent relogin attempts for targets being removed.

634.5.9.0-1vmw
--------------
 * PROBLEM DESCRIPTION:
	PSOD observed with qla4xxx_timer in the context.

	A previous disable pause frame fix invoked  idc_lock from watchdog(),
	which is in the timer context. When 2 functions contend for
	lock for disabling pause frames, one would sleep, causing PSOD.

   SOLUTION:
	Call disable_pause frame outside of timer context.

 * PROBLEM DESCTIPTION:
	Mailbox command 0x63 failure observed.

	When the target is not online, relogin timeouts may take longer
	than the default timeout specified in the firmware.  Subsequent
	relogin attempts may result in Mbx 63 failure.

   SOLUTION:
	It was too risky to change the firmware for this corner
	case scenario, so a workaround was implemented in the driver to
	allow the firmware more time to timeout relogins and wait for
	an AEN 0x8014.  The TOE waits an additional 6 seconds to time
	out a FIN response, so the driver padded its relogin timeout
	by this amount plus an additional second.

 * PROBLEM DESCRIPTION:
	Vmkernel message of "ddb not dead but marked for offline" observed.

	If an offline target has been timed out by the vmkernel
	(i.e. qla4xxx_recovery_timed_out invoked), then came back online
	prior to the driver completing the target deletion in the dpc,
	a driver flag was not cleared to properly indicate that the target
	was back online.  The resulted in the error message.

   SOLUTION:
	Clear the DF_OFFLINE flag when marking the target ONLINE.

 * PROBLEM DESCRIPTION:
	Mailbox command timed out after switching from polling mode to
	interrupt mode.

	Events:-
	1. Mailbox interrupts are disabled
	2. FW generates AEN and at same time driver enables Mailbox Interrupt
	3. Driver issues new mailbox to Firmware

	In above case driver will not get AEN interrupts generated by FW in
	step2 as FW generated this AEN when interrupts are disabled. During
	the same time driver enabled the mailbox interrupt, so driver will not
	poll for interrupt. Driver will never process AENs generated in step#2
	and issues new mailbox to FW, but now FW is not able to post mailbox
	completion as AENs generated before are not processed by driver.

   SOLUTION:
	Enable Mailbox / AEN interrupts before initializing FW in case of
	ISP83XX. This will make sure we process all Mailbox and AENs in
	interrupt mode.

 * PROBLEM DESCRIPTION:
	Remove redundant force_polling flag.

   SOLUTION:
	Instead of using force_polling flag to decide for polling,
	use AF_INTERRURPTS_ON flag.

 * PROBLEM DESCRIPTION:
	Code review observation: Nested lock implemented by calling
	idc_locki(whick would lead to lock contention) where it should
	have been unlock.

   SOLUTION:
	Replace lock with unlock.


 * PROBLEM DESCRIPTION:
	Targets do not come back online after re-entering IDC.

	During detach reattach path, REBUILD_DDB_LIST was not recreating
	sessions correctly.

   SOLUTION:
	Instead of rebuilding the list, PRESERVE_DDB_LIST (as in recover path)
	for faster convergence.

634.5.8.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	Mailbox command timeouts and spurious interrupts observed in driver
	logs.

	Mailbox timeouts and spurious interrupts occurred intermittently
	due to the risc_intr getting cleared twice.

   SOLUTION:
	Removed unintended second clearing of risc_intr during polling
	for mailbox completion.

 * PROBLEM DESCRIPTION:
	The driver incorrectly polled for mailbox completion for all cases,
	even when using interrupt driven completion was appropriate.

   SOLUTION:
	Fixed default value of force_polling flag, so that interrupt driven
	completion can be used where appropriate.

 * PROBLEM DESCRIPTION:
	Switch disables HBA port, marking the link down.

	In ISP83xx adapter, firmware handles the process of disabling
	pause frame, but according to ER 93859, if reset sequence is
	delayed due to some reason (some functions do not ack the reset,
	which causes a delayed pause frame at firmware level) and due to
	heavy incoming traffic the hardware buffers can fill up, leading to
	pause flood sent to the switch. The pause flood could go beyond the
	switch port pause frame threshold leading to port disable on the
	switch side.

   SOLUTION:
	Disable pause frames in driver when firmware hung is detected.

634.5.7.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	Unable to update ql4xextended_error_logging command line parameter with
	decimal value, which is the typical method used by end-users.
   SOLUTION:
	Updated proc info to accept either hex or decimal values for any command
	line parameter.

 * PROBLEM DESCRIPTION:
	System takes too long to boot.

	During driver initialization, the driver's attempt to request an IRQ
	failed.  The driver then unsuccessfully re-attempts to initialize the
	adapter.  The second attempt delays driver load unnecessarily.
   SOLUTION:
	If request_irqs fails, the driver will immediately fail to initialize
	the adapter. This will prevent useless retries of reviving the adapter
	thus reducing driver load time.

 * PROBLEM DESCRIPTION::
	Memory leak observed in the driver code.

	When a mailbox command times out in case of 4032 (1 Gig iSCSI
	Adapter), core dump memory is dynamically allocated. This memory
	gets freed only the dump is extracted. In cases, where the driver
	gets unloaded before the core dump is extracted, it is currently
	not freed.
   SOLUTION:
	Add code to free up the memory in the remove_adapter context.


 * PROBLEM DESCRIPTION:
	ER97276:  Notifications of Duplicate IP assignment on HBA port are not
	displayed in the log file.
   SOLUTION:
	Added code to display the AEN 8025 (Duplicate IP) notification in the
	driver log file.  The information is already reported to the application.


634.5.6.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	The iSCSI driver floods the vmkernel messages (by repeatedly
	printing the same failure messages) when the device is put to
	FAILED state.
   SOLUTION:
	When the device is in FAILED state, stop monitoring and
	printing firmware health related messages.

 * PROBLEM DESCRIPTION:
	Driver displayed SetDDB mailbox command failure with "4005"
	after driver reinit in the logs.

	The FW gets initialized, but the initiator IP has not yet been
	configured. Then LINK_UP occurs and the driver attempts to
	relogin all devices even though the IP has still not yet been
	configured (THIS IS THE PROBLEM), resulting in multiple relogin
	failures. The initiator IP eventually gets configured and all
	targets subsequently get logged in.
   SOLUTION:
	The following driver updates were made:
	Prevent relogin to a target if the initiator IP is not
	configured.
	In dpc, process get_dhcp_ip() prior to process_aen() to ensure
	that the IP address state is updated prior to attempting to
	process aens.

 * PROBLEM DESCRIPTION:
	iSCSI target becomes in-accessible when large no. of targets
	are connected.

	In certain setups, the total no. os outstanding AENs to be
	handled exceed 256. When that arises, driver drops an event
	which might lead to scenario's where an iSCSI target becomes
	in-accessible.
   SOLUTION:
	Created a dynamic queue between qla4xxx_isr_decode_mailbox
	(MBOX_ASTS_DATABASE_CHANGED) and qla4xxx_process_aen function
	using linux linked list. Memory for each linked list node is
	allocated using a look aside cache using mempool_alloc function
	which would internally use mempool_alloc_slab function. An
	additional mempool of 512 node objects is kept as a fallback
	incase allocation through look aside cache fails. Since the
	queue is dynamic therefore there is not limitation to the
	maximum number of AENs possible.


 * PROBLEM DESCRIPTION:
	Code Review: Code which might cause a PSOD present.

	There is a possibility that qla4xxx_mailbox_command() attempts
	to process a mailbox interrupt as part of stopping the firmware
	during unload and hits a NULL pointer exception as the response
	queue is not valid. Interrupts should be cleared before stopping
	firmware.
   SOLUTION:
	Clear interrupts during driver unload.

 * PROBLEM DESCRIPTION:
	Reset template buffer is not getting freed during driver unload.
   SOLUTION:
	Free reset template buffer on driver unload.

 * PROBLEM DESCRIPTION:
	Firmware state is shown as "Unknown" in driver proc node at
	times.
    SOLUTION:
	The fw_state being a bitmask, instead of '==', we should check
	individual bits. Making appropriate change for bit3 as per
	specs.

634.0.5.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	In a boot from SAN environment through an 83XX, on a PSOD,the core
	dump was not saved.
 SOLUTION:
	Correctly update Coredump handler for coredump processing when
	msix is enabled for 83XX.


634.0.4.0-1vmw
--------------

 * None.

634.0.3.0-1vmw
--------------

 * PROBLEM DESCRIPTION:
	ER91448: Running iSCSI traffic Abort Mbx 15 failed:

	We're getting an underrun because the storage doesn't support
	the command and hence does not return any data.  The firmware
	returns underrun, but the target does not.  Scsi_status is
	CHECK_CONDITION and sense key is ILLEGAL_REQUEST in this case.

	BUG: The driver previously returned DID_BUS_BUSY error code for
	the scsi-ml to retry the command.  After numerous retries, an
	Abort was generated by the VM (guest OS).

	This bug was introduced in driver .42-1vmw when underrun logic
	from the FC/FCoE driver that fixed a data corruption problem
	(seen with underrun and CHECK_CONDITION with RECOVERED_ERROR)
	was ported to the iSCSI driver.

   SOLUTION:
	The underrun logic was updated to return DID_ERROR with
	scsi_status and sense data to the scsi-ml (scsi mid-layer).

	Driver cleanup for RESERVATION_CONFLICT case:
	Since the ESX mid layer handles RESERVATION_CONFLICT in both
	the DID_OK and DID_ERROR case, we really don't need a special
	case for it in the ESX driver either.  Instead, it now defaults
	to the DID_ERROR for this case.

	ESX mid-layer code snippet:
	ESX5.0: cs-esx-50/tags/ESXi50_rebase4_07122011/vmkdrivers/src_9/
	vmklinux_9/linux/drivers/scsi/scsi_error.c
	ESX4.1: cs-esx-41/trunk/vmkdrivers/src_v4/vmklinux26/linux/
	drivers/scsi/scsi_error.c

	Function scsi_decide_disposition():
	switch (host_byte(scmd->result)) {
	case DID_OK:
		/*
		 * looks good.  drop through, and check the next byte.
		 */
		break;
	case DID_ERROR:
		if (msg_byte(scmd->result) == COMMAND_COMPLETE &&
				status_byte(scmd->result) == RESERVATION_CONFLICT)
			/*
			 * execute reservation conflict processing code
			 * lower down
			 */
			break;
	}

	switch (status_byte(scmd->result)) {
	case RESERVATION_CONFLICT:
	sdev_printk(KERN_INFO, scmd->device,
			"reservation conflict\n");
	return SUCCESS; /* causes immediate i/o error */
	}

	Driver cleanup for CHECK_CONDITION w/ RECOVERED_ERROR case:
	Updated driver to default to DID_ERROR for this case, instead
	of returning DID_BUS_BUSY. Either return value would prevent
	data corruption, but returning DID_ERROR will result in more
	simplified code.A return value of DID_OK would result in data
	corruption.

	Added support for TASK_SET_FULL and BUSY cases:
	Updated driver to return DID_OK w/ status for these cases as
	they are considered task not completed and needs immediate
	retry.  The scsi mid layer retries this command immediately
	also considers residual count. The retries will be at
	the head of the queue which help in faster recovery and avoids
	unnecessary timeout.

634.0.2.0-1vmw
--------------

 * Added fixes to stabilize 83XX code.

634.0.1.0-1vmw & Previous Releases
----------------------------------

 * Fix display of wrong proc info for IPv6 targets. [ER 67370]
 * Fixed PSOD with endless AENs. [PR 484269]
 * Fix issue where abort task mgmt cmds were sent to
   the wrong target.
 * Fixed issue related to incorrect handling of abort task mbx cmd.
 * Addressed PSOD issue related to long term link up/down.
 * Fix driver to handle disable/enable intrs mailbox cmd correctly
   for the CNA.
 * Fix PSOD during core dump on iSCSI SAN LUN.
 * Fix loopback test failure on the 2nd port.
 * Fix issue where iSCSI BFS displays same target device twice.
 * Fix the driver to use link up time in device_ready.
 * Perform context resets instead of chip reset for 82XX for
   context issues.
 * Fix PSOD caused during failover testing. [ER 78894]
 * Fix formatting issue related to target info display. [ER 79100]
 * Fix the issue where the driver would not correctly recover in
   case of intermittent 4032 errors.
 * Mask required bits of add_fw_options during initialization.
 * Fix issue with sending return mailbox status during loopback test.
 * Correct L1 cache data capture during minidump.
 * Updated beaconing changes for new API and enabled minidump by default
 * Correctly return AEN payload to the application.
 * Correctly honour reference count during aborting commands.
 * Fix system reboot issue while running Peg Halt tests. [ER 88647]
 * Print Debug info about IPE detection.
 * Fix ddb bit flip issue leading to Data Corruption.
 * Handle data underrun properly.
 * Honour iscsi Flags while returning completion status to mid-layer.
 * Coredump interrupt handler improvement


2. Known Issues

 * None.


7. Notices

Information furnished in this document is believed to be accurate and
reliable. However, QLogic Corporation assumes no responsibility for
its use, nor for any infringements of patents or other rights of
third parties which may result from its use. QLogic Corporation
reserves the right to change product specifications at any time
without notice. Applications described in this document for any of
these products are only for illustrative purposes. QLogic Corporation
makes no representation nor warranty that such applications are
suitable for the specified use without further testing or
modification. QLogic Corporation assumes no responsibility for any
errors that may appear in this document.


4. Contacting Support

   For further assistance, contact QLogic Technical Support at:
   http://support.qlogic.com


Trademarks

Accelera, Accelerating Cluster Performance, InfiniCon Systems,
InfiniNIC, InfiniPath, InfiniView, QLA, QLogic, the QLogic logo,
ReadyPath, SANdoctor, SANsurfer, and SilverStorm are registered
trademarks of QLogic Corporation. All other brand and product names
are trademarks or registered trademarks of their respective owners.


(c) Copyright 2015. All rights reserved worldwide. QLogic and the
QLogic logo are registered trademarks of QLogic Corporation.
All other brand and product names are trademarks or registered
trademarks of their respective owners.
