PR ID/CR ID:	LSIP200055359
Headline:	RHEL 5 U5 support for MegaRAID SWR5 products
Description:	Add RHEL 5 Update 5 kernel support of megaSR Linux drivers. 2/9/10 - Beta 1 3/17/10 - RC 3/30/10 - GA
State:		Ready4Impl

IMP ID/CO ID:	LSIP200065286
Headline:	(auto4comp SWR_Driver_R5_Univ) RHEL 5 U5 support for MegaRAID SWR5 products
Description:	Auto Create from PR LSIP200055359. Add RHEL 5 Update 5 kernel support of megaSR Linux drivers. 2/9/10 - Beta 1 3/17/10 - RC 3/30/10 - GA
State:	Delivered
Associated Task:	LSIP200019911
Task References:	LSIP200055359

DFCT ID:	LSIP200064987
Headline:	23111 62209 55062 Adding support for SSD in SWR
Description:	23111 62209 55062 Adding support for SSD in SWR
Steps to Reproduce:	23111 62209 55062 Adding support for SSD in SWR
Resolution:	For SSD devices connected to MegaSR, management applications (supporting SSD), should show the device as an SSD rather than SATA.
Fix Impact:	Low
External Behavior Change:	Yes
Suggested Testing:	For SSD devices connected to MegaSR, management applications (supporting SSD), should show the device as an SSD rather than SATA.
Child Tasks:	LSIP200019907

DFCT ID:	LSIP200049946
Headline:	With MegaSR system does not indicate missing drive when pulled from configuration
Description:	With FTS BIOS version (v.0.99S.2759), the system does not notice any more, when I pull out a configured hard disk. 1. The red LED stays dark 2. CTRL-M sporadically does not show a failed disk -- it is still displayed as "online" even hours after pulling it out. 3. The driver only notices that a disk is missing when writing data on the virtual disk that the missing disk is part of.
Steps to Reproduce:	FTS reproduced our issue 6 times today, in CTRL-M. · One time on a TX150 S7. · 5 times on a TX150 S6 (an ICH9 machine). (I was mainly concentrating on that machine today, therefore 5 times vs. 1 time on the S7). Configuration: All SATA slots are populated and contain unconfigured disks. TX150 S6: OPROM A.09.06171059R TX150 S7: OPROM A.09.07211059R Step-by-step: Boot the machine Enter CTRL-M Create a RAID1 using PD0 and PD1 Create a RAID1 using PD2 and PD3 Wait 15 - 30 seconds Pull out PD3. => Red LED of PD1 stays dark for more than 5 minutes, probably for days. => CTRL-M does not notice that the PD3 is missing for more than 5 minutes, probably for days. Write cache setting does not seem to be relevant in this scenario; I went with default values this time (WC=0). Still cannot replicate this 100%, but can in more than 50% of the cases.
Resolution:	This defect was reported by FTS for a system which did not raise an interrupt for drive removal notification. The future commands would timeout for this device. To fix the timeouts and have proper notification of drive removal, we now look for 2 back-to-back timout on a device. When such a timeout condition is detected, driver would remove the device. To test this, you'll need the exact setup used by customer. On that setup, interrupt is not generated for drive removal.
Fix Impact:	Medium
External Behavior Change:	Yes
Suggested Testing:	This defect was reported by FTS for a system which did not raise an interrupt for drive removal notification. The future commands would timeout for this device. To fix the timeouts and have proper notification of drive removal, we now look for 2 back-to-back timout on a device. When such a timeout condition is detected, driver would remove the device. To test this, you'll need the exact setup used by customer. On that setup, interrupt is not generated for drive removal.
Child Tasks:	LSIP200019903

