Torsten Kaiser wrote:
On 10/13/07, Torsten Kaiser <just.for.lkml@xxxxxxxxxxxxxx> wrote:
Wait!
I think I found the bug: Its a evil interaction between the above
patch and the swncq patch that is applied later.
The qc_defer patch removes the old ata_scmd_need_defer that was always
called for all drivers and substitutes it for ata_std_qc_defer and
adds it as aops->qc_defer to all drivers that support NCQ *at that
point*.
Then the swncq patch adds a new NCQ capable driver, but the nobody
added the qc_defer-ops to the ops-structure that is added. So swncq
will never defer any commands and the first command that would need to
be defered (the SMART commands) blows up, if there is still another
command in flight.
I will only add the qc_defer and try this...
3 boots, all worked. So I'm very sure that was the bug, but I will now
do a little load testing...
The only strange thing about 2.6.23-mm1 is, that it takes ~4 second
more to boot.
So, you basically applied the attached patch?
Yeah, absence of qc_defer for an NCQ-capable chip would do it.
Jeff
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index cf5c85e..240a892 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -554,6 +554,7 @@ static const struct ata_port_operations nv_swncq_ops = {
.bmdma_start = ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
+ .qc_defer = ata_std_qc_defer,
.qc_prep = nv_swncq_qc_prep,
.qc_issue = nv_swncq_qc_issue,
.freeze = nv_mcp55_freeze,
