Bug 132291 - Discovery of scsi devices with cisco iSCSI initiator linux-iscsi-3.6.0.3 fails
Summary: Discovery of scsi devices with cisco iSCSI initiator linux-iscsi-3.6.0.3 fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: iscsi-initiator-utils
Version: 3.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-10 17:43 UTC by Roman
Modified: 2008-04-07 04:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-07 16:29:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Roman 2004-09-10 17:43:46 UTC
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 16:29:47 UTC
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.