DFCT ID:	LSIP200064527
Headline:	SWR uses wrong macro definition for CDB6 READ/WRITE commands
Description:	Code in Problem #define GET_START_BLOCK6(cdb) \ (uint64_t)( \ (uint32_t)(cdb[3]) | \ (uint32_t)(cdb[2] << 8) \ ) #define SET_START_BLOCK6(cdb, blk_num) \ cdb[3] = (uint8_t)(blk_num & 0xff); \ cdb[2] = (uint8_t)((blk_num >> 8) & 0xff); \ Modified Code #define GET_START_BLOCK6(cdb) \ (U64)( \ (U32)(cdb[3]) | \ (U32)(cdb[2] << 8) | \ (U32)((cmd[1] & 0x1f) << 16)\ ) #define SET_START_BLOCK6(cdb, blk_num) \ cdb[3] = (U8)(blk_num & 0xff); \ cdb[2] = (U8)((blk_num >> 8) & 0xff); \ cdb[1] &= 0xE0; \ cdb[1] |= (U8)((blk_num >> 16) & 0x1f);\
Steps to Reproduce:	Code in Problem #define GET_START_BLOCK6(cdb) \ (uint64_t)( \ (uint32_t)(cdb[3]) | \ (uint32_t)(cdb[2] << 8) \ ) #define SET_START_BLOCK6(cdb, blk_num) \ cdb[3] = (uint8_t)(blk_num & 0xff); \ cdb[2] = (uint8_t)((blk_num >> 8) & 0xff); \ Modified Code #define GET_START_BLOCK6(cdb) \ (U64)( \ (U32)(cdb[3]) | \ (U32)(cdb[2] << 8) | \ (U32)((cmd[1] & 0x1f) << 16)\ ) #define SET_START_BLOCK6(cdb, blk_num) \ cdb[3] = (U8)(blk_num & 0xff); \ cdb[2] = (U8)((blk_num >> 8) & 0xff); \ cdb[1] &= 0xE0; \ cdb[1] |= (U8)((blk_num >> 16) & 0x1f);\
Resolution:	Modified the definitions for CDB6
Fix Impact:	Cosmetic
External Behavior Change:	No
Suggested Testing:	No testing required for this. Currently supported OSes by MegaSR do not use this command.
Child Tasks:	LSIP200019904

DFCT ID:	LSIP200064995
Headline:	CmdTool2 Linux version -CfgLDAdd command fail for MegaSR.
Description:	CmdTool2 Linux version Linux_CMDTool2_v8.00.13 -CfgLDAdd command fail for MegaSR. Below command works fine for MegaSAS, but fails for MegaSR. CmdTool2 -CfgLDAdd -Rx[E0:S0] -sz10240 -aN The test is done for ICH10R MegaSR mode on Bluff Creek. DOS version ESRT2CLI can configure RAID, but customer wants the linux version. So CmdTool2 needs to support this.
Steps to Reproduce:	CmdTool2 Linux version Linux_CMDTool2_v8.00.13 -CfgLDAdd command fail for MegaSR. CmdTool2 -CfgLDAdd -Rx[E0:S0] -sz10240 -aN The test is done for ICH10R MegaSR mode on Bluff Creek.
Resolution:	Newer cmdline tools require "mfc features get" should be supported.
Fix Impact:	Medium
External Behavior Change:	No
Suggested Testing:	All the newer command line tools should work without a problem.
Child Tasks:	LSIP200019908

DFCT ID:	LSIP200056366
Customer DFCT No:	SWRAID_PR4026
Headline:	New PnP ID required in Athens SWR driver 13.16.0308.2010
Description:	Please add Device_ID of OEM Workstation to LSI Embedded MegaRAID Driver module. Please add following Device_ID to LSI Embedded MegaRAID Driver module. <IbexPeak-M> PCI\VEN_8086&DEV_3B2C&SUBSYS_839F1033 [CLM] VenderID :8086h DeviceID :3B2Ch SubsystemVenderID :1033h SubsystemDeviceID :839Fh
Version of Bug Reported:	13.16.0308.2010
Steps to Reproduce:	NA
Customer Defect Track No:	SWRAID_PR4026
Child Tasks:	LSIP200019773

DFCT ID:	LSIP200064991
Headline:	SWR: SLT shows max drive support for Raid 10 as 16 drives
Description:	Install OS using suitable driver. Boot upto OS. Open SLT and select "Get controller Info". It shows that Controller supports max of 16 PDs for Raid 10 , but SWR supports max of 8 PDs. Screenshot attached. The following components have been used ---------------------------------------------------- RAID Web Console 2 6.90.0200Profile Summary - Generated on Fri Mar 12 07:19:00 PST 2010 ---------------------------------------------------------------------------------------- SERVER--- Server IP: 127.0.0.1 Server Name: WIN-ZZ2VGFI5ZBI OS name: Windows Server 2008 OS Version: 6.0 OS Architechture: x86 Driver Name: LSI MegaSR RAID5 Driver Version: 13.15.0309.2010 Application Version: RAID Web Console 2 - 6.90.0200 HARDWARE--- Controller: Intel Embedded Server RAID Technology II (Bus 0,Dev 31) Status: Optimal Firmware Package Version: Firmware Version: null BBU: NO Enclosure(s): 0 Drive(s): 6 Virtual Drive(s): 2 Drives--- CONNECTOR PRODUCT ID VENDOR ID STATE DISK TYPE CAPACITY POWER STATE SEAGATEST310003 ATA Online SATA 931.000 GB On ST3500630NS ATA Online SATA 465.250 GB On ST3500630NS ATA Online SATA 465.250 GB On ST3500630NS ATA Unconfigured Good SATA 464.729 GB On ST380815AS ATA Unconfigured Good SATA 73.574 GB On ST3500630NS ATA Unconfigured Good SATA 464.729 GB On Virtual Drives--- TARGET ID NAME CAPACITY STATE RAID LEVEL MegaRAID RECOVERY 0 MegaSR R0 #0 93.100 GB Optimal RAID 0 NO 1 VD_1 10.000 GB Optimal RAID 1 NO
Steps to Reproduce:	1) Open SLT 2) Select Get controller info 3) SLT shows that R10 supports max 16 Pds
Resolution:	Need to crate "mfc defautls get"
Fix Impact:	Medium
External Behavior Change:	No
Suggested Testing:	All the new tools should work with Athens now.
Child Tasks:	LSIP200019908

