#7.0

1. Driver name: smartpqi

2. Driver version: 70.4054.2.118-1OEM.700.1.0.15843807

3. Compatible ESX version(s): ESXi 7.0


#Fixes

1.	Fixed an issue where drive is identified as new device after reinserting drive in a different slot.
	
	Symptom: Drive will be identified as new device after reinserting drive in a different slot.
	Root cause: When drive is reinserted in a different slot, scsi3addr of drive changes with respect
	to slot. As a result, drive is detected as a new device.
	Fix: Compare only the World Wide ID of the drive to find whether the hot-added device is present
	in the removed device list and, if present, update scsi3addr of the corresponding device entry in
	the device list with the new scsi3addr of the hot-added drive.
	Note: Detecting the same SATA drive moved between bays of the same
	controller only works if the SATA WWN Unique ID feature is enabled in the driver
	module parameters.
	Risk: Medium

2.	Fixed an issue where system panics during array deletion.
	
	Symptom: System panics during array deletion test.
	Root cause: When ESXi destroys the device path, the driver sets a flag to indicate that the OS
	has already freed the scsi path, and driver can now safely free the device memory through the
	device discovery path. When the OS later re-added the path, the driver had not cleared the flag.
	When the same device has been removed from the system, the driver discovery path gets
	triggered and freed the path since the flag was set. After that, the OS destroys the path again,
	which resulted in double free and PSOD.
	Fix: Clear the flag which indicates OS has freed the scsi path.
	Risk: Medium

3.	Fixed an issue where system crashes when deleting logical volumes.
	
	Symptom: System crashes while deleting logical volumes.
	Root cause: PSOD occurred due to the lack of heartbeat for host CPUs; that is some of the
	CPUs were doing busy wait from the driver, and none of the other threads get the CPU. Decision
	of SCSI IO or not was being done outside the response processing loop. As a result, non-SCSI
	IO is treated as a SCSI IO completion, and 0 counter value may get a negative value. Thus, the
	IO counter value will never return to 0. During device removal, the driver enters a busy wait for
	the IO counter to become 0. This leads to a long busy wait and ESXi issues PSOD due to the
	lack of CPU heartbeat update.
	Fix: Changed busy wait to sleep and ensure that "scsi IO or not" is done in each response.
	Risk: Medium

4.	Renaming the component vendor name from Microsemi to Microchip for Esxi 7.0
   
	DETAIL : While submitting the smartpqi driver for certification, VMware is
	not accepting it with the vendor name "Microsemi" for 7.0 component.
	VMware expects the vendor name to be "Microchip" to match with the inbox 
	component name. 
	
5.	Fixed an issue where physical drives showing higher latency.
	
	Symptom: vSAN logs showing higher latency for physical disks
	Root Cause: Driver get the queue depth value from the firmware for each target.
	If the firmware doesn’t give a valid queue depth value for a target, driver is
	supposed to set the queue depth to a default values (1014 for LD, 27 for PD).
	But for all physical devices, current  driver reset the queue depth to
	maximum queue depth (1014) irrespective of whether firmware gave a valid QD or not.
	Fix: Add proper check while setting the device queue depth.
	Risk: Low
	
6.	Fixed an issue where driver produces too much logging

	Symptom: Driver is logging many messages and statistics that were
	intended only for debugging . 
	Fix: Driver's default logging level was modified.
	Risk: Low
	
7.  Fixed an issue where AIO performance counters are too verbose.

	Symptom: Messages from AIO performance counters are sent to vmkernel.log
	every 5 minutes. Each message contains multiple lines for each
	supported RAID type.
	Fix: Print these messages only when a certain controller flag is
    changed from disabled to enabled. Add a module parameter to allow 
	changing the state of the controller flag.
	Risk: Low
	
8.	Fixed an issue where verbose logging from error handlers

	Symptom: Verbose messaging from driver is flooding vmkernel.log.
	In some cases, this amount of logging can cause log congestion.
	Fix: Added controller flag and compile-time option to
	turn off the unwanted messaging.
	Risk: Low
	





