Re: Aic94xx and Linux kernel 2.6.19

["Darrick J. Wong" <djwong@us.ibm.com>]

Luben Tuikov wrote:

> 3. I never see a crash.  After the transport driver couldn't allocate
>    memory and returned 0xFFFFFFF4 (-ENOMEM), the SATL task is put
>    back on the list of tasks to be executed, task order, NCQ, etc perfectly
>    preserved. (SATL supports NCQ and Full Task Management, btw.)  The second time
>    around* allocation succeeds and the task(s) are executed.  The application
>    client (I/O tester application/whatever, in user space) never detects this,
>    since the task does complete and status is returned to the application client.

Indeed, I had hoped that libata would do a similar thing.  A curious
thing happens, however, when ata_qc_new_init fails to get an ata_queued_cmd:

First, ata_qc_new_init handles the failure like this:
    cmd->result = (DID_OK << 16) | (QUEUE_FULL << 1);
    done(cmd);

Then, we return to ata_scsi_translate and do this:
    err_mem:
        cmd->result = (DID_ERROR << 16);
        done(cmd);

It appears to me (jgarzik, please correct me if I'm wrong) that first we
set a status code indicating that we're ok but the device queue is full
and finish the command,  but then we blow away that status code and
replace it with an error flag and finish the command a second time!
That does not seem to be desirable behavior since we merely want the I/O
to wait until a command slot frees up, not send errors up the block layer.

Perhaps in the err_mem case we should simply exit out of
ata_scsi_translate instead?  I've a quick-and-dirty patch, though I've
not tested it thoroughly yet.

--

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 7af2a4b..5c1fc46 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1612,9 +1612,9 @@ early_finish:

 err_did:
 	ata_qc_free(qc);
-err_mem:
 	cmd->result = (DID_ERROR << 16);
 	done(cmd);
+err_mem:
 	DPRINTK("EXIT - internal\n");
 	return 0;