DFCT ID:	LSID100066174
Headline:	Unable to reliably flash dasiy chained encl.
Description:	flashing enclosures through a 8480E SAS card with varied configurations is unreliable. Flashing 1 is fine. Flashing 4 or 5 may or may not pass. The enclosure being populated or unpopulated does not seem to matter
Version of Bug Reported:	211
Steps to Reproduce:	The utility was provided by OEM I have attached the ISO image to this defect. The Encl need to be set to a particular OEM. Create a CD form image and then boot from CD and flash up and down.
Child Tasks:	LSID100066810

Task ID:	LSID100066810
Headline:	Release MPT 01.18.74
Description:	MPT 01.18.74 code release
State:	Completed
Change Set Files:	0
References:	LSID100066174(DFCT)

CO ID:	LSID100066961
Headline:	CR_Ref# LSID100066535: Temp diff message
Description:	CR_Ref# LSID100066535: Temp diff message
State:	Implement
Associated Task:	LSID100067231

DFCT ID:	LSID100066439
Headline:	SAS ZCR BBU never charges after reconditioning cycle until after a reboot.
Description:	During tests for the ZCR Firmware package 5.1.1-0039 (embedded Firmware 1.03.01-0212) we see a serious problem whenever a new BBU is installed. The brand new installed BBU from stock is starting a charge after power-on. That is ok so far. About 6 hours later the charge is finished and immediately the pending recalibration cycle is starting with a discharge. That is also ok. After the discharge is done, about 2,5 hours later the message "BBU relearn complete" appears. But now should start a BBU-charge. This charge is missing. (Wait for charge over the weekend 48 hours). Only when a reboot performed the charge is starting then. If I later start a manual recalibration (relearn) cycle it works. It works means, that after the message "BBU relearn completed" a charge automatically started without a reboot. We have seen that behavior on 3 different systems and different operating systems (see notes section) Steps to reproduce: install a brand new BBU on ZCR-SAS 8300XLP controller . RAID configuration is not important (R5 with 3HDs 1LD write back) boot into OS > BBU charge automatically start after 5-10min. after about 6 hours> charge complete >BBU relearn in progress >BBU discharging after about 2,5 hours >relearn completed now > missing charge Attached is a screenshot from the OEM Management tool. You can see the messages and a serial trace. <<TX200S3_ZCR_BBU.txt.txt>> <<BBU_relearn.jpg>>
Version of Bug Reported:	1.03.01-0212
Version of Bug Fixed:	1.03.31-0229
Steps to Reproduce:	Steps to reproduce: install a brand new BBU on ZCR-SAS 8300XLP controller . RAID configuration is not important (R5 with 3HDs 1LD write back) boot into OS > BBU charge automatically start after 5-10min. after about 6 hours> charge complete >BBU relearn in progress >BBU discharging after about 2,5 hours >relearn completed now > missing charge
Resolution:	Fixed
Resolution Description:	Problem: ========= On a new battery in SAS ZCR, after charging, the auto learning starts. When auto learning stops, the battery never starts charging, and is rendered useless during that boot. It gets charged in the next boot. Root Cause: ============ The MegaRaid FW assumes that if a battery is fast charged and brought to full voltage, it will maintain that voltage with trickle charge and will not suddenly go to a very low voltage while it monitors the charging. If a battery goes to a low voltage after it has completed a fast charge cycle, it will declare the battery as bad and will not use it. Hence when a fast charge completes, the FW sets a variable to indicate fast charge done, and on a low voltage checks that variable. However, during a learning cycle, the charging logic is disabled and the FW starts a discharging cycle. Hence on completion of the learning, the battery goes to a very low voltage of the discharged state, and the FW restarts the charging logic. Unfortunately, since the FW remembers that it has already completed a fast charge in that boot, using the above logic, it will declare the battery as bad and will not use it. On reboot, the fast charge variable is reset, and hence the FW again starts charging t! he battery as usual. Fix: ==== The fix is simply to reset the fast charge done variable in the FW when it starts discharging the battery during learning cycle. This will ensure the FW will restart the fast charge after learning is complete.
Customer List:	OEM -- OEM
Child Tasks:	LSID100067218

