From: Matthew Wilcox <matthew@wil.cx>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: linux-scsi@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver
Date: Tue, 31 Oct 2006 11:55:07 -0700 [thread overview]
Message-ID: <20061031185506.GE26964@parisc-linux.org> (raw)
In-Reply-To: <20061020180510.GN6537@austin.ibm.com>
On Fri, Oct 20, 2006 at 01:05:10PM -0500, Linas Vepstas wrote:
> Index: linux-2.6.19-rc1-git11/drivers/scsi/sym53c8xx_2/sym_glue.c
> ===================================================================
> --- linux-2.6.19-rc1-git11.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2006-10-20 12:25:11.000000000 -0500
> +++ linux-2.6.19-rc1-git11/drivers/scsi/sym53c8xx_2/sym_glue.c 2006-10-20 12:41:15.000000000 -0500
> @@ -659,6 +659,11 @@ static irqreturn_t sym53c8xx_intr(int ir
>
> if (DEBUG_FLAGS & DEBUG_TINY) printf_debug ("[");
>
> + /* Avoid spinloop trying to handle interrupts on frozen device */
> + if ((np->s.device->error_state != pci_channel_io_normal) &&
> + (np->s.device->error_state != 0))
> + return IRQ_HANDLED;
> +
This needs to be before the printf_debug call.
> @@ -726,6 +731,19 @@ static int sym_eh_handler(int op, char *
>
> dev_warn(&cmd->device->sdev_gendev, "%s operation started.\n", opname);
>
> + /* We may be in an error condition because the PCI bus
> + * went down. In this case, we need to wait until the
> + * PCI bus is reset, the card is reset, and only then
> + * proceed with the scsi error recovery. There's no
> + * point in hurrying; take a leisurely wait.
> + */
> +#define WAIT_FOR_PCI_RECOVERY 35
> + if ((np->s.device->error_state != pci_channel_io_normal) &&
> + (np->s.device->error_state != 0) &&
> + (wait_for_completion_timeout(&np->s.io_reset_wait,
> + WAIT_FOR_PCI_RECOVERY*HZ) == 0))
> + return SCSI_FAILED;
> +
Is it safe / reasonable / a good idea to sleep for 35 seconds in the EH
handler? I'm not that familiar with how the EH code works. It has its
own thread, so I suppose that's OK.
Are the driver's data structures still intact after a reset?
I generally prefer not to be so perlish in conditionals, ie:
if ((np->s.device->error_state != pci_channel_io_normal) &&
(np->s.device->error_state != 0) {
int timed_out = wait_for_completion_timeout(
&np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
if (!timed_out)
return SCSI_FAILED;
}
Why is the condition so complicated though? What does 0 mean if it's
not io_normal? At least let's hide that behind a convenience macro:
if (abnormal_error_state(np->s.device->error_state)) {
...
}
> Index: linux-2.6.19-rc1-git11/drivers/scsi/sym53c8xx_2/sym_hipd.c
> ===================================================================
> --- linux-2.6.19-rc1-git11.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2006-10-20 12:25:11.000000000 -0500
> +++ linux-2.6.19-rc1-git11/drivers/scsi/sym53c8xx_2/sym_hipd.c 2006-10-20 12:41:16.000000000 -0500
> @@ -2761,6 +2761,7 @@ void sym_interrupt (struct sym_hcb *np)
> u_char istat, istatc;
> u_char dstat;
> u_short sist;
> + u_int icnt;
The cryptic names in this routine are actually register names. Calling
a counter 'icnt' is unhelpful (rather than fitting in with the style).
Just 'i' will do.
> /*
> * interrupt on the fly ?
> @@ -2802,6 +2803,7 @@ void sym_interrupt (struct sym_hcb *np)
> sist = 0;
> dstat = 0;
> istatc = istat;
> + icnt = 0;
> do {
> if (istatc & SIP)
> sist |= INW(np, nc_sist);
> @@ -2809,6 +2811,14 @@ void sym_interrupt (struct sym_hcb *np)
> dstat |= INB(np, nc_dstat);
> istatc = INB(np, nc_istat);
> istat |= istatc;
> +
> + /* Prevent deadlock waiting on a condition that may never clear. */
> + icnt ++;
> + if (icnt > 100) {
> + if ((np->s.device->error_state != pci_channel_io_normal)
> + && (np->s.device->error_state != 0))
> + return;
> + }
> } while (istatc & (SIP|DIP));
Though, since INB and INW will return 0xff and 0xffff, why not use that
as our test rather than using a counter?
if (sist == 0xffff && dstat == 0xff) {
if (abnormal_error_state(np->s.device->error_state)
return;
}
next prev parent reply other threads:[~2006-10-31 18:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-20 18:05 [PATCH]: PCI Error Recovery: Symbios SCSI device driver Linas Vepstas
2006-10-31 18:55 ` Matthew Wilcox [this message]
2006-10-31 19:24 ` James Bottomley
2006-10-31 22:26 ` Linas Vepstas
2006-10-31 23:13 ` Linas Vepstas
2006-11-02 0:07 ` [PATCH v3]: " Linas Vepstas
2006-11-02 1:19 ` [PATCH v4]: " Linas Vepstas
2006-11-02 3:57 ` Matthew Wilcox
2006-11-02 4:46 ` [PATCH]: " Grant Grundler
2006-11-02 4:56 ` Matthew Wilcox
-- strict thread matches above, loose matches on Subject: below --
2007-07-02 18:39 Linas Vepstas
2007-07-02 18:39 ` Linas Vepstas
2007-07-05 18:28 ` Andrew Morton
2007-07-05 18:28 ` Andrew Morton
2007-07-05 18:28 ` Andrew Morton
2007-07-05 18:54 ` Matthew Wilcox
2007-07-05 18:54 ` Matthew Wilcox
2007-08-02 22:53 ` Linas Vepstas
2007-08-02 22:53 ` Linas Vepstas
2006-09-21 23:13 Linas Vepstas
2006-09-21 23:13 ` Linas Vepstas
2006-09-22 22:06 ` Luca
2006-09-22 22:06 ` Luca
2006-09-22 23:32 ` Linas Vepstas
2006-09-22 23:32 ` Linas Vepstas
2006-09-22 23:39 ` Randy.Dunlap
2006-09-22 23:39 ` Randy.Dunlap
2006-09-22 23:39 ` Randy.Dunlap
2006-09-22 23:50 ` Linas Vepstas
2006-09-22 23:50 ` Linas Vepstas
2006-09-23 0:57 ` Randy.Dunlap
2006-09-23 0:57 ` Randy.Dunlap
2006-09-23 0:57 ` Randy.Dunlap
2006-02-02 20:15 [PATCH] " Linas Vepstas
2006-01-18 16:53 linas
2006-01-18 17:07 ` Matthew Wilcox
2006-01-18 17:54 ` linas
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=20061031185506.GE26964@parisc-linux.org \
--to=matthew@wil.cx \
--cc=linas@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.