public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Mike Anderson <andmike@us.ibm.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH / RFC] scsi_error handler update. (3/4)
Date: 12 Feb 2003 17:34:29 -0500	[thread overview]
Message-ID: <1045087146.1623.11.camel@mulgrave> (raw)
In-Reply-To: <20030211081744.GC1368@beaverton.ibm.com>

On Tue, 2003-02-11 at 03:17, Mike Anderson wrote: 
> This patch series is against scsi-misc-2.5.
> 
> 02_serror-hndlr-1.diff:
> 	- Change to using eh_cmd_list.
> 	- Change scsi_unjam_host to get sense, abort cmds, ready
> 	  devices, and disposition cmds for retry or finish.
> 	- Moved retries outside of eh.
> 
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
> 
>  scsi_error.c |  477 +++++++++++++++++++++++++++++------------------------------
>  1 files changed, 241 insertions(+), 236 deletions(-)
> ------
> 
> diff -Nru a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> --- a/drivers/scsi/scsi_error.c	Mon Feb 10 22:25:47 2003
> +++ b/drivers/scsi/scsi_error.c	Mon Feb 10 22:25:47 2003
> @@ -211,36 +211,36 @@
>   * @sc_list:	List for failed cmds.
>   * @shost:	scsi host being recovered.
>   **/
> -static void scsi_eh_prt_fail_stats(Scsi_Cmnd *sc_list, struct Scsi_Host *shost)
> +static inline void scsi_eh_prt_fail_stats(struct Scsi_Host *shost)
>  {
> -	Scsi_Cmnd *scmd;
> -	Scsi_Device *sdev;
> +	struct scsi_cmnd *scmd;
> +	struct scsi_device *sdev;
>  	int total_failures = 0;
>  	int cmd_failed = 0;
> -	int cmd_timed_out = 0;
> +	int cmd_cancel = 0;
>  	int devices_failed = 0;
>  
>  
>  	list_for_each_entry(sdev, &shost->my_devices, siblings) {
Your eh_list here is per host, so there's no need to loop over all the
devices above. 

> -		for (scmd = sc_list; scmd; scmd = scmd->bh_next) {
> +		list_for_each_entry(scmd, &shost->eh_cmd_list, eh_list) {
>  			if (scmd->device == sdev) {
>  				++total_failures;
>  				if (scsi_eh_eflags_chk(scmd,
[...] 
> -static int scsi_eh_bus_device_reset(Scsi_Cmnd *sc_todo, struct Scsi_Host *shost)
> +static int scsi_eh_bus_device_reset(struct Scsi_Host *shost,
> +				    struct list_head *done_list)
>  {
>  	int rtn;
> -	Scsi_Cmnd *scmd;
> -	Scsi_Device *sdev;
> -
> -	SCSI_LOG_ERROR_RECOVERY(3, printk("%s: Trying BDR\n", __FUNCTION__));
> +	struct list_head *lh, *lh_sf;
> +	struct scsi_cmnd *scmd, *bdr_scmd;
> +	struct scsi_device *sdev;
>  
>  	list_for_each_entry(sdev, &shost->my_devices, siblings) {

Same problem here. 

> -		for (scmd = sc_todo; scmd; scmd = scmd->bh_next)
> -			if ((scmd->device == sdev) &&
> -			    scsi_eh_eflags_chk(scmd, SCSI_EH_CMD_ERR))
> +		bdr_scmd = NULL;
> +		list_for_each_entry(scmd, &shost->eh_cmd_list, eh_list)
> +			if (scmd->device == sdev) {
> +				bdr_scmd = scmd;
>  				break;
[...]
> @@ -1477,6 +1469,8 @@
>  
>  	ASSERT_LOCK(shost->host_lock, 0);
>  
> +	shost->in_recovery = 0;
> +
>  	/*
>  	 * If the door was locked, we need to insert a door lock request
>  	 * onto the head of the SCSI request queue for the device.  There

This is a lot better than we had previously, but still, I think resetting
in_recovery should happen after we've potentially queued door lock commands
on the queue head, since as soon as we reset this, the queue can potentially
be restarted (even without the necessary restart below this in the code).


James


  parent reply	other threads:[~2003-02-12 22:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-11  8:13 [PATCH / RFC] scsi_error handler update. (1/4) Mike Anderson
2003-02-11  8:15 ` [PATCH / RFC] scsi_error handler update. (2/4) Mike Anderson
2003-02-11  8:17   ` [PATCH / RFC] scsi_error handler update. (3/4) Mike Anderson
2003-02-11  8:19     ` [PATCH / RFC] scsi_error handler update. (4/4) Mike Anderson
2003-02-11 22:38     ` [PATCH / RFC] scsi_error handler update. (3/4) James Bottomley
2003-02-12  7:16       ` Mike Anderson
2003-02-12 14:26         ` Luben Tuikov
2003-02-12 14:37         ` James Bottomley
2003-02-12 22:34     ` James Bottomley [this message]
2003-02-13  8:24       ` Mike Anderson
2003-02-11 16:49 ` [PATCH / RFC] scsi_error handler update. (1/4) Luben Tuikov
2003-02-11 17:22   ` Mike Anderson
2003-02-11 19:05     ` Luben Tuikov
2003-02-11 20:14       ` Luben Tuikov
2003-02-11 21:14       ` Mike Anderson
     [not found]       ` <3E495862.3050709@splentec.com>
2003-02-11 21:20         ` Mike Anderson
2003-02-11 21:22           ` Luben Tuikov
2003-02-11 22:41             ` Christoph Hellwig
2003-02-12 20:10               ` Luben Tuikov
2003-02-12 20:46                 ` Christoph Hellwig
2003-02-12 21:23                   ` Mike Anderson
2003-02-12 22:15                     ` Luben Tuikov
2003-02-12 21:46                   ` Luben Tuikov
2003-02-13 15:47                     ` Christoph Hellwig
2003-02-13 18:55                       ` Luben Tuikov
2003-02-14  0:24                         ` Doug Ledford
2003-02-14 16:38                           ` Patrick Mansfield
2003-02-14 16:58                           ` Mike Anderson
2003-02-14 18:50                             ` Doug Ledford
2003-02-14 19:35                             ` Luben Tuikov
2003-02-14 21:20                               ` James Bottomley
2003-02-17 17:20                                 ` Luben Tuikov
2003-02-17 17:58                                   ` James Bottomley
2003-02-17 18:29                                     ` Luben Tuikov
2003-02-18  5:37                                       ` Andre Hedrick
2003-02-18 19:46                                         ` Luben Tuikov
2003-02-18 22:16                                           ` Andre Hedrick
2003-02-18 23:35                                             ` Luben Tuikov
2003-02-17 20:17                                   ` Doug Ledford
2003-02-17 20:19                                     ` Matthew Jacob
2003-02-17 21:12                                     ` Luben Tuikov
2003-02-17 17:35                                 ` Luben Tuikov
2003-02-14 21:27                               ` James Bottomley
2003-02-17 17:28                                 ` Luben Tuikov
2003-02-16  4:23                               ` Andre Hedrick
2003-02-11 18:00 ` Patrick Mansfield
2003-02-11 18:44   ` Mike Anderson

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=1045087146.1623.11.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=andmike@us.ibm.com \
    --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