========================================================================== The checksum's (found through sum -r) of the files that you have received (other than this README) are as follows: 00212 15 patchSG0003674.idb 21780 71 patchSG0003674.raid_man 64972 7175 patchSG0003674.raid_sw 01483 2 patchSG0003674 ========================================================================== - 1 - 1. Patch_SG0003674_Release_Note This release note describes patch SG0003674 to DG SCSI&FC RAID 3.1. Which contains: o Phoenix (model 2800) flare code 9.56.03/prom code 1.73 o Raid5 Agent, CLI, and GUI revision 1.7.1 1.1 Supported_Hardware_Platforms This patch contains software support for the Challenge (SCSI) RAID sub-system for the following: o Challenge servers with IP19, IP21, IP22 processors o Onyx systems with IP19, IP21 processors o Origin and Onyx-2 systems with IP27 processors The software cannot be installed on other configurations. 1.2 Supported_Software_Platforms This patch contains bug fixes for DG SCSI&FC RAID 3.1 (1275171120) on a system running IRIX 6.5.4, 6.5.3, 6.5.2, 6.5.1, 6.4-S2MP+O, 6.2, 6.1, 5.3xfs, 5.3. The software cannot be installed on other configurations. 1.3 Bugs_fixed_in_Patch_SG0003674 The bugs listed in this patch are simply requests to release new flare code, prom code, and management software. And as such do not represent real bugs. Refer to release note chapter 3 "Bug Fixes", for a description of the bug fixes for flare code, prom code, and management software. Bug numbers from Silicon Graphics bug tracking system are included for reference. o 698822 As of SP firmware 9.x6 a long standing bug which swapped the values for SP A and SP B on Mode page 29h was corrected. Therefore, when the 1.5.5 version (which worked around the long standing bug) of the SCSI RAID management software is used to monitor the status of the SCSI RAID subsystem and an SP is pulled or goes bad, the unaffected SP will be shown to have the problem (e.g., SP B fails, BUT CLI getcrus command reports that SP A is faulted, instead of SP B). This also has an effect on the SP ID returned from the SP ulogs (e.g., when viewing SP A ulog, SP B (ID) is - 2 - reported, instead of SP A). This issue has been resolved with the 1.7.1 version of the SCSI RAID management software. o 687416 When the year = 2000, the CLI (e.g., raidcli) 'getlog' reports the year = 100, instead of 2000. This issue has been resolved with revision 1.7.1 of the SCSI RAID system management software. o 670569 A memory resource problem has been identified with Flare code version 9.56.02. When the resource is depleted an SP panic code of "0x00220064" will be reported. This issue has been resolved with flare code 9.56.03, prom code 1.73. o 551121 When the devices in the raid5-agent.config file aren't listed in A,B order, the positional information reported to the client may be inaccurately reported by the Agent. This issue has been resolved with management software version 1.7.1. o Modified shell scripts that used the command string "ps -ef | grep raid5-agent | grep -v grep >/dev/null" to now use "ps -e | grep raid5-ag >/dev/null" This resolves an incorrect exit status value that is returned when /bin/sh is used, on systems with 'xpg4' (6.2+xpg4) installed. o Modified /usr/raid5/raid5gui shell script. Added environment variable in order to set XVTPATH=/usr/raid5/print. 1.4 Subsystems_Included_in_Patch_SG0003674 This patch release includes these subsystems: o patchSG0003674.man.relnotes o patchSG0003674.sw.fcraid o patchSG0003674.sw.scsiraid - 3 - 1.5 Installation_Instructions Because you want to install only the patches for problems you have encountered, patch software is not installed by default. After reading the descriptions of the bugs fixed in this patch (see Section 1.3), determine the patches that meet your specific needs. If, after reading Sections 1.1 and 1.2 of these release notes, you are unsure whether your hardware and software meet the requirements for installing a particular patch, run inst. The inst program does not allow you to install patches that are incompatible with your hardware or software. Patch software is installed like any other Silicon Graphics software product. Follow the instructions in your Software Installation Administrator's Guide to bring up the miniroot form of the software installation tools. Follow these steps to select a patch for installation: 1. At the Inst> prompt, type install patchSGxxxxxxx where xxxxxxx is the patch number. 2. Initiate the installation sequence. Type Inst> go 3. You may find that two patches have been marked as incompatible. (The installation tools reject an installation request if an incompatibility is detected.) If this occurs, you must deselect one of the patches. Inst> keep patchSGxxxxxxx where xxxxxxx is the patch number. 4. After completing the installation process, exit the inst program by typing Inst> quit - 4 - 1.6 Patch_Removal_Instructions To remove a patch, use the versions remove command as you would for any other software subsystem. The removal process reinstates the original version of software unless you have specifically removed the patch history from your system. versions remove patchSGxxxxxxx where xxxxxxx is the patch number. To keep a patch but increase your disk space, use the versions removehist command to remove the patch history. versions removehist patchSGxxxxxxx where xxxxxxx is the patch number. 1.7 Installing_flare_code In order to use all of the functionality and bug fixes of the SCSI RAID subsystem you need to update the disk and flare code. Refer to release note chapter 5 "Updating Firmware Instructions". 1.8 Disk_Drive_Prerequisite Whenever the flare code adds support for a new disk drive capacity, you MUST FIRST install the flare code that supports said disk drive; prior to installing said disk drive. 1.9 Caveats_for_Raid5_version_1.7.1 1.9.1 If flare version less than 9.x5 is installed on the SCSI RAID subsystem, the following features are not supported: - gethostmode and sethostmode (CLI commands) - getsniffer and setsniffer (CLI commands) - Bkgd Verify button (GUI) 1.9.2 If Agent version 1.5.5 is running on a server with SCSI RAID subsystem attached, the following features are not supported: - change the amount of RAID 3 Cache (CLI 'setcache' command, and GUI) - view SP ulog (GUI) - gethostmode and sethostmode (CLI commands) - getsniffer and setsniffer (CLI commands) - 5 - - Bkgd Verify button (GUI) 1.10 Known_Problems - 1 - 2. Known_Problems_(SCSIRAID) 2.1 Agent o After downloading new firmware, the RAID subsystem will reboot. After the RAID subsystem has rebooted, the Agent must be restarted. o Certain revisions of flare code, may report the incorrect flare code text string revision level. For example; if flare code 8.20 is loaded, then 'SP Powerup; Rev 0x%08x' (instead of 'SP Powerup; Rev 0x00081400') will be reported in the SP ulog. 2.2 CLI o When the seconds field value is less than 10. The output from CLI command 'getcontrol' will report the following: System Time: 11:40:3 instead of System Time: 11:40:03 o The 'getdisk' command reports available disk capacity (e.g. 4.09 GB base10), not raw capacity (e.g. 4.2 GB base10). o When using the 'getsniffer' command, and you specify a LUN that isn't currently owned by said device or a LUN that is a Hot Spare. The error message "Illegal Parameter in Request" will be reported. o When using the 'setsniffer' command, and you specify a LUN that isn't currently owned by said device or a LUN that is a Hot Spare. The command executes as though a change had been made, but no change was actually made (an error message should had been reported). o When using the CLI 'getlun' command on a non-exist LUN-ID. Instead of reporting an error, invalid LUN information is reported. o When using CLI commands the following error message might be reported: SCSI ERROR: Illegal Parameter in Request If an invalid parameter is specified. - 2 - 2.3 GUI o When viewing the Disk Info options from the Summary View, the error message 'Unagle to fill in Disk Info!" may appear. Simply ignore this message and press OK. All available disk information is displayed. o When allocating or deallocation memory for Flare-E SP firmware or RAID 3, the changes do not take effect until the array is rebooted. The total memory in the current windwo changes, but is not an accurate reflection of the total memory currently allocated on the array. The worst scenario is deallocating memory on Flare-E SP firmware or RAID 3 and the allocating more read or write cache than the SP has memory for. This will cause a failed request on changing the memory partition, and may cause the Agent to lock up resulting in a reboot of server system (in oder to terminate Agent zombie process) to restart the Agent. To avoid this, it is recommended that when changes are made to Flare-E SP firmware or RAID 3 cache that the RAID subsystem is rebooted so those settings will change. Then make changes to read or write cache and reboot the array again. Currently, warning message appear for these conditions on SP-A settings only. o When setting Flare-E SP firmware cache to any value other than zero, it is possible that the change will cause the Agent to lose communications with the array and hang up. After setting Flare-E SP firmware value, it is recommend that you restart both the Agent and GUI. o Unbind a faulted Hot Spare or fault Disk does not refresh the GUI to reflect the true state until the disk is faulted disk is reinserted. o It is possible to enable Write Cache in the SP Cache Settings Window while the BBU is removed or recharging. However, the change does not take effect until the BBU (Battery Backup Unit) comes back online. See the SP Cache Summary Windoe for the actual state of the Cache. o When a RAID 3 LUN is double faulted and then the Change button is clicked in the LUN Information Window, it is possible to crash the GUI. (CLARiiON Bug# SE-2958) o Hot keys will only work if the "NUM LOCK" key is disabled. - 3 - o The GUI will crash (i.e., dump core), when the Help Menu print option is used. To prevent this problem, prior to starting the GUI session, you need to set XVTPATH=/usr/raid5/print. See examples below: For /bin/csh: setenv XVTPATH /usr/raid5/print For /bin/sh: XVTPATH=/usr/raid5/print export XVTPATH Or DO NOT use the Help Menu print option. o The use of Disk ID's is not refreshed in all windows. When the checkbox next to "Use Disk ID's" is toggled on, it only toggles on the current Equipment or Summary View from where it was originally set. The other windows will use Disk ID's. However, the toggle button for "Use Disk ID's" will be off until that window is closed and then reopened. o The background verify window reports the LUN number in decimal format rather than hexadecimal, as is the case in other windows. o If a session of the GUI is used to look at more than one chassis and a LUN on one chassis is unbound, the LUN icons in the Summary Views for the other chassis will not display their LUNs until a poll has occurred. o In certain states the GUI will appear to hang but polling will continue and screens will be refreshed. Restart GUI with the polling interval at a higher interval to prevent this problem. o Do to the size of the *fontList, some of the text string characters in the widow dialogs get clipped. o The refresh rate has a ~3 second delay. This is an issue with XVT (third party development tool)/SGI visuals. o The Help Menu option still doesn't allow the help text information to be printed. This is an issue with XVT (third party development tool)/SGI visuals. o You will not be able to set or reset RAID 3 Cache values properly, when accessing a server that has RAID subsystems attached and Agent 1.5.5. Attempting to do so will either not be allowed or may result in the - 4 - Agent and GUI crashing. If it is necessary to change the RAID 3 cache values on a server with 1.5.5 Agent, either use the 1.5.5 GUI to change the values or upgrade the Agent to 1.7.1. o After downloading new firmware, the RAID subsystem will reboot. After the RAID subsystem has rebooted, the GUI must be restarted. o The Disk information window displays available disk capacity (e.g., 4.09 GB base10), not raw capacity (e.g., 4.2 GB base10). o The 'LUN Information dialog', bkgrnd verify button isn't grayed (shadowed out) for Hot Spare units. o The Change LUN Parameters window allows settings of parameters that are not applicable to a certain LUN type. This causes no problems. o The cache windows (SP summary, etc) are not continually update by Agent polling, but represent the state of the cabinet when the cache window was created. o If the `font-type` for the X-terminal is not defined in the /usr/raid5/Xdefaults file, the following error message will be reported: fatal: FATAL ERROR: MSG 0x0034b3ba [CAT 3/4 STD 46010 ] Category: XVT release 3 assert (Signaled assert4) Function: xvt_app_create xvt_R3FNT_system File: ./kfont.c line: 790 o Using GUI on Reality Engine-I/II and Infinite Reality graphics the following error message is reported: fatal: FATAL ERROR: MSG 0x0034df3e [CAT 3/4 STD 57150 ] Category: XVT release 3 assert (Signaled assert4) Function: xvt_dwin_draw_image xvt_win_create xvt_win_create xvt_win_crea File: ./kimage.c line: 201 The temporary fix to this problem is to edit the /usr/lib/X11/xdm/Xservers file and include (at the end-of-line) the following: -class TrueColor -depth 24 Afterwhich, you need to reboot the system. - 5 - o Features that you can not manipulate with the GUI. See list below: - Write-Aside (buffer size) - Idle-threshold - Idle-delay-time o The width of the GUI is fixed, so if you specify a font-type/style that exceeds the width limits the text from the sessions will be clipped. o All GUI sessions when minimized will display raidgui, instead of host name, on icon title bar. o Prior to stopping/ restarting the agent, GUI session needs to be terminated. If this isn't done, any GUI session operation will cause the GUI to abnormally terminate. o GUI alarm settings are not saved from one session to the next. If you exit the GUI, you must reset the alarm settings when you restart it. o When using the GUI to initiate a bind, the flare code could cause (intermittently) the GUI to lock up in a wait forever state. To clear this condition the GUI must be restarted. The bind will also need to be restarted. o When using the GUI, if the RAID_ARRAY_HOSTS variable is not set and /root and /usr are on separate partitions the following pop-up window will be displayed: unable to save host file: Cross-device link o The GUI is supported in a stand-a-lone environment (no other GUI applications running at the same time). The resources used by both GUI's may cause the RAID GUI to crash. o The GUI doesn't support re-sizing of windows. o When using the GUI, before setting the raid3 memory cache size, you must first disable (automatic) polling. o The GUI uses several color maps, but does not support mono-crom. For example the color light blue will appear as white on a mono-crom display. o If the Help Window is brought up from the Select Hosts window, the window menu option for Close will not close - 6 - the Help window. Use File->Exit to close the Help window. 2.4 Flare_Code o After unbinding a faulted Hot Spare or faulted Disk, FLARE still reports the LUN as faulted. This condition is not corrected until the disk is reinserted. NOTE This issue causes the GUI to reflect the incorrect status state. o During flare download, an error condition; which causes a "UNKNOWN SCSI ERROR" when downloading Flare, may occur. This can be corrected by power cycling the RAID sub-system reporting the error. o Some requests made by the management software, are INTERMITTENTLY rejected by flare. o When an UNS 'unsupported', disk drive is installed in the array flare, via Mode Page, reports the state of the disk drive as REM 'removed'. o When using the 'getsniffer' CLI command on a LUN that is not owned by the specified device, flare rejects the request (check condition 5/4/0) and the error message "Illegal Parameter in Request" will be reported. o When using the 'setsniffer' CLI command on a LUN that is not owned by the specified device, flare dose not reject the request. Therefore, any requested change to be made to the specified LUN via the specified device will not take effect. o When using the 'getsniffer' CLI command on a Hot Spare LUN, flare rejects the request (check condition 5/25/1) and the error message "Illegal Parameter in Request" will be reported. o SP Panic code of 0x00800000, extended code 0x00025db0 will be reported, when using the 'setsniffer' CLI command on a Hot Spare LUN. o After a panic dump image is copied to a hot spare disk that is in a ENA (enabled, part of a LUN group) state. The application software used to extract the dump image can't access the data until said hot spare disk is in a RDY (ready, not part of a LUN group) state. - 1 - 3. Bug_Fixes_(SCSIRAID) 3.1 Agent 3.1.1 version_1.7.1 o During the dump retrieval process, if data within the LIC (a.k.a flare code) dump retrieval file was misaligned. No error message was reported. This issue has been resolved. o If the SPs are not listed in A,B order in the configuration file, their position may be inaccurately reported by the Agent. o The 'agent' has been updated to support a change that was made to flare code version 9.56.xx and greater. When flare code version 9.56.xx or greater is installed on an SCSI RAID sub-system and a SP fault occurred the incorrect SP-ID would be reported. For example if SP-A was faulted the CLI 'getcrus' command would report that SP-A was OK and that SP-B was faulted. Also, the CLI/GUI is used to view the SP logs. The SP-ID returned in the output would be incorrect. For example, using the CLI the SP-ID would report "SPA: (a11): SP Removed" instead of "SPB: (a11): SP Removed". This issue has been resolved. 3.2 CLI 3.2.1 version_1.7.1 o The 'getdisk' command may report a negative Capacity value (i.e., A1 Capacity: -8 MB). This issues has been resolved. o The 'getlog' command isn't Y2K compliant. When the Year 2000 occurs the format reported will be MM/DD/100, instead of MM/DD/2000. This issue has been resolved. o The 'chglun' command doesn't have an that allows auto-assign to be disabled. This issue has been resolved. - 2 - 3.3 GUI 3.3.1 versions_1.7.1 o Previously, the Help Menu print option would report an error message "Can't open prolog file". This issue has been resolved. 3.4 Flare_Code 3.4.1 version_9.56.03 o A memory leak causing 0x00220064 panics was fixed. o A timeout condition causing 18 Giga Byte 10K RPM disks to shutdown on hot insertion, was increased to allow hot insertion to work properly. 3.4.2 version_9.56.02 o It was possible for cache to end up in a frozen-frozen state if a vault disk failed when cache was enabling after another vault disk have been repaired. o Intermittently a LUN that was assigned would not re- assign following a rebuild, or after a database disk rebuild was completed or a system was restarted. o FLARE would intermittently experience a panic 0x00000008, Extended Status 0x00000003, while viewing the Performance Statistics for a failing disk module in a powering up state with statistics logging enabled. o The FRU ID information for SP-B of Mode Sense page 0x29 was the same for SP-A. The information returned in Mode sense page 0x29 for SP-B is now correct. 3.4.3 version_9.56.01 o The Logical Unit_RESERVED bit was not cleared when a target reset occurred. FLARE now clears the reserved bit when it is reset. o The following panics would intermittently occur when the array was operating under extremely stressful conditions: 0x00220011 intermittently dumping cache 0x00220064 synchronizing cache on a RAID 3 LUN - 3 - 0x00000008 Extended Code 0x00000003 intermittently when unbind disks from Gridman 0x00c0000c unbinding a LUN immediately after a bind has completed with the sniff verify feature enabled 0x00800077 while changing array configuration parameters 0x04220028 intermittently, writing to a Hot Spare that aborts the operation o FLARE returned the incorrect SP identity (A or B) when an SP event was reported. FLARE now returns the correct value. o Older 1.2 GB and 2.0 GB IBM disk modules, with out-of- date disk firmware installed, were not compatible with some previous revision of FLARE. This resulted in these disks being powered down after installing the new FLARE revision. This problem has been resolved. o If a cache dump was interrupted by some abnormal event it was possible for a LUN to be marked "Cache Dirty" incorrectly. This problem has been corrected. o A higher than normal soft error rate on array storage processor was found to be a result of FLARE and PROM code incorrectly setting memory timing. Changed FLARE memory timing to correct value. o In order for a Mode Sense to Page 30h to work, a Mode Select must first be issued, otherwise the Mode Sense should return a check condition. FLARE was returning incorrect check condition values (All zeros) in Page 30h bytes SK/ASC/ASQ. FLARE now returns a correct error code. o Intermittently all disk drives in a chassis might simultaneously be incorrectly shutdown be FLARE. This occurred as a result of an SP experiencing repetitive 0x00000008, extended code 0x00000a14, panics. Because the panics are occurring back to back, FLARE does not have time to make a ULOG entry. There is, however, a valid entry in the array's Non-Vol memory log. FLARE no longer exhibits this failure. o Executing a 6 Byte Mode Sense (0x1A), Page 02h command resulted in a check condition. This command now works correctly. - 4 - 3.4.4 version_9.55.06 o RDY/RDY LUN lock The issue resolved in Flare for this particular situation, evolved around correcting an internal Flare race condition. During the power down of an RAID sub- system, a memory resident copy of the GLUT (Global Logical Unit Table) was updated with intermediate status and was later written to disk as valid status. The status indicated that more than 1 unit on a RAID 1/0 LUN needed rebuild. When the RAID sub-system was powered on, the LUN could not be assigned due to the multiple rebuild state. This problem was an issue with only RAID 1/0 units due to the unique algorithm used be this RAID set. Flare has been fixed to no write the intermediate status to disk. o Christmas Tree Multiple Drive Shutdown Experimentation in the lab has shown that an NMI signal on the Storage Processor that is asserted for a longer than expected amount of time, can cause Flare to re-iterate through it's trap handler routine several times. Each iteration causes Flare to issue a Reset on the back-end buses. If more than 10 Resets are issued, then Flare will begin to shut drives off. The lab experiments showed a multitude of iterations through the Trap Handler and, subsequently, a multitude of back-end Rests. Flare has been altered to not iterate through it's Trap Handler under these circumstances. Given that an NMI signal that is asserted for too long may be an indication of a hardware fault, Flare will now issue 1 back-end Reset and then fault the Storage Processor. The 1 back-end Reset is necessary to inform the peer SP that it's partner has gone away. This will allow the remaining storage processor to flush write cache and not cause any cache dirty can't assign(s). o 000c000c Panic Although this panic could not be reproduced at CLARiiON, we (CLARiiON) believe that SGI has provided enough information for us (CLARiiON) to resolve it. This panic evolves around the Verify Process using an intermediate table that was out of synch with another more reliable table in Flare. The fix for this situation is to have the Verify Process use the more reliable table and not use the intermediate table. - 5 - o Data Integrity with Hot Spares Rebuilding While in the process of rebuilding a Hot Spare, it was possible that if the Hot Spare started up quick enough that the Verify Process did not notice it, then the Verify Process could attempt to verify data this is outside the range of the rebuild data on the Hot Spare. The Verify Process could then attempt to correct that data by it's internal re-construction methods. Experimentation in the lab showed that if the Verify sniff rate was not increased past 3 seconds, the default, then the Verify Process was awakened quick enough to catch the switch to the Hot Spare. The fix for this is to disable the Verify Process on a degraded unit. o 0x937 Error Mis-reported A condition existed in Flare where a 0x937 level message could be reported in the Ulog incorrectly. The cause was a race condition in the lower levels of Flare code dealing with individual disk commands. In actuality, there never was a command problem, but due to the race condition, Flare logged it as one. Flare has since been fixed to no report these errors erroneously. 3.5 Prom_Code_Fixes 3.5.1 version_1.73 o A higher then normal soft error rate on array storage processor memory was found to be a result of FLARE and PROM code incorrectly setting memory timing. Changes PROM code memory timing to correct value. - 1 - 4. Enhancements_(SCSIRAID) 4.1 Agent 4.1.1 versions_1.7.1 o The Agent now supports multiple levels of system log message reporting. The following input parameters have been added to the Agent to determine how messages are outputted: -s = Send ALL unsolicited log (a.k.a ulog) message to syslog. -s0 = Do not send any messages to syslog. -s1 = Use level `alert` for critical messages. o The percent complete of a LUN bind or rebuild is now reported and updated at the completion of each poll cycle. o Now provides a means for the CLI 'getdisk' command to report the disk drive micro-code (firmware) level. Note firmware level reported only for bound LUN(s). o Now allows the CLI and GUI to load flare code with out requiring the SPs to reboot. NOTE: This will not allow the prom code to be updated. 4.2 CLI 4.2.1 versions_1.7.1 o The 'getfru' command has been added to the list of possible commands. For more information, refer to raid5(7). o The 'chglun' command -a autotrespass, has been changed to -at autotrespass. o The 'getlog' command has two new . The <-ecode error_code> argument allows a user to display only specify Ulog error codes and up. For example "-ecode 0x900", would report all Ulog for 0x900 to 0xAFF errors. The <-f> argument will force the Ulog to be read, even thought the Agent isn't polling. - 2 - For more information, refer to raid5(7). o The 'settime' command has been added to the list of possible commands. For more information, refer to raid5(7). o The 'reboot' command has been added to the list of possible commands. For more information, refer to raid5(7). NOTE When Agent revision 1.5.5 is used to manage the RAID subsystem(s) attached to the server. The 'settime' command will appear to complete the operations successfully (i.e., no error message returned), BUT the specified operation did not occur. o Two new commands 'getsniffer' (view sniffer/background verify parameters) and 'setniffer' (change sniffer/background verify parameters) have been added. For more information, refer to raid5(7). o The 'firmware' command has a new (-l). When the <-l> argument is specified, it allows the specified firmware 'filename' to be used from the local host. For more information, refer to raid5(7). o A new command 'gethostmode' has been added. This command allows the "Storage System Options Package" value to be reported. For more information, refer to raid5(7). o A new command 'sethostmode', has been added. This command allows the "Storage System Options Package" value to changed. For more information, refer to raid5(7). IMPORTANT If you change the hostmode to 'open', the RAID subsystem will reboot (soft-restart) and operation in Open CLARiiON mode. In this mode the raid5 agent will not be able to communicate with the RAID subsystem(s). o The 'getdisk' command now reports the disk drive micro-code (firmware) level, for bound LUNs. o The 'getagent' and 'getsp' commands now report the xx.xx.xx version number of the flare code. For example, if the flare code level was 9.56.02, the command output would report the flare level as 9.56.2 (instead of 9.56.02). - 3 - o The 'firmware' command has a new optional-arg (<- noreboot>) that allows flare code to be updated with out rebooting the SP. But, the previous version of flare code will still be running. The new flare code won't take effect until the SPs are rebooted. For more information, refer to raid5(7). CAUTION: If you do not choose to reboot the RAID subsystem after the firmware is downloaded, the PROM code will not be updated. (even if you reboot the SPs later) until you upgrade firmware (again) and choose to reboot the RAID subsystem automatically. o The 'firmware' command has a new (-l). When <-l> is specified the location of the firmware filename is expected to be on the Local Host. For more information, refer to raid5(7). 4.3 GUI 4.3.1 versions_1.7.1 o The SP Cache Settings window, display has been updated. Now there are individual buttons for enabling and disabling Write Cache, SP-A Read Cache, and SP-B Read Cache. o The vertical and horizontal text format from the 'Summary View window', status displayed through color now. Due to space constraints with the support for the 30-slot RAID subsystems, the summary window was redesigned. The Summary window now utilizes color to display the various states upon the buttons. The Equipment window utilizes the same colors to denote changing or error states. o The 'Equipment View window' and 'Summary View window' has a new menu item added called 'Legends'. These were added to explain the new color schemes on the disk module and the LUN buttons. o The SP Summary window, now reports the Host Mode. o The Poll Settings window, now allows a user to change the "Agent Poll Settings". The poll settings window, section for Agent Poll Settings presents 3 options to the user: 1. Polling Enabled 2. Polling Disabled - 4 - 3. Agent Poll Interval The first option, "Polling Enabled", will enable agent polling. The second option, "Polling Disabled", will disable agent polling. The third option, "Agent Poll Interval", will set the agent's automatic polling interval for the current agent session (default value is 60 seconds). By default the agent poll interval is the polling frequency specified by the poll entry in the agent's configuration file. The agent poll interval reverts to this default value whenever the agent is restarted. To change the default agent poll interval for this and subsequent agent sessions, you must set the poll entry in the agent's configuration file to the desired interval. CAUTION If agent polling is disabled, you cannot use automatic or manual GUI polling to update the event log. IMPORTANT You can view/change the agent poll settings only if you have permission to write to the agent configuration file. Any changes that you make to the poll settings are lost when the agent is stopped. NOTE When Agent revision 1.5.5 is used to manage the RAID subsystem(s) attached to the server. The error message "RPC unable to retrieve agent poll settings:" will be reported, when using Poll Setting window. o The Configure menu has a new item, Main Menu bar- >Configure->Reboot SP(s). The Reboot SP(s) window allows you to reboot (soft-restart) the SP(s). Two confirmation windows will be reported, before the SP(s) are rebooted. NOTE When Agent revision 1.5.5 is used to manage the RAID subsystem(s) attached to the server. The error message "Unable to reboot via SP A: RPC returned NULL on reboot request" will be reported, when using the Reboot SP(s) dialog. o The Configure menu has a new item, Main Menu bar- >Configure->Set SP Clock. The Set SP Clock window allows the user to set the date and time for the SPs (SP A and SP B) in the RAID subsystem (selected chassis). The window presents 3 options to the usr: 1. Sync SP to Local Host - 5 - 2. Sync SP to Agent Host 3. Enter new SP data/time The first option, "Sync SP to Local Host", will set the SP clock to the same date and time of the server on which the GUI is running. The second option, "Sync SP to Agent Host", will set the SP clock to the same date and time of the server on which the agent is running. The third option, "Enter new SP data/time", allows the user to specify a date/ time in the form MM/DD/YYYY HH:MM:SS to be set at the SP. IMPORTANT HH must be specified as 0 through 23, (24- hour clock). NOTE When Agent revision 1.5.5 is used to manage the RAID subsystem(s) attached to the server. The error message "Unable to set SP clock. RPC returned NULL on set clock" will be reported, when using the Set SP Clock dialog. o The LUN Information window, has a new button Bkgd Verify. The Background Verify Parameters window, allows the following: 1.