DFCT ID:	LSID100066879
Customer DFCT No:	23332225
Headline:	The 1068 is asserting INTA/ and ALT_INTA/ together when he is in ZCR mode
Description:	If ZCR_EN\ is active, then according to the Technical Manual (LSISAS1068 PCI-X to 8-Port Serial Attached SCSI/SATA Controller), no activity will be driven by the 1068 on the INTA\ pin. The 1068 is asserting INTA/ and ALT_INTA/ together when he is in ZCR mode. The INTA/ is a shared interrupt and will be used for slot 2 where a LAN card is installed. The LAN card feels not to be responsible for the request issued by the 1068. But from the OS perspective the LAN card does not serve all the INTA/ and the OS is disabling the LAN card.
Version of Bug Reported:	1.03.00.0212
Version of Bug Fixed:	1.03.31-0229
Steps to Reproduce:	This must be done on specific OEM system (see notes). Install ZCR controller Install LAN controller in Slot 2 next to ZCR controller Install Linux Run heavy I/O on the ZCR controller while connected to the lan. Eventually Linux will disable the controller with an error message.
Resolution:	Fixed
Resolution Description:	The 1068 ZCR is asserting INTA/ and ALT_INTA/ together when he is in ZCR mode. The INTA/ is a shared interrupt and will be used for slot 2 where a LAN card is installed. The LAN card feels not to be responsible for the request issued by the 1068. But from the OS perspective the LAN card does not serve all the INTA/ and the OS is disabling the LAN card. To fix this we need to set the MPI_HOST_INTERRUPT_MASK to 0x201 at boot, instead of 0x01 as done with non-ZCR cards.
Customer Defect Track No:	23332225
Customer List:	OEM -- OEM
Child Tasks:	LSID100067220

DFCT ID:	LSID100065270
Headline:	"Unstable Enclousure" message seen in Windows
Description:	Customer is seeing a Windows "Unstable Enclosure" message in Windows when they flash the enclousre FW. This enclosure FW flash process takes approx 30 seconds. It seems like our 8480E would time out or disreagard the enclosure when enclosure Fw is flashed. The OS gives this error is an AEN which comes from the FW: EventID is MR_EVT_ENCL_UNSTABLE. Why is this Event sent out by FW? Looking at serial debug log, there are also Data Aborts seen when SEP is rebooted.
Version of Bug Reported:	0910
Steps to Reproduce:	Connect SAS 8480E/8408E SAS MegaRAID controller to Xyratex backplane. FW is xx.0190. Boot to Windows. Flash Xyratex backplane FW while windows is running. Unstable Enclosure message should appear and all communication with enclosure is lost. MSM will no longer see the enclosure as well. A subsequest reboot will bring then recognize the enclosure and things are back to normal.
Resolution:	Fixed
Resolution Description:	fixed.
Customer List:	LSI -- LSI
Child Tasks:	LSID100067024

DFCT ID:	LSID100066883
Headline:	SAS ZCR relearn should hold off until fast charge is complete
Description:	I think to start a relearn the battery must be fully charged before. It makes less sense to start a relearn for a battery which is in fast charge at the moment. But when user is starting a relearn manually FW starts immediately a discharge independent of the battery state. I think the right behavior would be to hold the relearn in pending state until the battery is fully charged.
Version of Bug Reported:	1.03.00-0211
Version of Bug Fixed:	1.03.31-0229
Steps to Reproduce:	Plug in ZCR controller with Battery While battery is fast charging, start a relearn cycle. Discharge will start right away.
Resolution:	Fixed
Resolution Description:	Fix: Use the same code in manual learning code as auto learning code to check if the charging is complete before starting to learn, otherwise changes state and waits for charging to complete before starting the learn cycle. This ensures that it learns the comple capacity of the battery, instead of learning the current partial charge capacity.
Customer List:	OEM -- OEM
Child Tasks:	LSID100067218

Task ID:	LSID100067221
Headline:	Fix debug code and serial dumping
Description:	1. Fix serial tty dumping in case of host timeout where dump of WRITE command was not printing due to a C operator precedence error. 2. The Fw use to hang in serial port routines if Fw enters monTask when nobody unlocks the serial port by typing "123" before. This is fixed.
State:	Completed
Change Set Files:	0
References:

