Patch-ID# 116167-01 Keywords: sdlt, sdlt320, sdlt220, l25, l100, quantum, tape drive, firmware Synopsis: Hardware, SDLT320/SDLT220 Automation Tape Drive, Firmware Download Program V70 Date: Jan/30/2004 Install Requirements: Additional instructions may be listed below Solaris Release: 8 SunOS Release: 5.8 Unbundled Product: Sun StorEdge L25/L100 Unbundled Release: N/A Xref: Topic: Relevant Architectures: sparc BugId's fixed with this patch: Changes incorporated in this version: NOTE: - Uprev`ed tape drive firmware to V70 Patches accumulated and obsoleted by this patch: Patches which conflict with this patch: Patches required with this patch: Obsoleted by: Files included with this patch: README.116167-01 SDLTv70lib.img tload_5.0 Problem Description: The drive reports the incorrect remaining capacity of the tape when the drive is interrogated with the Read Capacity SCSI command. This may affect one or more applications. The problem reported was associated with SAM-FS. Patch Installation Instructions: ------------------------------- None. Special Install Instructions: ---------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contents -------- A.0 Firmware File Names, Changes, & Utility Descriptions B.0 Precautionary Statements C.0 Patch Installation and Utility Usage Intructions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A.0 Firmware File Names & Utility Descriptions ----------------------------------------------- A.1 SDLTv70lib.img --> The firmware image SDLTv70lib.img (2,301,952 bytes) A.2 tload_5.0 --> The firmware download utility (57,176 bytes) A.3 README.116167-01 --> This file (52,149 bytes) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A.4 Release Notes for revision changes from V46 to V70 ------------------------------------------------------ Last Release Revision: V46 Revision V47 A.4.1 Problem Description: The SPACE forward by blocks does not seek, it runs sequentially. Root Cause: A bug introduced in V35 causes the drive to think there is a filemark present in the cache between the current position and the target block. This miscalculation causes the drive to read forward towards looking for the filemark or target block instead of moving directly to the target block. Corrective Action: Fix the recognition algorithm so that it does not incorrectly detect a filemark in the cache. Revision V49 A.4.2 Problem Description: A WRITE FILEMARK command with the Number of Filemarks parameter set to zero on a DLTtape IV media (read only in SDLT) will return a good status when the firmware should have reported a check condition with a sense code/ASC/ASCQ of 7/30/05 (Data Protected, Cannot Write Medium, Incompatible Format). Root Cause: A WRITE FILEMARK command with length of 0 while the drive is not in write mode is considered a NO-OP by the firmware and returns good status regardless of the type of tape that is in the drive. Corrective Action: If a WRITE FILEMARK command is issued for a tape that is non-writable by the SDLT220/320, the firmware now returns a check condition for incompatible media (7/30/05). A.4.3 Problem Description: When reading a DLT1 tape the drive may erroneously report a Hard Read Error (HRE). Root Cause: A specific pattern in the format of a block caused a HRE to be incorrectly reported. The required pattern is that multiple user data blocks must be imbedded in a physical tape block with the last user data block in the physical block exactly ending such that only the entire associated CRC data for that user data spills over into the next physical block on tape. Due to the 8K physical block size in the DLT1 tape format the potential for multiple data blocks being within one physical block is limited as this would require either small user data blocks or data which is highly compressible. With the need for the CRC data to be the first thing in the next physical block, greatly reduces the likely hood of encountering this issue. Corrective Action: Modified the firmware to handle the specific pattern in the block such that the HRE won't be reported and the data will be returned to the customer. Revision V55 A.4.4 Problem Description: There was a small window of time (less than a millisecond) during the start-up of a write operation where the Write Protect switch on the cartridge could be moved to the protected position and the drive would not enable write protected state. The Write Protect light would turn on, but the drive would not reject WRITE commands. Root Cause: The changed write protect status was not passed up to the SCSI task in this window. Corrective Action: Call the global function to enable the write protected status in this state so that SCSI is informed of the status change. A.4.5 Enhancement: Switch from using the SCSI_2 style IDENTIFY message to the SCSI-3 style. The SCSI-3 style message has no LunTar or reserved fields, but instead has a 6 bit LUN field. A.4.6 Problem Description: The SCSI bus will unexpectedly go bus free or timeout when trying to read a tape that had a hard write error during a long erase. A 0xB247 bug check will be logged. Root Cause: A hard write error on a long erased tape could potentially yield a valid EOD where there is none. Corrective Action: Make sure that the EOD that was encountered was not part of the long erase. A.4.7 Problem Description: SPACE forward blocks command takes a very long time to complete when the number of blocks is large. The length of time it takes for a space command to complete is directly proportional to how large of a space is requested. Root Cause: A bug introduced into the code in version V35 caused the firmware to believe there was a filemark in the cache between the current position and the target block. This miscalculation caused the drive to read forward looking for either the filemark or the target block instead of moving directly to the target block. Corrective Action: Fix the comparison in the cache scan routine to correctly detect filemarks. A.4.8 Problem Description: A MODE SELECT command sent with the WRITE DELAY TIME set to zero will cause the next write command to flush data to tape immediately. This caused a drive reset with an event of 0xB0FB bugcheck entered in the drive history log. Root Cause: The flush of data to the tape happened before the data was completely processed. Corrective Action: Only allow a flush if there is data ready in the cache. Disable the cached write data timeout if the WRITE DELAY TIME is set to zero A.4.9 Problem Description: Write commands sent after an auto flush timeout will not auto flush to tape until a drive reset or power cycle of the drive occurs. Root Cause: The Cache flush timer was not being reset after the first flush timeout. Corrective Action: Reset the cache flush timer. A.4.10 Enhancement: An improved resource management scheme allows the drive to no longer report BUSY status when a new command is received while an Immediate or disconnected command is still executing. The new command can allocate necessary resources and be placed in the queue to be executed. As before, if the command is from the same initiator and to the same LUN as a queued command that has not yet sent status, the queued command will be aborted and the new command will return Check Condition with status indicating the overlapped commands condition. A.4.11 Problem Description: A UNIT ATTENTION for a Not Ready to Ready transition may be reported to an initiator if a tape is loaded and then unloaded with no commands sent by that initiator while the device was ready. Root Cause: The UNIT ATTENTION condition is not stripped from the queue for an initiator if it is at the head of the queue when the tape is unloaded. Corrective Action: Fix the routine that strip UNIT ATTENTION conditions to process all items on the queue. A.4.12 Enhancement: Add support for SCSI-3 Logical Unit Reset message. A.4.13 Problem Description: The cleaning light may inadvertently come on during a read operation even though no hard read error actually occurred. Root Cause: There are multiple paths that handle read recovery and each path has it?s own decision point for turning on the cleaning light. One of these paths was erroneously setting the cleaning light even if no hard read error was encountered. Corrective Action: The decision point for turning on the cleaning light was consolidated to one point for all of the read recovery paths. A.4.14 Problem Description: If a format is selected that differs from what is written on the tape, an ERASE command will go bus free or timeout. A B09E bug check will be logged. Root Cause: The firmware wasn't setting up internal data structure properly for the erase. Corrective Action: Changed the firmware to setup the internal data structures properly. A.4.15 Problem Description: When performing a retry after an ECC failure during a read command the drive may unexpectedly go bus free or timeout. A 0xE026 bug check will be logged. Root Cause: During a retry operation, firmware data structures were not being freed properly. Corrective Action: Changed the firmware to free the data structures properly. A.4.16 Problem Description: When pushing the eject button the cartridge sometimes won't come out. Root Cause: As part of the unload process the directory must be written, if this process fails the cartridge will be stuck in the drive until power cycle. Corrective Action: Changed the code such that the directory failure will only set a tape alert flag and continue with the unload. A.4.17 Problem Description: A BUCKLE ERROR on a Code Update(CUP) Tape load caused a drive reset. Root Cause: The internal load command for the CUP tape did not handle Load Failure status. Corrective Action: Load Failure status is handled correctly for a CUP tape. A.4.18 Enhancement: Log Pages 02/03 ? Added parameter 8002h: The dropout component of the raw error count (parameter 8001h). Log Page 3E ? Added parameters: 06h: MediaID of the current tape 07h: Controller serial number 08h: Number of times the drive has been cleaned 09h: Serial number of the first drive to write the current tape 0Ah: Serial number of the last drive to write the current tape A.4.19 Enhancement: Added event 0xA505 to log CAF failures to HS logs. Cal status, cal fail flags, retry sequence, and magnetic to optical offsets are logged if CAF or Servo cal failed. A.4.20 Problem Description: When reading a DLT1 tape, the drive may erroneously report a hard read error (03,11,00). Root Cause: A case in which only the CRC from the previous block is found in the current block and the previous physical block contained more than one logical block caused a hard read error to be reported. Corrective Action: Changed firmware to correctly handle the CRC residing outside the physical block containing the data. A.4.21 Problem Description: Negative residual count is returned following a Check Condition on a SPACE reverse command when SCSI-3 mode is enabled. Root Cause: Residual count was SCSI-2 style. Corrective Action: Report positive residual counts only following a Check Condition on a SPACE command when SCSI-3 mode is enabled. A.4.22 Enhancement: Added Re-Write CAF from BOT (RWCB) flag to the vendor unique mode select page. Using a mode select command this flag will be set and the CAF/FAF fields will be re-written on the next write from BOT. Note: This flag must be set after the cartridge is loaded. A.4.23 Problem Description: A SCSI LOAD command may disconnect and never reconnect during tape insertion. Root Cause: There is a small time window (less than 2 seconds) during the internal tape load process that may cause a SCSI LOAD command to not complete. Corrective Action: Internally queue SCSI LOAD commands until the internal load command completes. A.4.24 Enhancement: Support has been added for Tape Alert Flag 17 - "You have loaded a cartridge of a type that is read-only in this drive. The cartridge will appear as writeprotected." This flag is set whenever an attempt is made to write a Type IV media. Tape Alert Flag 9 will no longer be set in this situation. A.4.25 Problem Description: A SDLT320 drive would accept a firmware image too old to support the SDLT320 hardware, rendering the drive unusable. Root Cause: There was no check in Code Update to verify that the new code image would support the hardware the code would be running on. Corrective Action: A check was added to fail Code Update if the new code image would not support the hardware. Code versions below V45 will not be allowed in SDLT320 drives. A.4.26 Problem Description: If a read of the very first block on tape or the first block on a space operation failed for a no sync mark found condition the drive will go unexpectedly bus free or timeout. The drive will log a 0xB29F to the history log. Root Cause: When encountering a no sync mark found in the above cases, the wrong data was used to position the tape causing the bugcheck. Corrective Action: Fixed the first block processing to handle the error condition properly A.4.27 Problem Description: After a hard write error, when additional writes have filled the data buffer, the drive disconnects. Once the error retries complete, the drive reselects, disconnects, reselects again, and sends Check Condition status. The extra reselection and disconnection should not occur. Root Cause: Communication between the microprocessor and the SCSI controller left an ambiguity in which process was supposed to send status. Corrective Action: The SCSI controller microcode was corrected so it will not perform this additional reselection if the microprocessor has indicated that it should not send status. A.4.28 Problem Description: Mode Select with an SDLT320 Density Code sent to an SDLT220 drive would succeed, but a subsequent Write would fail with Sense Data indicating Incompatible Media. Root Cause: The drives generally accept any Density Code in a Mode Select. If the code is not valid, the drive writes its default density. The 320 format on a 220 drive is the only instance of a format code that is valid for a cartridge but not valid for the drive. Corrective Action: Mode Select with an SDLT320 Density Code sent to an SDLT220 drive will now fail with Sense Data indicating Illegal Request (5,26,02). A.4.29 Enhancement: ScsiResRelNOP EEROM parameter now accessible over SCSI via Mode Select page 3E. A.4.30 Problem Description: WRITE FILEMARK command with the length of zero with a BRC tape at EOT returns volume overflow status. This causes failures while reading the Veritas BUE catalog with non-writable media. Root Cause: This is correct SCSI behavior, but an exception needed to be made for Veritas use of WRITE FILEMARK command. Corrective Action: A WRITE FILEMARK command with zero length at EOT will now be a no-op and return goodstatus. A.4.31 Problem Description: The cleaning light may come on towards the beginning or end of tape after a write error occurs because of a TServo error (3,52,00). Root Cause: There was no check towards the beginning or end of tape to indicate that the cleaning light should be turned on. Corrective Action: Put in a check to make sure that the cleaning light comes on only when cleaning the drive will address the error condition encountered. A.4.32 Problem Description: Processing of a media access command while the drive was not ready could produce a check condition status and no sense data. Root Cause: Wrong status was being returned on media access commands that were queued to be processed after the state of the media changed. Corrective Action: Return the correct status on failed media access commands A.4.33 Problem Description: A Log Select command with both PCR and SP set to 1 was executing the parameter reset and returning GOOD status. Root Cause: The firmware was not testing for this condition. Corrective Action: Added a test for this condition to the Log Select validation code. A.4.34 Enhancement: The Report Density Support command no longer reports the secondary density codes. The drives still support them. A.4.35 Problem Description: Aborting a SCSI REWIND command after writing and during the data flush that is triggered by the REWIND can cause an unexpected bus free condition with a 0xC427 bugcheck log entry. Root Cause: After receiving the abort, only part of the drive firmware was taken out of write mode but not the rest of the system. Corrective Action: If a media access command gets aborted and the firmware had been in write mode, then the system will be set back to write mode to allow the abort process to complete successfully. A.4.36 Problem Description: While in BRC (Backward Read Compatible) mode and no rewind command is issued after the cartridge load, the SCSI bus goes bus free with a 0xB29F Bugcheck log entry. Root Cause: After the BRC cartridge type detection, the servo processor is at a different track than the policy processor assumes. Corrective Action: The read command issued to the servo processor now gives the correct start position. A.4.37 Problem Description: Multiple SCSI bus resets may cause a hang condition resulting in a drive reset. Root Cause: Additional SCSI bus resets while flushing data may cause the flush command to be aborted. Corrective Action: No longer allow any internal flush commands to be aborted. A.4.38 Problem Description: In Report Density Support, we were reporting one of the SDLT220 formats to have capacity 160GB instead of 110GB. Root Cause: The wrong constant was in the table where the capacity is read. Corrective Action: The table now has the correct value and we report the correct capacity for all supported formats in Report Density Support. A.4.39 Problem Description: Request Sense was reporting incorrect values in the tape remaining field. Root Cause: For SDLT320 formatted carts we were using a 4k block size to calculate tape remaining instead of a 6k block size. Corrective Action: We now use a 6k block size to calculate tape remaining and a SDLT320 formatted cart will report 160GB remaining when at BOT. A.4.40 Problem Description: A calibration failure on a drive requesting cleaning erroneously returns (03,52,17) which is an invalid sense data. Root Cause: An OR operation is being performed on the ASC/ASCQ fields of a calibration error (03,52,00) and the cleaning requested sense data (03,00,17) resulted in the drive reporting (03,52,17). Corrective Action: The drive will now report the correct SK,ASC,ASCQ ? (03,00,17) Cleaning requested. A.4.41 Problem Description: If we detect a whirr (supply motor turning but no tape movement) when engaging the supply motor we fail with a drive error, which does not allow the tape to be removed. Root Cause: The whirring case is treated the same as any case where the supply motor moves excessively when we attempt to retract the tape and snug the buckle into the cartridge. Corrective Action: If we detect a whirr condition, and the drive is sure that the tape has not moved out of the cartridge, we will now declare that as a load failure case (as for misbuckling) and allow an eject to be requested. A.4.42 Problem Description: On the first load after power-on, the drive may fail to load tape and the reels do not move. Root Cause: Digital to analog converters (DAC) controlling the reel motors are not initialized by the firmware if a SRAM location that controls the DAC contains a value of 0x01 upon power up. This issue was introduced in the V40 firmware. Corrective Action: Removed the dependency on the RAM value for initializing the DAC. This causes the DAC always to be initialized properly. A.4.43 Problem Description: Backward read cartridge types might be detected incorrectly during load. Root Cause: Tape speed variation during the load causes an error in the pack diameter calculation and thus the tape thickness calculation. Tape thickness is one of the BRC cartridge type determiners. Corrective Action: Compensate the diameter measurement for tape speed variation and produce a more accurate measurement. Use the distance to BOT hole as a cross check for cartridge type. A.4.44 Problem Description: Servo EEROM may fail beyond 6 years, which is not up to MTBF for product. Root Cause: The part is only specified to 1,000,000 writes per byte. The most frequent updates may consume those at around 6 years continuous operation. Corrective Action: Move variables to new locations in the EEROM, if the old location burns out. A.4.45 Problem Description: Changes requested through the library port to turn compression on or off were not changing the compression value. Root Cause: The library command was not calling the compression update function. Corrective Action: Library and Loader requests to change the compression state now calls the update function. A.4.46 Enhancement: Added a routine to the loader LUN command processing to validate support for the UNLOAD command. This command unloads the loader magazines. A.4.47 Enhancement: Added notification to the loader if the host changes compression via a mode select or setting of the EEPROM parameter FORCECOMP. A.4.48 Enhancement: We now read the reserved bytes 41-45 of the response to the Loader Inquiry Data and report them to the host in the previously reserved bytes 36-40 in the SCSI loader standard Inquiry Data. Additionally we report the personality for all code personalities. A.4.49 Problem Description: Overlapped commands from the loader to the drive are not rejected. Root Cause: The overlapped command condition was not being detected. Corrective Action: Keep track of outstanding commands to the drive from the loader and fail when overlapped commands are detected. A.4.50 Problem Description: BUCKLE FAILURE (Load failure) on the loader also set the HARDWARE ERROR bit. Root Cause: Calling the function to set the HARDWARE ERROR bit on the return status of LOAD FAIL. Corrective Action: No longer changing the state of the HARDWARE ERROR bit on a LOAD FAILURE. A.4.51 Problem Description: BUCKLE FAILURE (Load failure) also sets the HARDWARE ERROR bit in the library status. In some applications this could inhibit the library error recovery. Root Cause: Calling the function to set the HARDWARE ERROR bit on the return status of LOAD FAIL. Corrective Action: The firmware no longer changes the state of the HARDWARE ERROR bit on a LOAD FAILURE. Revision V56 A.4.52 Enhancement: Due to the unanticipated side effect of every load of a blank tape to log a 0xA505 event the following enhancement which was added in V55 is being removed. [6.16 Enhancement Added event 0xA505 to log CAF failures to HS logs. Cal status, cal fail flags, retry sequence, and magnetic to optical offsets are logged if CAF or Servo cal failed.] A.4.53 Problem Description: A Read command after an Erase from Beginning Of Tape (BOT) returns data instead of blank tape condition if the Erase command is issued after the read ahead has loaded data into the cache. Root Cause: The Erase command was not clearing the cache data causing the Read command to send what it thought was valid data. This error was created in V55. Corrective Action: The cache is cleared before every Erase command. A.4.54 Problem Description: A read command can take up to 18 minutes to declare an error if the previous write of the cartridge failed with an invalid FAF1 or CAF. Root Cause: The drive uses a full set of retries to try to find data that is not there. Corrective Action: If the directory indicates that there are invalid CAF or FAF1 fields or where the directory incorrectly indicates valid CAF and FAF1 fields but no user data has been written, limit the number of retries. Blank Tape will be declared in less than 3 minutes if there is no data found. A.4.55 Problem Description: After a hard write error followed by a rewind, the SCSI goes bus free and a C926 is logged. Root Cause: A partial entity was not being flushed out of cache correctly after the HWE. Corrective Action: At the end of the flush after HWE, we make sure that if we have a partial entity, that it gets flushed correctly as well. A.4.56 Problem Description: Writing small blocks of data (less than 32 bytes) and toggling compression on and off between blocks may cause incorrect data to be returned on a subsequent read command. Root Cause: There is a small window caused by the small blocks in the pipeline where a block can be incorrectly labeled with the wrong compression state. Corrective Action: The compression state is now attached to the block as it travels through the stages. The state of compression is only changed at block processing boundaries. A.4.57 Enhancement: Added an EEROM option called Mod4BlockSize which causes the drive to check the Block Size field in the Block Descriptor of MODE SELECT commands and verify it is a multiple of 4. A.4.58 Problem Description: CUP from V46 code to V55 in library environment may cause the drive to operate in short tape mode if the drive does not get power cycled after the CUP. Root Cause: Removal of a firmware reboot protected RAM variable caused a shift in memory and the short track mode for library would be set. Corrective Action: Added a placeholder variable to retain the variable locations in the reset-protected RAM. A.4.59 Problem Description: The drive would sometimes report a hardware error in the library status packet and then clear the error based on a successful retry. Root Cause: The library status logic was looking directly at the physical state of the drive rather than letting the physical-side tell it explicitly when a hardware error had occurred. Corrective Action: The physical-side now directly indicates when a hardware error has occurred, and hardware errors should no longer be reported unless they are something that requires user intervention. Revision V59 A.4.60 Enhancement: (T57-1, CQ3304) Added parameter 0x8003 to Log Pages 02 (Write Errors) and 03 (Read Errors). The new parameter contains a raw count of Tracking Servo errors. A.4.61 Enhancement: (T57-3, CQ3331) The cleaning LED will now extinguish if there is a successful calibration on a tape after reloading of a cartridge. This makes the SDLT drive operation consistent with the DLT 8000 drive. A.4.62 Problem Description: (T57-1, ST1548) Drive errors could occur if the drive is powered on with a cartridge in place. Root Cause: An incorrect value for the position of the head actuator was being loaded from the servo EEPROM. Corrective Action: Fix an error in the directory of the servo EEPROM A.4.63 Enhancement: (T59-1, ST1550) Added capability to eject the cartridge after error conditions if there is no chance of damaging the cartridge or the media. A.4.64 Problem Description: (T59-1, ST1549) Drive could drop the leader when unbuckling. Root Cause: The eject currents on the reel motors could be below the stall current and not provide enough tension causing the leader to be dropped. Corrective Action: Increase the eject current. Revision V70 A.4.65 Enhancement: Support has been added for EMAM. This includes support for the Read Attributes and Write Attributes SCSI commands. See EMAM specification for further details. A.4.66 Problem Description: When the EEROM option EnaCheckDenOnWr was set, the drive would sometimes erroneously report invalid medium type on a write command after SCSI reset. Root Cause: The drive did not clear a stored density that was selected before the SCSI reset. Corrective Action: The EnaCheckDenOnWr EEROM option has been removed because all cases that would have possibly allowed the drive to try and write an invalid density have been resolved. A.4.67 Enhancement: Added an EEROM option called Mod4BlockSize with cause the drive to check the Block Size field in the Block Descriptor of MODE SELECT commands and verify it is a multiple of 4. A.4.68 Problem Description: After an HWE, a subsequent Rewind command causes a BugCheck C926. Root Cause: A partial entity was not being flushed out of cache correctly after the HWE. Corrective Action: At the end of the flush after HWE, we make sure that if we have a partial entity, that it gets flushed correctly as well. A.4.69 Problem Description: After completing message traffic introduced by setting attention during a reconnection sequence on a READ or WRITE command, the drive would send status instead of transferring more data, even if more data was required. Root Cause: The fact that more data was required for the command was not checked after completing the reselection process if other message traffic had occurred. Corrective Action: Once the reselect process is complete, check for more data to transfer. A.4.70 Problem Description: If six Mode Selects are sent to the drive without delay between commands during a cleaning cycle, the SCSI bus goes bus free and a B80D is logged. Root Cause: We allowed multiple identical commands to be queued up. Corrective Action: We no longer allow multiple identical commands to be queued up. As a result, we also no longer change the density LED while a cleaning tape is in the drive since it really has no meaning at that time. A.4.71 Problem Description: A read command can take up to 18 minutes to declare an error if the previous write of the cartridge failed with an invalid FAF1 or CAF. Root Cause: The drive uses a full set of retries to try to find data that is not there. Corrective Action: If the directory indicates that there are invalid CAF or FAF1 fields or where the directory incorrectly indicates valid CAF and FAF1 fields but no user data has been written, limit the number of retries. Blank Tape will be declared in under 3 minutes if there is no data found. A.4.72 Enhancement: Due to the unanticipated side effect of every load of a blank tape to log a 0xA505 event, the following enhancement which was added in V55 is being removed. [6.16 Enhancement Added event 0xA505 to log CAF failures to HS logs. Cal status, cal fail flags, retry sequence, and magnetic to optical offsets are logged if CAF or Servo cal failed.] A.4.73 Problem Description: Writing small blocks of data (less than 32 bytes) and toggling compression on and off between blocks may cause incorrect data to be returned on a subsequent read command. Root Cause: There is a small window caused by the small blocks in the pipeline where a block can be incorrectly labeled with the wrong compression state. Corrective Action: The compression state is now attached to the block as it travels through the stages. The state of compression is only changed at block processing boundaries. A.4.74 Problem Description: An odd byte, tape read on a wide SCSI bus would transfer all but the last byte of data and hang. This could occur only if the last 4 bytes of the data were in the next data block on the tape and in a different envelope. Root Cause: The processing of the CRC bytes in the next data block caused a delay in the movement of the last few remaining bytes of data into the SCSI FIFO which caused the transfer to stop. Corrective Action: Do not start the transfer until all of the data is present. A.4.75 Enhancement: Added support for protocol specific Mode pages 0x18 and 0x19. These pages are needed to support the fibre channel interface. A.4.76 Problem Description: The tape remaining value in the Request Sense data reports a value that is low while on the first track of data. The tape remaining value is correctly adjusted using actual block counts after writing the first track. Root Cause: The table containing the initial number of blocks per track had a value that was too low and did not match the capacity of the tape format. Corrective Action: Adjust the initial values in the table to match the drive specifications. A.4.77 Problem Description: The drive will report ready after recovering from an internal error, but it is not calibrated and will error on subsequent write or read commands. Root Cause: The drive was not calibrated as part of the internal recovery. Corrective Action: Calibration is done as part of the internal recovery process. A.4.78 Enhancement: Added a parameter 0x8003 for TServo errors to Log pages 2 and 3. This parameter contains the raw count of tracking servo errors. A.4.79 Problem Description: After spacing or locating to a position and getting a hard read error on the first logical block, the SCSI goes bus free and a C346 is logged. Root Cause: A variable used by the read error processing code was not initialized properly. Corrective Action: Initialize the variable before use. A.4.80 Enhancement: For compatibility with SCSI-3, support is added for the Hold bit in the Load/Unload command and added support for the AutoLoad Mode field in Mode page 0x0A. A.4.81 Problem Description: A Disconnect message was sent by the drive before the Identify message on reselection if the Initiator had reported a message parity error on the previous disconnect sequence. Root Cause: The disconnect message remained in the SCSI chip FIFO and was automatically sent at reconnection. Corrective Action: Clear the FIFO before starting the reselection sequence. A.4.82 Enhancement: Optimized the ECC error correction processing speed. Reading tapes with high errors rates can have up to a 7 times improvement in throughput. A.4.83 Problem Description: The tape format in logical side could change as the drive loads and calibrates BRC media which could create structures with incorrect tape formats. Root Cause: The BTH (Before The Hole) directory on BRC tapes is in a different format than the rest of the tape and could be construed in logical side as the actual tape format. Corrective Action: The tape format will now be reported as unknown until the load has completed. A.4.84 Enhancement: The cleaning LED will now extinguish if there is a successful calibration on a tape. This makes the SDLT drive operation consistent with the DLT 8000 drive. A.4.85 Problem Description: A Read command after an Erase from Beginning Of Tape (BOT) returns data instead of blank tape condition if the Erase command is issued after the read ahead has loaded data into the cache. Root Cause: The Erase command was not clearing the cache data causing the Read command to send what it thought was valid data. This error was created in V55. Corrective Action: The cache is cleared before every Erase command. A.4.86 Problem Description: After a HRE during a Locate command, a subsequent Space BKWD command will BugCheck E01F because the released bad block would be attempted to be released a 2nd time. Root Cause: The released bad block which created the HRE is attempted to be released a 2nd time. Corrective Action: Don't release it the 2nd time. A.4.87 Problem Description: For pre-V55 firmware, a long delay may occur on a cartridge unload due to internal recoveries prior to the drive posting a A503 (subcode 67) event in the history log and then reporting command complete. For V55 and V56 firmware revisions there may be a long delay followed by the posting of the A503 (subcode 67) event in the history log and then generating a Bug Check 0xA21D which causes the drive to reset itself. The delay before reporting the A503 event is approximately 5-6 minutes. This could result in the Host Bus Adapter timing out and issuing a reset to the drive. Root Cause: The last recovery in the rewind operation associated with an unload command is to reset the servo processor. If this recovery succeeds, the tape ends up at the buckle point instead of at BOT. The firmware was erroneously expecting the tape to be at BOT after this reset which caused an inconsistent state in the firmware. Resolving this inconsistent state caused the 5-6 minute delay. Due to a change in the interface between servo and controller code which was introduced in V55, V55 and V56 resulted in the drive bug checking which the previous codes had not. Corrective Action: Check for the correct completion state of the unload command following a servo reset. Drive will reconnect following successfully recovery and will not generate Bug Check 0xA21D in these situations. A.4.88 Problem Description: A tape with a marginal CAF could result in a BugCheck B4AB. Root Cause: There is an unexpected state during calibration in CAF not being handled correctly. Corrective Action: Set a global calibration failure flag. A.4.89 Problem Description: Code Downloads to the loader LUN failed. Root Cause: Checking an incorrect field in the control structure. Corrective Action: Check the correct saved LUN. A.4.90 Enhancement: Implemented the level 1 diagnostic. This diagnostic has 4 parts: Checks ROM EDC, OS queuing, cache interface, and servo status. Also implemented the receive diagnostic results command which reports the status of the level 1 and level 2 diagnostics. A.4.91 Problem Description: After a dropped leader occurs, if the drive is reset it hangs at the end of POST. Root Cause: In reestablishing the dropped leader error condition, we were using an uninitialized resource and causing a hang. Corrective Action: Check When we reestablish an error condition after reset, we will no longer use uninitialized resources. A.4.92 Problem Description: If the drive is in the misbuckled state as a result of a buckle failure and the drive is reset or power cycled, the tape will be stuck in the drive. Root Cause: Drive could not remember the state of the cartridge through a power cycle. Corrective Action: The drive will remember the state of the tape through power loss by saving the state in the EEPROM. This information is used to allow an unload of the cartridge when the drive powers up. A.4.93 Problem Description: The drive was failing the media sensor POST as a result of the media type stored in the EEPROM not matching the media sensor state. Root Cause: An entry in the EEPROM was set to the size of a char (8 bit) instead of a short (16 bit) resulting in an invalid EEPROM directory entry. Corrective Action: Made the size of the entry a short. A.4.94 Problem Description: In the new functionality of Log Pages 2&3, drives record CAF write tservo errors as read errors instead of write errors. Root Cause: The macro that controls whether to select read or write for several parameters always selected read for CAF. Corrective Action: Add the case for CAF seeks to the macro that selects between read and write. A.4.95 Problem Description: Some drives make an audible noise from the head lift mechanism for several seconds following power on. Also, drive errors could occur when attempting to establish communication via the library interface if the drive is powered on with a cartridge in place with tape wound onto the take-up reel. Neither condition results in damage to the drive or media and does not impact other drive functions. Root Cause: An incorrect value for the position of the head actuator was being loaded from the servo EEPROM. Corrective Action: Fix an error in the directory of the servo EEPROM. A.4.96 Problem Description: Drive could drop the leader when unbuckling (8D #179). Root Cause: The eject currents on the reel motors could be below the stall current and not provide enough tension, resulting in unbuckle failures and dropped leaders. Corrective Action: Increase the reel motor currents during eject to maintain optimal leader tension during unbuckle. A.4.97 Problem Description: The drive would sometimes report a hardware error in the library status packet and then clear the error based on a successful retry. Root Cause: The library status logic was looking directly at the physical state of the drive rather than letting the physical side tell it explicitly when a hardware error had occurred. Corrective Action: The physical side now directly indicates when a hardware error has occurred, and hardware errors should no longer be reported unless they are something that requires user intervention. A.4.98 Problem Description: The tape format in library port could change as the drive loads and calibrates BRC media which could create structures with incorrect tape formats. Root Cause: The BTH (Before The Hole) directory on BRC tapes is in a different format than the rest of the tape and could be construed in logical side as the actual tape format. Corrective Action: The tape format will now be reported as unknown until the load has completed. A.4.99 Problem Description: Not ready to ready Unit Attention is reported on the drive LUN but not the loader LUN on a SCSI bus reset. Root Cause: No check was being made to determine if this UA should be sent. Corrective Action: When the drive sees a SCSI bus reset, it looks at its stored status for the loader in order to determine if the loader was previously in a ready state. If so, the drive will queue a not ready to ready UA on the Loader LUN. A.4.100 Problem Description: Code update from V46 code to V55 in a library environment will cause the drive to operate in short tape mode if the drive does not get power cycled after the code update. Root Cause: Removal of a firmware reboot protected RAM variable caused a shift in memory and the short track mode for library would be set. Corrective Action: Added a placeholder variable to retain the variable locations in the reset-protected RAM. A.4.101 Problem Description: In a loader environment, if the loader updated its code via FTP but did not update the drive, the INQUIRY data for the loader did not get updated to new revision number. Root Cause: On a Loader only CUP via FTP, the drive was not reset and therefore did not request new INQUIRY data. Corrective Action: On transport layer resets, the drive will automatically ask for new INQUIRY data. A.4.102 Problem Description: MChngr bit in standard INQUIRY was set when the drive was mounted in a library or loader and SCSI-3 mode was enabled. Root Cause: SCSI Standard misinterpretation. Corrective Action: Never set the MChngr bit since the SDLT drive does not support attached medium changer commands. A.4.103 Enhancement: Added a new SDLT Library command, SendTServoErrors [0x28]. The data returned will include all read and write TServo errors as well as the read and write bytes processed. See SuperDLTtape Interactive Library Interface Specification, Rev F for more detail. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ B.0 Precautionary Statements ----------------------------- **WARNING:****WARNING:****WARNING:****WARNING:****WARNING:****WARNING:** B.1 The system MUST BE IDLE during the firmware download process! No other programs should be running while this utility is being used. Failure to do so may cause the devices being upgraded to fail or the system to crash. Any other computers sharing the same I/O bus as the host system must be either disconnected or offline. B.2 If any upgrade failures occur, do not continue upgrading devices. For example, loss of power during download will result in damaged peripherals and require replacement. If any failures occur, please collect the following log file: "/var/adm/messages", and an explorer dump. Please forward these files to your service provider for analysis. B.3 This package will only function on Quantum SDLT220/320 SCSI Tape Drives which were shipped/used in Sun StorEdge L25/L100 Tape Libraries. B.4 Please READ instructions below completely BEFORE starting download procedure. Follow the procedures carefully. You may program multiple drives at the same time, however, you may not exit the utility until all drives have completed the download process. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C.0 Patch Installation and Utility Usage Intructions ----------------------------------------------------- C.1 General guidelines for upgrading: EJECT MEDIA FROM DEVICE TO BE UPGRADED. Download utility will eject media from the device if it is found to be loaded. Do NOT attempt to force media back into the drive. Media present in a device having firmware downloaded to the device may result in data loss from media or damage to device. STOP ALL APPLICATIONS. The system must be idle during the firmware upgrade process. DISCONNECT or take OFFLINE any other computers sharing the same I/O bus as the host. UPGRADE the tape device. Follow the given instructions in the procedure section below. In case of any disruption or unforeseen events happening on the relevant bus during the firmware download process, it may be that the upgraded device becomes non-functional. In this event, it will be necessary to replace the device. This would happen as a result of an incomplete or corrupted firmware file being downloaded. Loss of power during the upgrade process would also damage the device. **NOTE** If you cannot upgrade devices due to software application interference, try booting off of the Solaris release CD. **NOTE** After the firmware download is completed, it may be necessary to power cycle the device to ensure fully resetting the device. In turn, this may also require a successive reboot of the host system to ensure all functionality is restored. C.2 Procedure for Tape Firmware Download: The procedure to be used for upgrading the device's firmware is explained below. Upgrade time will be approximately 3-5 minutes for each device. You must have root/super-user privileges in order to perform this operation. a). Unpack the patch (through tar) into any directory, e.g. /var/spool/patch (Note, if the patch ends in a ".Z" suffix, you will need to first uncompress it.) Example: # uncompress # tar xvf b). In the patch directory, as root, type the "tload_5.0" command: # ./tload_5.0 SDLTv70lib.img c). Select the tape device to be upgraded (see example below). **NOTE** This upgrade can result in error messages in the console window and/or the terminal "tload_5.0" window. It is normal for a SCSI bus reset message to appear in the console window for each device that is upgraded. d). Ensure that the device to be upgraded is the correct one and answer the question: Do you want to download firmware to this tape device [N]? with a 'y' for yes or anything else for no. Default answer is no. e). After each device has been upgraded, the displayed tape device list will be refreshed. Device(s) upgraded should reflect having the new code level, "4646", in the "Rev" field (see example below). f). If there is an additional device to be upgraded (same device type and desire to upgrade to the latest firmware), select that device as previously done in C.2.c). & C.2.d). above. Continue in this fashion until all desired devices have been upgraded. g). Quit the "tload_5.0" program by typing '0' (see example below). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C.3 EXAMPLE # ######################################### # # Launch Tape Firmware Download Utility # ######################################### # # ./tload_5.0 SDLTv70lib.img ATTACHED DEVICES: Device Supplier Product Rev Serial Number Device State -------------- -------- ---------------- ---- ------------- ------------- 1:0ln QUANTUM SDLT320 2E2E PMC23Y1251 Available 2:02n QUANTUM SDLT320 2E2E PMC23Y1283 Available Select Device(s) (ex: 1,3-4) or 0 to quit) [1]: 1 01n QUANTUM SDLT320 2E2E PMC23Y1251 Selected Do you want to download firmware to this device [N]? y ATTACHED DEVICES: Device Supplier Product Rev Serial Number Device State -------------- -------- ---------------- ---- ------------- ------------- 1:0ln QUANTUM SDLT320 2E2E PMC23Y1251 Downloading 2:02n QUANTUM SDLT320 2E2E PMC23Y1283 Available Ejecting Tape out of the Tape Drive Downloading /dev/rmt/01n... please wait. ATTACHED DEVICES: Device Supplier Product Rev Serial Number Device State -------------- -------- ---------------- ---- ------------- ------------- 1:01n QUANTUM SDLT320 2E2E PMC23Y1251 Writing Flash 2:02n QUANTUM SDLT320 2E2E PMC23Y1283 Available Select Device(s) (ex: 1,3-4) or 0 to quit) [3]: 0 One or more devices has not yet completed flash update and/or download recovery time. Devices must not be utilized until after this recovery period has expired, or permanent damage may result. This program will release all devices and terminate in 6 minutes. ATTACHED DEVICES: Device Supplier Product Rev Serial Number Device State -------------- -------- ---------------- ---- ------------- ------------- 1:0ln QUANTUM SDLT320 4646 PMC23Y1251 F/W Upgraded 2:02n QUANTUM SDLT320 2E2E PMC23Y1283 Available # # ######################################### # # The example above only upgrades one # device. You do not have to exit with # a "0" and initiate the 'tload_5.0' utility # again. You may continue instead and # directly upgrade the next tape device, # following the same steps as before # for each device until all devices # have been upgraded # ######################################### # # ######################################### # # After devices are upgraded, the Rev # will be 4646 # ######################################### # # ######################################### # # To Quit, enter '0'. System prompt # will return. # ######################################### # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C.4 tload_5.0 (ABOUT THE UTILITY): tload_5.0 - Firmware Download utility for tape drives. SYNOPSIS tload_5.0 [ filename ] [ -v ] filename firmware/microcode filename DESCRIPTION tload_5.0 is an firmware download utility for Sun supported tape devices. If the firmware_file is specified, then it will display the list of tape devices present on the host system and asks the user to select the tape device which is to be upgraded. Only One Tape Device may be upgraded at a time. If the firmware_file is not specified, then it will display the list of tape devices present on the host system along with their FIRMWARE revision levels. The command can be run only as a super-user. DISCLAIMER This utility is ONLY supported for downloading, to Sun supported tape devices, the Sun supported firmware binary (firmware_file) which has officially been released via the official Sun Patch Process. This utility is only supported with the release of firmware (binary) it is bundled with in said patch. Do not attempt to use any other version of 'tload' that may have been acquired previously else device damage may occur. Use only the version provided with this patch, version 5.0 (tload_5.0). Use of tload_5.0 to load non-Sun supported tape devices is at the user's own risk, and is not supported. Use of tload_5.0 to load Sun supported tape devices with firmware NOT bundled with the utility in an officially released Sun Patch is at the user's own risk, and is not supported. PROBLEMS Any problems regarding this utility by the user following proper procedures should be reported to the user's service provider along with the following items: 1) /var/adm/messages file 2) explorer dump 3) tload -v (verbose output) README -- Last modified date: Friday, January 30, 2004