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
1 - Initiator (host) sends "Inquiry" command and target
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
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.
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)