Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-77-1017351.1
Update Date:2011-03-01
Keywords:

Solution Type  Sun Alert Sure

Solution  1017351.1 :   Sun StorEdge 6920 DSP Firmware May Cause Data Avaiability Issue  


Related Items
  • Sun Storage 6920 System
  •  
Related Categories
  • GCS>Sun Microsystems>Sun Alert>Criteria Category>Availability
  •  
  • GCS>Sun Microsystems>Sun Alert>Release Phase>Resolved
  •  

PreviouslyPublishedAs
228410


Product
Sun StorageTek 6920 System

Bug Id
<SUNBUG: 6451084>

Date of Resolved Release
22-NOV-2006

Impact

On the Sun StorEdge 6920 with Data Services Platform (DSP) firmware 2.2.1.182 installed, "Persistent Reservation" issues may cause DSP panics which could result in storage being unavailable.


Contributing Factors

This issue can occur on the following platform:

  • Sun StorEdge 6920 without DSP firmware patch 118396-52

The following conditions must be present for this issue to occur:

  1. The DSP is running version 2.2.1.182 firmware
  2. Command must be active at the time of the error
  3. Persistent Reservation must be waiting for WRITE DATA to be received
  4. CTIO request must result in an error status
  5. Command must NOT be aborted

Note: The above factors are not readily visible.


Symptoms

The DSP will panic with the following string:

    PANIC!!:  file - isp_target.c  line - 5148
    MED_FREE_BUF - free pr/resv cmd when not finished, xsp = 0xXXXXXXXX

Panic strings first show up on the console and then are recorded in the messages file (and in a core dump, if active).


Workaround

There is no workaround for this issue. Please see the Resolution section below.


Resolution

This issue is addressed on the following platform:

  • Sun StorEdge 6920 with DSP firmware patch 118396-52 or later


References

<SUNPATCH: 118396-52>

Previously Published As
102727
Internal Comments


* "Command" referred to in Contributing Factors is to internal scsi commands, not something that is actively or overtly done by a user (ie: commands that can be found in scsi protocol). Examples would be Read/Write/Open/Close etc.



The problem is only with UBR19 & UBR20. There was new functionality that was added in 19 (and migrated to 20 before it was caught) that caused the problem. The level of DSP code would be 02.02.01.182 is where the problem is. It's fixed in 02.02.01.189. See PTS website for details:



http://pts-storage.west/products/SE6920/baseline_matrix.html


Internal Contributor/submitter
[email protected]

Internal Eng Business Unit Group
NWS (Network Storage)

Internal Eng Responsible Engineer
[email protected]

Internal Services Knowledge Engineer
[email protected]

Internal Escalation ID
1-18423401, 1-18702805, 1-19457830

Internal Resolution Patches
118396-52

Internal Sun Alert Kasp Legacy ID
102727

Internal Sun Alert & FAB Admin Info
Critical Category: Availability ==> Regression
Significant Change Date: 2006-11-22
Avoidance: Upgrade
Responsible Manager: [email protected]
Original Admin Info: [WF 22-Nov-2006, dave m: review completed, send for release]
[WF 20-Nov-2006, dave m: draft created, questions for eng]

Product_uuid
67794720-356d-11d7-8ef2-ce2ac2bc9136|Sun StorageTek 6920 System

References

SUNPATCH:118396-52

Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback