[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <45AAE981.60906@shaw.ca>
Date: Sun, 14 Jan 2007 20:40:01 -0600
From: Robert Hancock <hancockr@...w.ca>
To: linux-kernel <linux-kernel@...r.kernel.org>,
linux-ide@...r.kernel.org
Cc: Jeff Garzik <jeff@...zik.org>, Allen Martin <AMartin@...dia.com>
Subject: [PATCH -mm] sata_nv: cleanup ADMA error handling
Should apply to -mm tree or current libata-dev git tree. Sorry for
attaching, but I seem to have misplaced the magic incantations to make
Thunderbird not destroy inline patches..
---
This cleans up a few issues with the error handling in sata_nv in ADMA
mode to make it more consistent with other NCQ-capable drivers like ahci
and sata_sil24:
-When a command failed, we would effectively set AC_ERR_DEV on the
queued command always. In the case of NCQ commands this prevents libata
from doing a log page query to determine the details of the failed
command, since it thinks we've already analyzed. Just set flags in the
port ehi->err_mask, then freeze or abort and let libata figure out what
went wrong.
-The code handled NV_ADMA_STAT_CPBERR as a "really bad error" which
caused it to set error flags on every queued command. I don't know
exactly what this flag means (no docs, grr!) but from what I can guess
from the standard ADMA spec, it just means that one or more of the CPBs
had an error, so we just need to go through and do our normal checks in
this case.
-In the error_handler function the code would always go through and do
an ADMA channel reset and also dump out the state of all the CPBs. This
reset seems heinous in this situation since we haven't even decided to
reset anything yet. The output seems redundant at this point since
libata already dumps the state of all active commands on errors (and it
also triggers at times when it shouldn't, like when suspending). Do the
ADMA reset only on hardreset and remove the output.
Signed-off-by: Robert Hancock <hancockr@...w.ca>
View attachment "sata_nv-cleanup-error-handling.patch" of type "text/plain" (8000 bytes)
Powered by blists - more mailing lists