All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Kosina <jkosina@suse.cz>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Adam Radford <aradford@gmail.com>
Subject: Re: [PATCH] PCI: add quirk for 3ware 9650SE controller
Date: Tue, 5 Nov 2013 14:06:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.LNX.2.00.1311051402500.2779@pobox.suse.cz> (raw)
In-Reply-To: <CAErSpo7qORQjs62zdi-5et2WnWwy3weMs56G84rWhNrW59F5WQ@mail.gmail.com>

On Thu, 31 Oct 2013, Bjorn Helgaas wrote:

> > Attached is dmesg output leading to timeouts (that are cured by my
> > original patch in this thread) and lspci.
> 
> I opened https://bugzilla.kernel.org/show_bug.cgi?id=64141 for this
> issue and attached your dmesg log and lspci output.
> 
> > Please let me know if there is anything else I could do, or if you are
> > going to proceed with my patch adding the quirk.
> 
> Your quirk keeps us from disabling MSIs on the device during
> enumeration.  But even if the BIOS left MSIs enabled, there's nothing
> to field the MSI until after the driver claims the device.  So I don't
> believe this has to be done as a quirk.  It should work just as well
> to do something in the driver when it claims the device.
> 
> I guess another way to say this is that I don't think we understand
> what the real problem is, and if we just add a quirk to work around
> it, we might miss the chance to fix the real problem, and we may never
> be able to remove the special-case code we're adding in the generic
> path.
> 
> I know you said you tried doing something in the driver, and it didn't
> work.  I don't know exactly what you tried, but twa_probe() looks
> strange to me.  The other drivers I looked at do all their PCI
> initialization before the scsi_host_alloc() / scsi_add_host() /
> scsi_scan_host() stuff.  But twa_probe() has PCI stuff scattered
> around between those three SCSI calls.  In particular, it does the MSI
> setup way down near the end, after scsi_add_host(), which seems like
> just the sort of thing that could explain this problem.

What I tried was patch below, but it didn't have any observable effect -- 
the commands sent to the controller would still time out the same way.

Debugging this is not really straightforward for me unfortunately, as I 
don't own the system myself.

I agree that we don't fully understand what is happening, but the quirk 
was the only way I have been able to come up with to make the device 
functioning again (apart from reverting d5dea7d95).

Any other ideas are welcome.

---
 drivers/scsi/3w-9xxx.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index ba754c3..bad7faf 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -2055,6 +2055,11 @@ static int __devinit twa_probe(struct pci_dev *pdev, const struct pci_device_id
 			goto out_disable_device;
 		}
 
+	/* Try to enable MSI */
+	if (use_msi && (pdev->device != PCI_DEVICE_ID_3WARE_9000) &&
+	    !pci_enable_msi(pdev))
+		set_bit(TW_USING_MSI, &tw_dev->flags);
+
 	host = scsi_host_alloc(&driver_template, sizeof(TW_Device_Extension));
 	if (!host) {
 		TW_PRINTK(host, TW_DRIVER, 0x24, "Failed to allocate memory for device extension");
@@ -2134,11 +2139,6 @@ static int __devinit twa_probe(struct pci_dev *pdev, const struct pci_device_id
 	       le32_to_cpu(*(int *)twa_get_param(tw_dev, 2, TW_INFORMATION_TABLE,
 				     TW_PARAM_PORTCOUNT, TW_PARAM_PORTCOUNT_LENGTH)));
 
-	/* Try to enable MSI */
-	if (use_msi && (pdev->device != PCI_DEVICE_ID_3WARE_9000) &&
-	    !pci_enable_msi(pdev))
-		set_bit(TW_USING_MSI, &tw_dev->flags);
-
 	/* Now setup the interrupt handler */
 	retval = request_irq(pdev->irq, twa_interrupt, IRQF_SHARED, "3w-9xxx", tw_dev);
 	if (retval) {


-- 
Jiri Kosina
SUSE Labs

  reply	other threads:[~2013-11-05 13:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27  9:44 [PATCH] PCI: add quirk for 3ware 9650SE controller Jiri Kosina
2013-08-27  9:45 ` Jiri Kosina
2013-08-28 15:46   ` Jiri Kosina
2013-08-28 16:33     ` Bjorn Helgaas
2013-09-06  9:51       ` Jiri Kosina
2013-09-06 22:47         ` Bjorn Helgaas
2013-09-24 20:50           ` Bjorn Helgaas
2013-09-27  9:08           ` Jiri Kosina
2013-10-30 10:27             ` Jiri Kosina
2013-10-31 21:27               ` Bjorn Helgaas
2013-11-05 13:06                 ` Jiri Kosina [this message]
2013-11-05 18:44                   ` Bjorn Helgaas
2014-06-03 23:00                     ` Bjorn Helgaas
2014-06-04  7:59                       ` Jiri Kosina

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=alpine.LNX.2.00.1311051402500.2779@pobox.suse.cz \
    --to=jkosina@suse.cz \
    --cc=aradford@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=ebiederm@xmission.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@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 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.