PR ID/CR ID:	LSIP200196899
Headline:	Allow ONLY Catera approved FW to be flashed on Catera Brand controllers
Description:	This functionality should be blocked at the FW level. If FW running on an Catera Brand controllers detects FW being flashed is not releases for Catera Brand controllers it should return an error and add an event "Firmware not supported on Catera Brand controllers". This functionality is required for MR and iMR FW stack and work on 1078,liberator and Tbolt code.
State:		Implementation

IMP ID/CO ID:	LSIP200200333
Headline:	(auto4comp FW_SAS_LSI) Allow ONLY Catera approved FW to be flashed on Catera Brand controllers
Description:	**** This IR is for the 10M09 Liberator FW build **** Auto Create from PR LSIP200196899. This functionality should be blocked at the FW level. If FW running on an Catera Brand controllers detects FW being flashed is not releases for Catera Brand controllers it should return an error and add an event "Firmware not supported on Catera Brand controllers". This functionality is required for MR and iMR FW stack and work on 1078,liberator and Tbolt code.
State:	Delivered
Associated Task:	LSIP200209348
Task References:	LSIP200196899

DFCT ID:	LSIP200209349
Headline:	Enable PCI capability Bit for VPD exsupport.
Description:	Oracle requestes the Enable PCI capability Bit for VPD support.
Steps to Reproduce:	lsipci should expose with PCI VPD,which was previously disabled for Oracle alone.
Resolution:	removed the disalbing PCI capability Bit for VPD exsupport.
Fix Impact:	Low
External Behavior Change:	No
Suggested Testing:	with "lsipci " command in linux we should see the VPD page
Child Tasks:	LSIP200209351

DFCT ID:	LSIP200200459
Customer DFCT No:	7092301
Headline:	MegaCli prematurely returns exit 0x0 status on drive firmware flash
Description:	CLI completes the command after successful completion of last WRITE BUFFER CDB to the drive & not after flashing the drive or cache restoration. SAS/SATA/SEP devices would update firmware based on respective vendor specific implementation. Same is corrected below in red. 1)     CLI initiates Drive firmware flash. 2)     FW will a.     Command block is acquired. b.     Flush all Controller cache to drive, and then allocate top couple cache memory of MBs for Drive firmware image. The rest of the cache is re-initialized as drive cache. 3)     Drive firmware download happens by multiple WRITE BUFFER commands for the drive firmware image. 4)     After last WRITE buffer command sent to the drive & completed by drive, CLI command is completed. 5)     After wait for few seconds specified by the application, SCSI inquiry is sent by the drive. 6)     Command block is acquired after a successful completion of SCSI Inquiry to drive. And the cache is restored to the original state. 7)     During the whole steps above OS/host IO commands are allowed to be sent to controller & driver. Due to power cycle, cache could become dirty. 8)     But since we are doing a power cycle at 4, next boot up firmware would come with dirty cache. Cache structure validation is part of boot up sequence. 9)     Cache validation fails as the assumed location of cache header is now has stale data by the drive firmware image, leading to firmware hit the montask. I believe proper implementation would for Oracle to issue a scsi inquiry after drive firmware flashing and verify if the firmware upgrade is successfully. Checking the return code from CLI will only indicate whether Write buffer is successfully sent to the drive firmware, but not whether image is flashed on to the disk. But we had attached test firmware that would wait till firmware flush happens. This version is not test as we don?t have Oracle drive to verify and most importantly whether take path for release code depends up on internal review,etc . I believe download application verifying the flash upgrades version seems to be the right path.
Steps to Reproduce:	NA
Resolution:	Delay the completion of last write buffer till the fwdownload is complete (fwdownload complete means meaning wait after last WB command, issue SCSI inq, free the memory , issue PD sync cache)
Customer Defect Track No:	7092301
Fix Impact:	Medium
External Behavior Change:	No
Suggested Testing:	should be able flash the drive fw image back to back without any waiting.
Child Tasks:	LSIP200209213

DFCT ID:	LSIP200209376
Headline:	HWR: 10M09: OEM requests ibbu i2c communication retries to be displayed in fw log
Description:	OEM requests ibbu i2c communication retries to be displayed in fw log. A counter variable should be displayed whenenver fw must do retries to establish battery communication. Customer does not want to fill the log up with unecessary prints. Thus, they do not want prints displayed if the battery is not present.
Steps to Reproduce:	View fw log for cases if battery is connected or not connected. There should not be prints when battery is not connected. If battery is connected, then should only be prints if fw had to do retries to establish communication. May have to do something like temparily disconnect the battery connector to simulate this.
Resolution:	FW is displaying accumulated Gas gauge retry counter for specific OEM If no BBU is connected there should be no prints of BBU communication retries. The retry counter gets Reset once Gas gauge communication gets successful.
Fix Impact:	Cosmetic
External Behavior Change:	No
Suggested Testing:	For specific OEM retry counter should be dispalyed with the FW.
Child Tasks:	LSIP200209442

