Bug 676049

Summary:	Valid SCSI Sense data - should it be interpreted/used if the status is not Check Condition?
Product:	Red Hat Enterprise Linux 5	Reporter:	Dwight (Bud) Brown <bubrown>
Component:	kernel	Assignee:	Rob Evers <revers>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.3	CC:	james.leddy, mchristi, thenzl
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-10-24 01:41:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dwight (Bud) Brown 2011-02-08 17:47:41 UTC

Description of problem:
Sense data is utilized if marked valid even when scsi status isn't Check Condition.

There seem to be different interpretations of the scsi standard as far as sense data goes. Within FC response frames at the end of a scsi command there are sense length valid bits which are checked and result in the sense data within the frame being copied into the io sense buffer. This sense buffer has the valid bit set within the first byte of the sense buffer and results in messages such as the following (scsi status was success):

kernel: sdbj: Current: sense key: No Sense
kernel: Add. Sense: Lamp failure

One view is that the returned sense data should never be copied out of the response frame unless the scsi status is Check Condition. Also, if the sense key is No Sense, then the the asc/ascq should be ignored as in the above case (a scanner lamp failure status doesn't make much sense for a disk).

Looking for a consistent interpretation based upon SCSI Standards and upstream that is reflected within the code base.

Version-Release number of selected component (if applicable):

How reproducible:
Seems somewhat random.

Steps to Reproduce:
1.
2.
3.

Actual results:
Returned sense buffers are interpreted based upon the sense length valid bit being set and the sense buffer valid flag in byte0 rather than solely on scsi status resulting in unusual status messages being output (such as lamp failure for a disk).

Expected results:
A consistent interpretation.

Additional info:

Comment 1 Dwight (Bud) Brown 2011-02-08 17:57:34 UTC

According to SAM-4:

"
CHECK CONDITION. This status indicates that sense data has been delivered in the buffer defined by the Sense Data argument to the Execute Command procedure call (see 5.13). Additional actions that are required when CHECK CONDITION status is returned are described in 5.8."

"
5.13 Sense data
Sense data shall be made available by the logical unit in the event that a command terminates with a CHECK CONDITION status or other conditions (e.g., the processing of a REQUEST SENSE command). The format, content, and conditions under which sense data shall be prepared by the logical unit are specified in this standard, SPC-4, the applicable command standard, and the applicable SCSI transport protocol standard.

Sense data associated with an I_T nexus shall be preserved by the logical unit until:
a) the sense data is transferred;
b) a logical unit reset (see 6.3.3) occurs;
c) an I_T nexus loss (see 6.3.4) occurs for the I_T nexus associated with the preserved sense data; or
d) power loss expected (see 6.3.5) occurs.

When a command terminates with a CHECK CONDITION status, sense data shall be returned in the same I_T_L_Q nexus transaction (see 3.1.50) as the CHECK CONDITION status. After the sense data is returned, it shall be cleared except when it is associated with a unit attention condition and the UA_INTLCK_CTRL field in the Control mode page (see SPC-4) contains 10b or 11b.

Completion with sense data in the same I_T_L_Q nexus transaction as a CHECK CONDITION status shall not affect ACA (see 5.9) or the sense data associated with a unit attention condition when the UA_INTLCK_CTRL field contains 10b or 11b."

Is sense data only ever valid on an 02h (Check Condition) scsi status even if the sense length valid bit within the fc response frame is set and there is a valid sense length + byte0 of the sense buffer has the valid bit set? Or is it always trash regardless and should always be ignored except if CC is present as status within the response frame.

What are the "or other conditions" under which valid sense data can be returned, if any, other than 02h/CC?  And if a No Sense sense key is returned, does that mean ASC/ASCQ fields should be ignored?