Task ID:	LSID100067245
Headline:	Maintenance version 3
Description:	Maintenance version change to 3
State:	Completed
Change Set Files:	0
References:

Task ID:	LSID100067220
Headline:	Fix ZCR asserting INTA and failing externa NW card
Description:	The 1068 ZCR is asserting INTA/ and ALT_INTA/ together when he is in ZCR mode. The INTA/ is a shared interrupt and will be used for slot 2 where a LAN card is installed. The LAN card feels not to be responsible for the request issued by the 1068. But from the OS perspective the LAN card does not serve all the INTA/ and the OS is disabling the LAN card. To fix this we need to set the MPI_HOST_INTERRUPT_MASK to 0x201 at boot, instead of 0x01 as done with non-ZCR cards.
State:	Completed
Change Set Files:	0
References:	LSID100066879(DFCT)

Task ID:	LSID100067231
Headline:	fix 66535
Description:	fix 66535
State:	Completed
Change Set Files:	0
References:	LSID100066961(CO)

Task ID:	LSID100067251
Headline:	FW_SAS Release Version: 1.03.31-0229
Description:	FW_SAS Release Version: 1.03.31-0229
State:	Completed
Change Set Files:	0
References:

Task ID:	LSID100066685
Headline:	Add PCIId.h File and use it to isolate vendor id
Description:	Add the file PCIID.h from Ocoone stream and use it to clean up all vendor id, sub vendor id and sub device id hardcoded in all files. Also remove any reference to vendor name from other source files This will help delivering code to Ocoone and avoid conflicts.
State:	Completed
Change Set Files:	0
References:

Task ID:	LSID100067024
Headline:	Handle Unstable Enclosure
Description:	Reference defect 65270 Unstable Enclosure
State:	Open
Change Set Files:	0
References:	LSID100065270(DFCT)

Task ID:	LSID100067218
Headline:	Fix no charge after learn & start learn immediate
Description:	Two Fixes: 1. LSID100066439: SAS ZCR BBU never charges after reconditioning cycle until after a reboot. Problem: ========= On a new battery in SAS ZCR, after charging, the auto learning starts. When auto learning stops, the battery never starts charging, and is rendered useless during that boot. It gets charged in the next boot. Root Cause: ============ The MegaRaid FW assumes that if a battery is fast charged and brought to full voltage, it will maintain that voltage with trickle charge and will not suddenly go to a very low voltage while it monitors the charging. If a battery goes to a low voltage after it has completed a fast charge cycle, it will declare the battery as bad and will not use it. Hence when a fast charge completes, the FW sets a variable to indicate fast charge done, and on a low voltage checks that variable. However, during a learning cycle, the charging logic is disabled and the FW starts a discharging cycle. Hence on completion of the learning, the battery goes to a very low voltage of the discharged state, and the FW restarts the charging logic. Unfortunately, since the FW remembers that it has already completed a fast charge in that boot, using the above logic, it will declare the battery as bad and will not use it. On reboot, the fast charge variable is reset, and hence the FW again starts charging the battery as usual. Fix: ==== The fix is simply to reset the fast charge done variable in the FW when it starts discharging the battery during learning cycle. This will ensure the FW will restart the fast charge after learning is complete. 2. LSID100066883: SAS ZCR relearn should hold off until fast charge is complete. Fix: Use the same code in manual learning code as auto learning code to check if the charging is complete before starting to learn, otherwise changes state and waits for charging to complete before starting the learn cycle. This ensures that it learns the comple capacity of the battery, instead of learning the current partial charge capacity.
State:	Completed
Change Set Files:	0
References:	LSID100066439(DFCT)     LSID100066883(DFCT)

Task ID:	LSID100067248
Headline:	FW_SAS Release Version: 1.03.30-0228
Description:	FW_SAS Release Version: 1.03.30-0228
State:	Completed
Change Set Files:	0
References:

Task ID:	LSID100066818
Headline:	Release MPT 01.18.74 for B1
Description:	MPT 01.18.74 code release
State:	Completed
Change Set Files:	0
References: