Mark Lord wrote:
..
[75703.296100] WARNING: at drivers/ata/libata-core.c:4732
ata_qc_issue+0x1ca/0x230 [libata]()
..
That line is this one (linux-2.6.26.2):
WARN_ON(ap->ops->error_handler && ata_tag_valid(link->active_tag));
So this should trigger only when link->active_tag is valid, which
doesn't normally happen.
But the convoluted traceback shows that this code path came from the EH,
so something in libata EH is likely neglecting to clear link->active_tag
before issuing a new command.
Tejun?
..
Mmm.. since it happens only once in a while, and not on every EH action,
one might assume that it's a race of some kind.
One possibility, might be due to .qc_defer.
The stock ata_qc_defer relies heavily on ata_tag_valid(),
which matches what the above WARN_ON uses.
But sata_mv doesn't use ata_tag_valid, because it wants to know
about the entire port and not just a single individual link on the port.
So instead, it uses ap->nr_active_links for the test.
My guess is that these two items are not kept in sync during EH.
Tejun?
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
