[Bug 243958] New: SLES 9 SP3 mptscsi device driver with IBM's San Volume Controller
https://bugzilla.novell.com/show_bug.cgi?id=243958 Summary: SLES 9 SP3 mptscsi device driver with IBM's San Volume Controller Product: SUSE Linux 10.1 Version: Final Platform: x86 OS/Version: SLES 9 Status: NEW Severity: Major Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: betts@vmware.com QAContact: qa@suse.de This is an bug for SLES 9 SP3 mptscsi device driver. Whey was it filed here? SLES9 is not available in my bugzilla drop down selections. Please refile to appropriate queue if needed. Description: We have been working with IBM on an issue with IBM's San Volume Controller solution with VMware. We identified a change that needs to be made to the mptscsi device driver that ships with the Novell SLES 9 SP3. We have made the change and all tests are running successfully at IBM. Solution: The code change is very minor, see below case MPI_IOCSTATUS_SUCCESS: /* 0x0000 */ + scsi_status = pScsiReply->SCSIStatus; + sc->result = (DID_OK << 16) | scsi_status; - if (scsi_status == MPI_SCSI_STATUS_BUSY) - sc->result = (DID_BUS_BUSY << 16) | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=243958 ------- Comment #1 from betts@vmware.com 2007-02-08 17:58 MST ------- Description of problem: The mptscsi driver in linux version 2.6.9-34 changes a SCSI return status of scsi busy into a SCSI status of host busy and scsi (target) busy before returning the status to the linux I/O stack. Version-Release number of selected component (if applicable): The code change to the mptscsi driver that appends the DID_BUS_BUSY status to the SCSI status was made between linux versions 2.6.9-22 and 2.6.9-34. How reproducible: 100% reproducible Steps to Reproduce: 1. Create a condition where the LSI hardware returns a scsi status of MPI_SCSI_STATUS_BUSY to the driver. This is easy to do runnning SLES 9 SP3 as a virtual machine with the VMware ESX product. 2. The mptscsi driver converts the scsi status of MPI_SCSI_STATUS_BUSY into a host status of DID_BUS_BUSY and a scsi status of MPI_SCSI_STATUS_BUSY. 3. When the SCSI I/O command is returned to the Linux SCSI midlayer with a host status of DID_BUS_BUSY, the command will be retried five times and then if the target continues to return a status of BUSY the I/O command will be marked as failed. If the SCSI I/O command originated within the ext3 file system, the I/O failure will cause the ext3 file system to be marked as read-only. This behavior is different from the mptscsi driver in linux version 2.6.9-22. In the version *22, the mptscsi driver did not append the host status of DID_BUS_BUSY to a SCSI command failure of MPI_SCSI_STATUS_BUSY. Without the host status of DID_BUS_BUSY, the Linux SCSI midlayer will retry the failed I/O command an unlimited number of times. In the case of the ext3 file system, a brief period of busy status from the SCSI target would not cause the file system to be marked read-only. Actual results: When an LSI SCSI device returns a status of target busy for a very brief period of time, I/Os will fail after a few retries. Expected results: When an LSI SCSI device returns a status of target busy for a very brief period of time, I/Os will be retried. Additional info: The problematic change to the mptscsi.c file is in the mptscsih_io_done() routine: case MPI_IOCSTATUS_SUCCESS: /* 0x0000 */ if (scsi_status == MPI_SCSI_STATUS_BUSY) sc->result = (DID_BUS_BUSY << 16) | scsi_status; else sc->result = (DID_OK << 16) | scsi_status; This modification was clearly made for a reason, but it may to be out of compliance with the LSI device specificiation. It is unexpected that a scsi status of BUSY would be treated the same as a host status of busy. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com