DFCT ID:	LSIP200209385
Headline:	Intermittent RAID key failure during power-on
Description:	Intermittent RAID key failure during power-on causes MFC parameters to be 0
Steps to Reproduce:	This problem is seen on specific batch of Raid Keys at a specific temperature (20 degrees Celcius). Test jig that grounds data line of the RAID key is used to simulate the problem. Rebooting using this test jig causes the problem.
Resolution:	If Raid key authorization fails before succeeding then FW will again execute Raid key initialization
Fix Impact:	Medium
External Behavior Change:	Yes
Suggested Testing:	Reboot controller with Raid key data line grounded for a short time. Controller should read Raid key parameters correctly.
Child Tasks:	LSIP200209363

DFCT ID:	LSIP200196885
Customer DFCT No:	XB065954
Headline:	(XB065954) TDA 5015 Batteries Not Charging
Description:	Relearn not starting.
Steps to Reproduce:	Jeff Inskeep has reproduced this issue in his lab.
Resolution:	The problem at the outset is, some batteries(iBBU07) are not charging at all (the asking current is very High, but the battery is not charging), and this state is called Charge Lock-up state. In this state, the combination of Gas gauge and Charger will never charge a battery, as charger gets into locked up state. There are two possible causes for the lockup state. One of them is the “battery overcharged state” that IBM experienced. The second one can result if there are calibration errors in the gas gauge and/or out of spec low charging voltage from the charger, and this is hardware failure. Firmware needs to categorize the charge lock-up state(the asking current is very High, but the battery is not charging) to either of these. The first case is, when Battery Voltage is more than Charge Rail voltage. Solution to get out of this failure state is, discharge the battery until battery Voltage gets to less than 3.9 Volts and then initiate a relearn. The second case is when the Battery Voltage < ChargeVoltage - 2*currentTaperQualVoltage . This is a battery hardware failure and hence that battery needs to be declared bad.
Customer Defect Track No:	XB065954
Fix Impact:	Low
External Behavior Change:	No
Suggested Testing:	The released FW should fix the charge Lock-up state problem
Child Tasks:	LSIP200209374

DFCT ID:	LSIP200209455
Headline:	(CL LSIP200188135) Data corruption found while running the IO on degraded R5 VDs with 32 drives.
Description:	Data corruption hit while running the IO on 8 R5 VDs with different stripe sixe from 8KB to 1MB. --------------------------------------- Operating System: RHEL 5U5_x64 Driver: 6.08 Controller: LSI MegaRAID SAS 9360-8i APP: 3.60.05-1337 MSM: 11.08-01 MegaCli: 8.02.16 Enclosure: Camden, Ebbets ESM Firmware: 0319 Drives: SAS
Steps to Reproduce:	1) Create 8 LDs RAID5 with 32drives with multiple stripe sizes starting from 8Kb through 1Mb but create one LD with greater than 2.5TB plus size. 2) Start IO. 3) Let I/O runs for 30 minutes then pull out 1 drive from R5 and wait for 30 minutes to reinsert the pulled out drive to start rebuild to 100% After 1hr DC hit. Attached firmware logs and chaos log.
Resolution:	In case of un-recoverable host write case (due medium errors we are not puncturing the parity)
Fix Impact:	Low
External Behavior Change:	No
Suggested Testing:	please see recreation steps
Child Tasks:	LSIP200209375

DFCT ID:	LSIP200209329
Headline:	FoD features will not activate or deactivate
Description:	FoD features will not activate or deactivate After installing FoD keys for R5 and SED, the features do not get enabled.
Version of Bug Reported:	20.10.1-0058
Steps to Reproduce:	Boot system with Falcon controller Install FoD keys for R5 and SED features Reboot server and notice features do not become enabled
Resolution:	Enable boot time PFK update flag in PFK feature set DCMD
Fix Impact:	Medium
External Behavior Change:	Yes
Suggested Testing:	Boot controller with FOD enabled
Child Tasks:	LSIP200209505

Task ID:	LSIP200209363
Headline:	209363 Reinitialize RAID Key parameters if authentication fails before succeeding
Description:	In function EepromPerformRaidKeyAuthorization(); if Raid key authorization fails then FW will again execute function EepromInit()
State:	Delivered
Change Set Files:
References:	LSIP200209385(DFCT)

