Bug 63765 - sg driver problem
sg driver problem
Product: Red Hat Public Beta
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-04-18 11:32 EDT by Joshua Giles
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-24 18:08:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joshua Giles 2002-04-18 11:32:17 EDT
Description of Problem:
The problem is noted here, by the sg driver maintainer: 


Basically, the ide-scsi driver isn't doing what it's supposed to per that note. 
The end result is that an app that uses the sg interface when an IDE device is 
behind it, may not know that errors are occurring on the device. You can try to 
put code in your app that checks the sense buffer, and they then he sg page 
will be updated. However, I still think it would be best if we could drive a 
true fix into the ide-scsi driver.

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

How Reproducible:

Steps to Reproduce:

Actual Results:

Expected Results:

Additional Information:
Comment 1 Larry Woodman 2002-07-30 11:37:30 EDT
The attached URL that describes the probelm is not valid, 
please update with a new/valid URL.

Larry Woodman
Comment 2 Joshua Giles 2002-07-30 12:43:36 EDT
As per note [1] on http://www.torque.net/sg/p/sg_v3_ho/x255.html:
"Some lower level drivers (e.g. ide-scsi) clear this status field even when a 
CHECK_CONDITION or COMMAND_TERMINATED status has occurred. However they do set 
DRIVER_SENSE in driver_status field. Also a (sb_len_wr > 0) indicates there is 
a sense buffer."
Comment 3 Tom Coughlan 2003-01-24 18:08:12 EST
From Issue Tracker 7723 (now closed):

This issue was discussed a few months ago on the linix-scsi mailing list:


In summary, the current behavior of ide-scsi (and the SCSI midlayer) is
plausibly correct.  Therefore, you should write your program to check for
non-zero sense data, rather than rely on the SCSI status to indicate success or

The reason you can not rely on the SCSI status is because some SCSI adapters
(e.g. ide-scsi) do not do autosense.  This means that when a command fails, the
adapter driver returns the failure status to the SCSI midlayer, and the midlayer
must issue a Request Sense command to get the sense data. The Request Sense
command succeeds, and so the midlayer ends up returning good status, with the
sense data for the failed command.  That's ugly, but it is justifiable,
considering the way the SCSI protocol works.  

This problem is solved for ide-scsi in 2.5, because autosense has been added to
ide-scsi.  This means that when a command fails, the ide-scsi driver will do the
Request Sense command on its own, and then return the sense data to the midlayer
at the same time as the status for the failed command.

Note You need to log in before you can comment on or make changes to this bug.