DFCT ID:	LSIP200065163
Headline:	In MegaSR remove debug message print when MSM sends sglist larger than one
Description:	The following message appears 24 times during HDD stress test: megaswr[osl]: err sge_count=2 > one OS: Sles10 x86 64 SP3 Driver: megasr 13.11.0922.2009 HDD: 2 x RAID 1 with SSDSA2SH032G1GN (Fw:045C8860) In Megasr driver we only support ioctl sglists of length 1. Sometimes MSM is sending sglist of length > one , then we return invalid status to application then it is retried with sglist length one. We see the print when we find this condition. It‚s harmless but customer wants we can remove the print. FTS requests not post this message to the system log, since this condition is harmless.
Steps to Reproduce:	See description.
Resolution:	Making CL_ERR to CL_IOCTL.
Fix Impact:	Cosmetic
External Behavior Change:	No
Suggested Testing:	Should n't see the debug message in the driver log.
Child Tasks:	LSIP200019906

DFCT ID:	LSIP200018636
Headline:	OEM driver version 13.13.1021.2009 for win 7 lists LSI product in txtsetup.oem driver info.
Description:	Win 7 drivers txtsetup.oem file for OEM driver version 13.13.1021.2009 lists the driver has a LSI product. [Disks] MEGASR = "LSI Embedded MegaRAID Controller Driver (Windows Vista/Longhorn for x64)", \megasr.sys, \ This driver is an OEM driver and should be labeled appropriately.
Steps to Reproduce:	no recreation steps are necessary.
Resolution:	Fixed the string.
Fix Impact:	Low
External Behavior Change:	No
Suggested Testing:	Should see OEM strings now.
Child Tasks:	LSIP200019538

DFCT ID:	LSIP200065280
Headline:	MegaSR - Change the Win7-x86 and Win7-2k8r2-x64 txtsetup.oem files to not refer to Vista/Longhorn
Description:	Request from OEM: Could you change the Win7-x86 and Win7-2k8r2-x64 txtsetup.oem files to not refer to Vista/Longhorn? They are not the same OS, and should be listed as the Windows 7/2k8r2 driver disk/readme. This is likely to cause customer confusion in an area that is already pretty confusing to some (which driver am I supposed to load???). In reality, I‚d prefer the Vista-2k8 txtsetup.oem to refer to Vista/2k8 instead of Vista/Longhorn, but that is an even smaller concern (since these are at least the right OS‚s being referenced, even if it uses a pre-production Windows codename).
Steps to Reproduce:	Packaging issue
Resolution:	Changed directory names and txtsetup.oem to refer to win7.
Fix Impact:	Medium
External Behavior Change:	No
Suggested Testing:	Open the package and see if any vista strings in win7 and directory name should be windows7_2008R2_*.
Child Tasks:	LSIP200019778

