This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 132291 - Discovery of scsi devices with cisco iSCSI initiator linux-iscsi-3.6.0.3 fails
Discovery of scsi devices with cisco iSCSI initiator linux-iscsi-3.6.0.3 fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: iscsi-initiator-utils (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-10 13:43 EDT by Roman
Modified: 2008-04-07 00:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-07 12:29:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Roman 2004-09-10 13:43:46 EDT
I am seeing some compatibility problems between our iscsi native
target implementation (Symmetrix microcode) and Cisco
iscsi initiator on particular Red Hat kernel edition.
Kernel version I am using is:

 - Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
   Kernel 2.4.21-15.ELcustom on an i686

Those issues can be seen at intial discovery of scsi devices
and are ultimately causing already discovered devices to be
inaccessible for I/O (set to offline). After the initial
"Report LUNs" command, discovery for each scsi device follows this
steps:

 1 - Initiator (host) sends "Inquiry" command and target
     responds successfully
 2 - Initiator sends "Test Unit Ready" command and target
     responds with "check condition".
 3 - Initiator sends "Request Sense" command and target
     responds with a sense class "Unit Attention", which
     is correct.

Looking at kernel messages in log file it seems, that
scsi kernel subsystem is working under impression that
received sense data is all zeroes. I traced sense data
buffer path from what was on a link, through cisco initiator
layer to kernel scsi subsystem and I could see valid data
coming all the way to kernel. However when scsi code goes
to process it, it's working with a sense data buffer all
beeing zeroes. The problem/bug I think is in function
scsi_request_sense() (file: scsi_error.c) at the very
end of it. Just before function returns, it is restoring
data of original request together with zeroing, sense data
buffer. This buffer was used to store result of the sense
of sense data request. Offended line I believe is:

>  492    memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));

After this function returns, scsi code goes and investigates
sense data values and it finds everything to be zero.
I removed this call from the code and gave it a try and it
worked for me. I am attaching a file version, we got with
this kernel version (hope this is fine?).
Since it looks such a general bug flaw, it should have bad
consequences with also other scsi storage devices, it makes
 me wonder if I am analyzing my problems correctly.
Comment 1 Doug Ledford 2007-06-07 12:29:47 EDT
RHEL3 is in deep maintenance mode at this point and no further updates, other
than security issues, are planned.  Closing this bug out.  (Not to mention that
I suspect one of the various updates to the iSCSI initiator support during the
RHEL3 lifetime solved the issue anyway)

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