From: Hannes Reinecke <hare@suse.de>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
linux-ide@vger.kernel.org, Jens Axboe <axboe@suse.de>,
Kurt Garloff <garloff@suse.de>
Subject: Re: [PATCH] Fix SATA ATAPI error handling
Date: Fri, 27 May 2005 08:52:38 +0200 [thread overview]
Message-ID: <4296C3B6.3060806@suse.de> (raw)
In-Reply-To: <42969AC8.6070904@pobox.com>
Jeff Garzik wrote:
> Hannes Reinecke wrote:
>> +static void scsi_invoke_strategy_handler(struct Scsi_Host *shost)
>> +{
>> + int rtn;
>> + struct list_head *lh, *lh_sf;
>> + struct scsi_cmnd *scmd;
>> + unsigned long flags;
>> + LIST_HEAD(eh_work_q);
>> + LIST_HEAD(eh_done_q);
>> +
>> + rtn = shost->hostt->eh_strategy_handler(shost);
>> +
>> + spin_lock_irqsave(shost->host_lock, flags);
>> + list_splice_init(&shost->eh_cmd_q, &eh_work_q);
>> + spin_unlock_irqrestore(shost->host_lock, flags);
>> +
>> + SCSI_LOG_ERROR_RECOVERY(1, scsi_eh_prt_fail_stats(shost,
>> &eh_work_q));
>> +
>> + list_for_each_safe(lh, lh_sf, &eh_work_q) {
>> + scmd = list_entry(lh, struct scsi_cmnd, eh_entry);
>> +
>> + if (scsi_eh_eflags_chk(scmd, SCSI_EH_CANCEL_CMD) ||
>> + !SCSI_SENSE_VALID(scmd))
>> + continue;
>> + scmd->retries = scmd->allowed;
>> + scsi_eh_finish_cmd(scmd, &eh_done_q);
>> + }
>> +
>> + if (!list_empty(&eh_work_q))
>> + if (!scsi_eh_abort_cmds(&eh_work_q, &eh_done_q))
>> + scsi_eh_ready_devs(shost, &eh_work_q, &eh_done_q);
>
>
> The scsi_eh_abort_cmds() call doesn't do much, since all calls to
> scsi_try_to_abort_cmd() will fail due to libata's lack of EH abort handler.
>
Yeah, noticed that one, too. Sometimes after I did the patch.
The main point of the patch is that the eh_work_q _has_ to be emptied,
regardless whether we can do something with the command. Otherwise it
will always kick in and try to abort the command.
> The latter code will print "aborting cmd failed" for the command, and
> not much else.
>
You are correct; the correct way of doing things would be to abort the
SATA commands or, failing that, reset the device/bus/adapter.
Only from reading the source I got the impression that the only reset
method is a full bus reset. And the spec only added to the confusion.
So I left it there, as this point was never reached anyway.
After sorting out issue with ATAPI commands not having a proper sense
code (patch by Albert Lee regarding completing a command twice) the
error handler could actually _do_ something with the failed command.
Afterwards all cmds would be removed all command from the queue and
everyone was happy.
Cheers,
Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux AG S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2005-05-27 6:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-23 15:28 [PATCH] Fix SATA ATAPI error handling Hannes Reinecke
2005-05-27 3:58 ` Jeff Garzik
2005-05-27 6:52 ` Hannes Reinecke [this message]
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=4296C3B6.3060806@suse.de \
--to=hare@suse.de \
--cc=axboe@suse.de \
--cc=garloff@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@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).