From: Tejun Heo <htejun@gmail.com>
To: albertl@mail.com
Cc: Jeff Garzik <jgarzik@pobox.com>,
Linux IDE <linux-ide@vger.kernel.org>,
Unicorn Chang <uchang@tw.ibm.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Doug Maxey <dwm@bebe.enoyolf.org>
Subject: Re: libata new EH issue - ATAPI device error not properly reported
Date: Wed, 28 Jun 2006 19:27:22 +0900 [thread overview]
Message-ID: <44A2598A.6040001@gmail.com> (raw)
In-Reply-To: <44A23D76.30307@tw.ibm.com>
Hello, Albert.
Albert Lee wrote:
> Hi Tejun,
>
> Unicorn is doing some test with the current upstream branch and something
> looks strange in the log.
>
> With the new EH, when the ATAPI device reports dev_status 0x51,
> the err_mask is reported as 0x0. This does not look right.
> Maybe we should report AC_ERR_DEV error back to the upper layers?
> (Test log attached for your review.)
>
[--snip--]
> Jun 27 18:10:57 xlinux19 kernel: atapi_qc_complete: ENTER, err_mask 0x0 <== Doesn't look right. Should report error.
The following code block follows the above VPRINTK.
/* handle completion from new EH */
if (unlikely(qc->ap->ops->error_handler &&
(err_mask || qc->flags & ATA_QCFLAG_SENSE_VALID))){
if (!(qc->flags & ATA_QCFLAG_SENSE_VALID)) {
/* FIXME: not quite right; we don't want the
* translation of taskfile registers into a
* sense descriptors, since that's only
* correct for ATA, not ATAPI
*/
ata_gen_ata_desc_sense(qc);
}
qc->scsicmd->result = SAM_STAT_CHECK_CONDITION;
qc->scsidone(cmd);
ata_qc_free(qc);
return;
}
As EH set ATA_QCFLAG_SENSE_VALID after reading sense data the above if
block is executed thus reporting upper layer CHECK_CONDITION. Overall,
the control flow on ATAPI CC is like the following.
1. ATAPI CC occurs
2. AC_ERR_DEV set and EH invoked
3. EH requests sense. sense is stored in the sense buffer and
AC_ERR_DEV is cleared.
4. EH completes the qc and triggers above code block in atapi_qc_complete().
The logic behind clearing AC_ERR_DEV after reading sense data is that
ATAPI CC doesn't always indicate device error. It can indicate
anything. By clearing AC_ERR_DEV after sense data is read, libata EH
considers the error condition is cleared and doesn't perform further
action on the device. If the sense data indicates actual error, upper
layers will probably deal with it (sr driver or userland application).
It might be useful to interpret some of sense data and handle things
like transmission error in libata EH, but I don't know. ATAPI errors
always have been handled by upper layers.
--
tejun
next prev parent reply other threads:[~2006-06-28 10:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 8:27 libata new EH issue - ATAPI device error not properly reported Albert Lee
2006-06-28 10:27 ` Tejun Heo [this message]
2006-06-28 11:03 ` Albert Lee
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=44A2598A.6040001@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=dwm@bebe.enoyolf.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=uchang@tw.ibm.com \
/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).