From: Bernd Schubert <bs@q-leap.de>
To: Linux SCSI Mailing List <linux-scsi@vger.kernel.org>
Cc: Eric Moore <Eric.Moore@lsi.com>,
Sathya Prakash <Sathya.Prakash@lsi.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
DL-MPTFusionLinux@lsi.com
Subject: Re: [ PATCH 2/4 ] mpt fusion disable hard resets for 53C1030 based devices
Date: Tue, 23 Sep 2008 15:30:06 +0200 [thread overview]
Message-ID: <200809231530.06967.bs@q-leap.de> (raw)
In-Reply-To: <200809231526.31863.bs@q-leap.de>
This is patch 2/4 ...
On Tuesday 23 September 2008 15:26:30 Bernd Schubert wrote:
> For 53C1030 based dual port HBAs the hard reset handler will cause
> trouble on the second channel with innocent devices. It is then better
> to fail the device which activated the error handler than to fail
> cause errors on unrelated devices. Of course, the real solutions
> would be to figure out why the hard reset handler cause trouble on the
> second channel. Probably only LSI can do, though.
>
> Signed-off-by: Bernd Schubert <bs@q-leap.de>
>
> drivers/message/fusion/mptbase.c | 42 ++++++++++++++++++++++++++++-
> drivers/message/fusion/mptspi.c | 31 +++++++++++++++++++++
> 2 files changed, 72 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.26/drivers/message/fusion/mptbase.c
> ===================================================================
> --- linux-2.6.26.orig/drivers/message/fusion/mptbase.c
> +++ linux-2.6.26/drivers/message/fusion/mptbase.c
> @@ -59,6 +59,7 @@
> #include <linux/interrupt.h> /* needed for in_interrupt() proto */
> #include <linux/dma-mapping.h>
> #include <asm/io.h>
> +#include <scsi/scsi_device.h>
> #ifdef CONFIG_MTRR
> #include <asm/mtrr.h>
> #endif
> @@ -6452,6 +6453,33 @@ mpt_HardResetHandler(MPT_ADAPTER *ioc, i
> }
>
> /**
> + * Check if there are devices connected to the second (alt) ioc.
> + * Return 1 if there is at least on device and 0 if there are
> + * none or no alt_ioc.
> + */
> +static int
> +alt_ioc_with_dev(MPT_ADAPTER *ioc)
> +{
> + struct Scsi_Host *shost;
> + struct scsi_device *sdev;
> + int have_devices = 0;
> +
> + if (!ioc->alt_ioc)
> + return 0;
> +
> + shost = ioc->alt_ioc->sh;
> +
> + shost_for_each_device(sdev, shost) {
> + /* when we are here, we know there is is a device
> + * attached to this host, which is all we need to know */
> + have_devices = 1;
> + break;
> + }
> +
> + return have_devices;
> +}
> +
> +/**
> * mpt_SoftHardResetHandler - Generic reset handler
> * @ioc: Pointer to MPT_ADAPTER structure
> * @sleepFlag: Indicates if sleep or schedule must be called.
> @@ -6466,7 +6494,19 @@ mpt_SoftHardResetHandler(MPT_ADAPTER *io
>
> rc = mpt_SoftResetHandler(ioc, sleepFlag);
> if (rc) {
> - rc = mpt_HardResetHandler(ioc, sleepFlag);
> + if (ioc->no_hard_reset && alt_ioc_with_dev(ioc)) {
> + /* On dual port HBAs based on the 53C1030 chip the
> + * hard reset handler will cause DID_SOFT_ERROR on
> + * the second (in principle independent) port.
> + * Almost always this error cannot be recovered
> + * causing entire device failures. So it better not
> + * to call the hard reset handler at all in order to
> + * prevent failures of independent devices */
> + printk(MYIOC_s_INFO_FMT "Skipping hard reset in "
> + "order to prevent failures on %s.\n",
> + ioc->name, ioc->alt_ioc->name);
> + } else
> + rc = mpt_HardResetHandler(ioc, sleepFlag);
> }
>
> return rc;
> Index: linux-2.6.26/drivers/message/fusion/mptspi.c
> ===================================================================
> --- linux-2.6.26.orig/drivers/message/fusion/mptspi.c
> +++ linux-2.6.26/drivers/message/fusion/mptspi.c
> @@ -1301,6 +1301,33 @@ mptspi_resume(struct pci_dev *pdev)
> #endif
>
>
> /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>-=*/ +/**
> + * avoid_hard_reset - check if hard resets should be avoided
> + * @pdev: Pointer to pci_dev structure
> + *
> + * Hard resets will cause trouble on the the secondary IOC of
> + * 53C1030 based devices.
> + *
> + * Returns 1 if affected chip is found and 1 for unaffected chips
> + */
> +static int
> +avoid_hard_reset(struct pci_dev *pdev)
> +{
> + int avoid;
> +
> + switch (pdev->device) {
> + case MPI_MANUFACTPAGE_DEVID_53C1030:
> + case MPI_MANUFACTPAGE_DEVID_53C1030ZC:
> + /* TODO: which chips are affected as well? */
> + avoid = 1;
> + break;
> + default:
> + avoid = 0;
> + }
> +
> + return avoid;
> +}
> +
>
> /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>-=*/ /*
> * mptspi_probe - Installs scsi devices per bus.
> @@ -1509,6 +1536,10 @@ mptspi_probe(struct pci_dev *pdev, const
> goto out_mptspi_probe;
> }
>
> + /* hard resets on 53C1030 HBAs will cause trouble on secondaray (alt)
> + * IOCs, so better no hard reset on these */
> + ioc->no_hard_reset = avoid_hard_reset(pdev);
> +
> /*
> * issue internal bus reset
> */
> --
> 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
--
Bernd Schubert
Q-Leap Networks GmbH
next prev parent reply other threads:[~2008-09-23 13:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-23 13:16 [PATCH 0/4 V2] mpt fusion error handler patches Bernd Schubert
2008-09-23 13:20 ` [ PATCH 1/4 ] mpt fusion SoftReset handler Bernd Schubert
2008-10-30 15:37 ` Prakash, Sathya
2008-10-30 16:18 ` Bernd Schubert
2008-10-30 18:10 ` Prakash, Sathya
2008-09-23 13:26 ` [ PATCH 1/4 ] mpt fusion disable hard resets for 53C1030 based devices Bernd Schubert
2008-09-23 13:30 ` Bernd Schubert [this message]
2008-10-06 9:07 ` [ PATCH 2/4 " Prakash, Sathya
2008-10-06 9:32 ` Bernd Schubert
2008-09-23 13:27 ` [ PATCH 3/4 ] mpt fusion prevent DV deadlock Bernd Schubert
2008-10-30 17:58 ` Prakash, Sathya
2008-10-31 18:53 ` Bernd Schubert
2008-09-23 13:28 ` [PATCH 4/4 ] Increase scsi timeouts Bernd Schubert
2008-10-06 9:07 ` Prakash, Sathya
[not found] <6A4D764DC1BDE14495DA8DC60A3D69531E967A0759@hkgmail01.lsi.com>
2008-10-07 16:25 ` [ PATCH 2/4 ] mpt fusion disable hard resets for 53C1030 based devices Moore, Eric
2008-10-07 17:09 ` Bernd Schubert
2008-10-07 20:00 ` Moore, Eric
2008-10-07 21:27 ` Bernd Schubert
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=200809231530.06967.bs@q-leap.de \
--to=bs@q-leap.de \
--cc=DL-MPTFusionLinux@lsi.com \
--cc=Eric.Moore@lsi.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Sathya.Prakash@lsi.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