DFCT ID:	LSIP200053655
Headline:	SWR with onboard 1068E takes 7 minutes to boot Linux system (SUSE 10 SP2)
Description:	Cisco is using the onboard 1068E controller with SR mode firmware and have a RAID5 array set up with SUSE 10 SP2 installed. When the OS boot up, it seems like the megasr driver is getting stuck initializing the driver and it takes 6 to 7 minutes for the system to finish booting. The current driver installed is 13.10.0708.2009 and the message in DMESG dumped is below. megaswr[10xx]: normal IOC transition to READY megasr: reply register for start stop unit:0x3f005e0 target:0, address reply megasr: start stop unit error reply, ioc status:0 scsi status:0x2 megasr[mpt]: start stop failed on target 0, retrying again:1 megasr[mpt]: Device:[0:ST31000340NS SN06] capacity=0x74706db0 megasr: reply register for start stop unit:0x3f00660 target:1, address reply megasr: start stop unit error reply, ioc status:0 scsi status:0x2 megasr[mpt]: start stop failed on target 1, retrying again:1 megasr[mpt]: Device:[1:ST31000340NS SN06] capacity=0x74706db0 megasr: reply register for start stop unit:0x3f006e0 target:2, address reply megasr: start stop unit error reply, ioc status:0 scsi status:0x2 megasr[mpt]: start stop failed on target 2, retrying again:1 megasr[mpt]: Device:[2:ST31000340NS SN06] capacity=0x74706db0 megasr: reply register for start stop unit:0x3f00760 target:3, address reply megasr: start stop unit error reply, ioc status:0 scsi status:0x2 megasr[mpt]: start stop failed on target 3, retrying again:1 megasr[mpt]: Device:[3:ST31000340NS SN06] capacity=0x74706db0 megasr: raid 5 logical drive is online, is fully initialized, has 4 drives, and has a size of 0x3d08f000 sectors. megasr: raid 5 logical drive is online, is fully initialized, has 4 drives, and has a size of 0x7a11f800 sectors. megasr: raid 5 logical drive is online, is fully initialized, has 4 drives, and has a size of 0xa5ca9800 sectors. megasr[raid_key]: [x] RAID5 support [x] SAS drive support
Steps to Reproduce:	OS: SUSE 10 SP2 1068E BIOS is M1068e.06.05071459R SWR driver is 13.10.0708.2009 - Create RAID5 volume and install SUSE 10 SP2 - after finish installing OS, restart the system and observe system boot time - It takes 6 to 7 minutes before you see the desktop
Resolution:	Hardreset in mpt is needed for WHQL passing. Not need for Linux.
Fix Impact:	Medium
External Behavior Change:	No
Suggested Testing:	Loading of the driver should be faster for Linux installs.
Child Tasks:	LSIP200019909

Task ID:	LSIP200019903
Headline:	19903 With MegaSR system does not indicate missing drive when pulled from configuration
Description:	With MegaSR system does not indicate missing drive when pulled from configuration
State:	Ready_for_Delivery
Change Set Files:
References:	LSIP200049946(DFCT)

Task ID:	LSIP200019904
Headline:	19904 SWR uses wrong macro definition for CDB6 READ/WRITE commands
Description:	SWR uses wrong macro definition for CDB6 READ/WRITE commands
State:	Ready_for_Delivery
Change Set Files:
References:	LSIP200064527(DFCT)

Task ID:	LSIP200019910
Headline:	19910 New PnP ID required in Athens SWR driver 13.16.0308.2010
Description:	VenderID :8086h DeviceID :3B2Ch SubsystemVenderID :1033h SubsystemDeviceID :839Fh
State:	Delivered
Change Set Files:
References:

Task ID:	LSIP200019778
Headline:	19778 Change the Win7-x86 and Win7-2k8r2-x64 txtsetup.oem files to not refer to Vista/Longhorn
Description:	Change the Win7-x86 and Win7-2k8r2-x64 txtsetup.oem files to not refer to Vista/Longhorn
State:	Delivered
Change Set Files:
References:	LSIP200065280(DFCT)

Task ID:	LSIP200019773
Headline:	19773 LSIP200063829
Description:	LSIP200063829
State:	Delivered
Change Set Files:
References:	LSIP200056366(DFCT)

Task ID:	LSIP200019909
Headline:	19909 SWR with onboard 1068E takes 7 minutes to boot Linux system
Description:	SWR with onboard 1068E takes 7 minutes to boot Linux system
State:	Delivered
Change Set Files:
References:	LSIP200053655(DFCT)

Task ID:	LSIP200019475
Headline:	19475 Task to create release
Description:	Task to create release
State:	Active
Change Set Files:
References:

Task ID:	LSIP200019908
Headline:	19908 SWR: SLT shows max drive support for Raid 10 as 16 drives
Description:	SWR: SLT shows max drive support for Raid 10 as 16 drives
State:	Delivered
Change Set Files:
References:	LSIP200064991(DFCT)     LSIP200064995(DFCT)

