Bug 132291
| Summary: | Discovery of scsi devices with cisco iSCSI initiator linux-iscsi-3.6.0.3 fails | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Roman <rgramc> |
| Component: | iscsi-initiator-utils | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-06-07 16:29:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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) |
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.