Task ID:	LSIP200209442
Headline:	209442 Displaying Gas Gauge Retry Counter for specific OEM
Description:	Displaying Gas Gauge Retry Counter for specific OEM
State:	Delivered
Change Set Files:
References:	LSIP200209376(DFCT)

Task ID:	LSIP200209351
Headline:	209351 (LSIP200209349) Enable PCI capability Bit for VPD exsupport.
Description:	to change the previous disabled.
State:	Delivered
Change Set Files:
References:	LSIP200209349(DFCT)

Task ID:	LSIP200209375
Headline:	209375 Data corruption found while running the IO on degraded R5 VDs with 32 drives.
Description:	Data corruption found while running the IO on degraded R5 VDs with 32 drives.
State:	Delivered
Change Set Files:
References:	LSIP200209455(DFCT)

Task ID:	LSIP200209348
Headline:	209348 (LSIP200200335) (LSIP200196899) Allow ONLY Catera approved FW to be flashed on Catera Brand controllers
Description:	Block flashing of new app.rom wtihout proper stamping of new image with pci ids.
State:	Delivered
Change Set Files:
References:	LSIP200200333(CO)

Task ID:	LSIP200209213
Headline:	209213 (LSIP200200459) MegaCli prematurely returns exit 0x0 status on drive firmware flash
Description:	Delay the completion of last write buffer till the fwdownload is complete (fwdownload complete means meaning wait after last WB command, issue SCSI inq, free the memory , issue PD sync cache)
State:	Delivered
Change Set Files:
References:	LSIP200200459(DFCT)

Task ID:	LSIP200199983
Headline:	199983 Release Task 09/19/2011
Description:	Release Task
State:	Active
Change Set Files:
References:

Task ID:	LSIP200209557
Headline:	209557 Release Task 10/05/2011
Description:	Release Task
State:	Active
Change Set Files:
References:

Task ID:	LSIP200209505
Headline:	209505 Enable boot time PFK update flag
Description:	Enable boot time PFK update flag in PFK feature set DCMD
State:	Delivered
Change Set Files:
References:	LSIP200209329(DFCT)

Task ID:	LSIP200209374
Headline:	209374 Fixes for iBBU07 Cherger Lock-up condition.
Description:	some batteries(iBBU07) are not charging at all (the asking current is very High, but the battery is not charging), and this state is called Charge Lock-up state. In this state, the combination of Gas gauge and Charger will never charge a battery, as charger gets into locked up state. There are two possible causes for the lockup state. One of them is the “battery overcharged state” that IBM experienced. The second one can result if there are calibration errors in the gas gauge and/or out of spec low charging voltage from the charger, and this is hardware failure. Firmware needs to categorize the charge lock-up state(the asking current is very High, but the battery is not charging) to either of these. The first case is, when Battery Voltage is more than Charge Rail voltage. Solution to get out of this failure state is, discharge the battery until battery Voltage gets to less than 3.9 Volts and then initiate a relearn. The second case is when the Battery Voltage < ChargeVoltage - 2*currentTaperQualVoltage . This is a battery hardware failure and hence that battery needs to be declared bad
State:	Delivered
Change Set Files:
References:	LSIP200196885(DFCT)

Task ID:	LSIP200209439
Title:	deliver rajeshpr_FW_SAS_10M09_Dev_Main_2 on 20111003.105844.

Task ID:	LSIP200200128
Title:	rebase FW_SAS_10M09_Dev_Main on 20110920.114634.

Task ID:	LSIP200147843
Title:	rebase jayantd_FW_SAS_10M09_Dev_Main on 20110426.174832.

Task ID:	LSIP200209212
Title:	rebase rajeshpr_FW_SAS_10M09_Dev_Main_2 on 20110927.164026.

Task ID:	LSIP200200143
Title:	rebase snanduri_FW_SAS_10M09_Dev_Main on 20110920.171044.

Task ID:	LSIP200200129
Title:	rebase jayantd_FW_SAS_10M09_Dev_Main on 20110920.115050.

Task ID:	LSIP200209444
Title:	deliver snanduri_FW_SAS_10M09_Dev_Main on 20111003.123850.

Task ID:	LSIP200209361
Title:	rebase vasum_FW_SAS_10M09_Dev_Main on 20110930.114438.

Task ID:	LSIP200209507
Title:	deliver jayantd_FW_SAS_10M09_Dev_Main on 20111004.174215.

Task ID:	LSIP200209496
Title:	deliver vasum_FW_SAS_10M09_Dev_Main on 20111004.140140.

Task ID:	LSIP200209456
Title:	deliver jayantd_FW_SAS_10M09_Dev_Main on 20111003.183652.

Task ID:	LSIP200209508
Title:	deliver FW_SAS_10M09_Dev_Main on 20111004.180748.