Task ID:	LSIP200019906
Headline:	19906 LSIP200051693 : In MegaSR remove debug message print when MSM sends sglist larger than one
Description:	LSIP200051693 : In MegaSR remove debug message print when MSM sends sglist larger than one
State:	Delivered
Change Set Files:
References:	LSIP200065163(DFCT)

Task ID:	LSIP200019642
Headline:	19642 Fixing INTEL strings in textsetup.oem
Description:	Fixing INTEL strings in textsetup.oem
State:	Active
Change Set Files:
References:

Task ID:	LSIP200019538
Headline:	19538 LSIP200018636 : OEM driver version 13.13.1021.2009 for win 7 lists LSI product in txtsetup.oem driver info.
Description:	OEM driver version 13.13.1021.2009 for win 7 lists LSI product in txtsetup.oem driver info.
State:	Delivered
Change Set Files:
References:	LSIP200018636(DFCT)

Task ID:	LSIP200019907
Headline:	19907 For SSDs, the MegaSR driver reports the wrong media type
Description:	For SSDs, the MegaSR driver reports the wrong media type
State:	Ready_for_Delivery
Change Set Files:
References:	LSIP200064987(DFCT)

Task ID:	LSIP200019911
Headline:	19911 RHEL 5.5 support
Description:	RHEL 5.5 support
State:	Delivered
Change Set Files:
References:	LSIP200065286(CO)

Heading:

Known Restrictions

Contents:

• Type "brokenmodules=ahci" line at kernel parameter line during SLES 9 & 10 installations • RHEL 3.0 64-bit versions are not supported on AMD systems. Only Intel systems are supported. • RAID 5 is not supported on XEN. • In SWR5 driver, RAID 5 feature is enabled only if iButton is present in the system. BIOS communicates the presence/absence of iButton using configuration data on disk (DDF) and through device registers from BIOS version 06.10111923. So if IButton is present then any driver version later than 10.02.1001.2007 with BIOS version later than 06.10111923 should be able to create a R5 logical drive using an operating system application. The following limitation is applicable for any driver (version less than 10.02.1001.2007) and BIOS (version less than 06.10111923) combination:-      If driver does not read a valid DDF, it will disable R5 creation. Driver may not see valid DDF if (A) user does not configure using BIOS Ctrl+M; or (B) if no drives were present at the boot time and all the drives were hot-inserted after OS is booted. In both cases, user must create initial configuration using BIOS Ctrl+M utility. • A RAID 5 logical drive withstands single drive failure by reconstructing missing data from the data and parity from the remaining drives. The assumption underlying this ability is that the data in the remaining drives is consistent. This assumption becomes invalid if there is a power loss during write operation(s). If there is a loss of power during a write operation, data inconsistencies may occur because data and parity writes may have completed only partially. After subsequent reboot the logical drive has inconsistent data on that particular stripe. If a drive were to fail at this point, missing data (for the inconsistent stripe alone) cannot be reconstructed from remaining drives. To correct inconsistency, drivers starts back ground initialization (BGI) at reboot. While BGI is in progress, the inconsistent stripe(s) are vulnerable to drive failure. One way to avoid this window of vulnerability is to run check consistency on the logical drive using BIOS utility. Another way is to prevent an unplanned shutdown (e.g. using UPS). • The LITE-ON SH S752K model CD/DVD ROM device does not respond to 0x55 & 0x51 MMC commands properly. The device hangs when these commands are issued multiple times. The driver resets the device when it hangs; but reset adversely affects DVD burning. This behavior can be consistently observed using K3B DVD burning software. K3B aborts DVD writes when 0x55 is failed and device is reset. • RHEL5 installation does not automatically prefer the driver in DUD to native driver. Run replace_ahci script inside the DUD before rebooting during the last stage of installation. Refer to readme.txt under in the DUD for more details • RAID 5, by its very nature, cannot tolerate double failures. The double failure can be a combination of a single drive failure and either; more drive(s) failure or an unplanned power failure, in the RAID system. Unplanned power failure can be including but not limited to, loss of power source or an unusual system shutdown. Unplanned power failures while there are medium errors on the drives is also considered as a double failure condition. • No Linux hibernation Support. Multiple drive failure would result in a data loss condition. A single drive failure combined with any additional unplanned failure can cause loss of data integrity. To avoid loss of data integrity for the power failure case, it is highly recommended to provide an uninterrupted power supply to the server to protect the RAID 5 subsystem during the event of a degraded or rebuilding state. Medium errors on the disks, combined with an unplanned power failure can also cause loss of data integrity, but this occurrence would be very unlikely.