From: Mark Lord <liml@rtr.ca>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: IDE/ATA development list <linux-ide@vger.kernel.org>,
Tejun Heo <htejun@gmail.com>
Subject: [PATCH 02/02] sata_mv: warn on PIO with multiple DRQs
Date: Wed, 18 Jun 2008 12:13:02 -0400 [thread overview]
Message-ID: <4859340E.60203@rtr.ca> (raw)
In-Reply-To: <485933A4.3010409@rtr.ca>
Chip errata sometimes prevents reliable use of PIO commands which involve
more than a single DRQ (data request). In normal operation, libata should
not generate such PIO commands (uses DMA instead), but they could be sent
in via SG_IO from userspace.
A full workaround might be to break up such commands into sequences
of single DRQ ones, but that's just way too complex for something
that doesn't normally happen in real life.
So, allow the attempt (it often works, despite the errata),
but log the event for reference when somebody screams.
Signed-off-by: Mark Lord <mlord@pobox.com>
---
Tejun/Alan/Jeff:
We may also want a patch to prevent libata-eh from downshifting
all the way to PIO on these chipsets, but I am not sure how to
accomplish that from inside sata_mv. Any suggestions?
--- old/drivers/ata/sata_mv.c 2008-06-17 19:22:46.000000000 -0400
+++ linux/drivers/ata/sata_mv.c 2008-06-17 19:22:15.000000000 -0400
@@ -1595,6 +1595,24 @@
if ((qc->tf.protocol != ATA_PROT_DMA) &&
(qc->tf.protocol != ATA_PROT_NCQ)) {
+ static int limit_warnings = 10;
+ /*
+ * Errata SATA#16, SATA#24: warn if multiple DRQs expected.
+ *
+ * Someday, we might implement special polling workarounds
+ * for these, but it all seems rather unnecessary since we
+ * normally use only DMA for commands which transfer more
+ * than a single block of data.
+ *
+ * Much of the time, this could just work regardless.
+ * So for now, just log the incident, and allow the attempt.
+ */
+ if (limit_warnings && (qc->nbytes / qc->sect_size) > 1) {
+ --limit_warnings;
+ ata_link_printk(qc->dev->link, KERN_WARNING, DRV_NAME
+ ": attempting PIO w/multiple DRQ: "
+ "this may fail due to h/w errata\n");
+ }
/*
* We're about to send a non-EDMA capable command to the
* port. Turn off EDMA so there won't be problems accessing
next prev parent reply other threads:[~2008-06-18 16:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-18 16:11 [PATCH 01/02] sata_mv: enable async_notify for 60x1 Rev.C0 and higher Mark Lord
2008-06-18 16:13 ` Mark Lord [this message]
2008-06-19 0:29 ` [PATCH 02/02] sata_mv: warn on PIO with multiple DRQs Jeff Garzik
2008-06-19 1:44 ` Mark Lord
2008-06-19 1:48 ` Tejun Heo
2008-06-19 1:56 ` Jeff Garzik
2008-06-19 2:00 ` Mark Lord
2008-06-19 6:28 ` Jeff Garzik
2008-06-19 20:23 ` Mark Lord
2008-06-19 1:57 ` [PATCH] sata_mv: safer logic for limit_warnings Mark Lord
2008-07-04 13:11 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4859340E.60203@rtr.ca \
--to=liml@rtr.ca \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).