-#if 0
- /*
- * This nasty chop at the problem is not working anymore
- * as we do not adjust the retry count anylonger in order
- * to have a number of retries that avoids I/O errors.
- * The manipulation of the retry count has been removed
- * in favour of a safe tape device handling. We must not
- * sent SCSI commands more than once to a device if no
- * retries are permitted by the high level driver. Generally
- * speaking, it was a mess to change retry counts. So it is
- * fine that this sort of workaround is gone.
- * Then, we had to face a certain number of immediate retries in case of
- * busy and queue full conditions (see below).
- * This is not acceptable
- * for the latter. Queue full conditions are used
- * by devices to indicate to a host that the host can rely
- * on the completion (or timeout) of at least one outstanding
- * command as a suggested trigger for command retries.
- * Busy conditions require a different trigger since
- * no commands are outstanding for that initiator from the
- * devices perspective.
- * The drawback of mapping a queue full condition to a
- * busy condition is the chance of wasting all retries prior
- * to the time when the device indicates that a command
- * rejected due to a queue full condition should be re-driven.
- * This case would lead to unnecessary I/O errors that
- * have to be considered fatal if for example ext3's
- * journaling would be torpedoed by such an avoidable
- * I/O error.
- * So, what issues are there with not mapping a queue-full
- * condition to a busy condition?
- * Due to the 'exclusive LUN'
- * policy enforced by the zSeries FCP channel, this
- * Linux instance is the only initiator with regard to
- * this adapter. It is safe to rely on the information
- * 'don't disturb me now ... and btw. no other commands
- * pending for you' (= queue full) sent by the LU,
- * since no other Linux can use this LUN via this adapter
- * at the same time. If there is a potential race
- * introduced by the FCP channel by not inhibiting Linux A
- * to give up a LU with commands pending while Linux B
- * grabs this LU and sends commands - thus providing
- * an exploit at the 'exclusive LUN' policy - then this
- * issue has to be considered a hardware problem. It should
- * be tracked as such if it really occurs. Even if the
- * FCP Channel spec. begs exploiters to wait for the
- * completion of all request sent to a LU prior to
- * closing this LU connection.
- * This spec. statement in conjunction with
- * the 'exclusive LUN' policy is not consistent design.
- * Another issue is how resource constraints for SCSI commands
- * might be handled by the FCP channel (just guessing for now).
- * If the FCP channel would always map resource constraints,
- * e.g. no free FC exchange ID due to I/O stress caused by
- * other sharing Linux instances, to faked queue-full
- * conditions then this would be a misinterpretation and
- * violation of SCSI standards.
- * If there are SCSI stack races as indicated below
- * then they need to be fixed just there.
- * Providing all issue above are not applicable or will
- * be fixed appropriately, removing the following hack
- * is the right thing to do.
- */
-
- /*
- * Note: This is a rather nasty chop at the problem. We cannot
- * risk adding to the mlqueue however as this will block the
- * device. If it is the last outstanding command for this host
- * it will remain blocked indefinitely. This would be quite possible
- * on the zSeries FCP adapter.
- * Also, there exists a race with scsi_insert_special relying on
- * scsi_request_fn to recalculate some command data which may not
- * happen when q->plugged is true in scsi_request_fn
- */
- if (status_byte(scpnt->result) == QUEUE_FULL) {
- ZFCP_LOG_DEBUG("Changing QUEUE_FULL to BUSY....\n");
- scpnt->result &= ~(QUEUE_FULL << 1);
- scpnt->result |= (BUSY << 1);
- }
-#endif
-