From patchwork Tue Nov 5 13:06:30 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Kosina X-Patchwork-Id: 3141301 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A249BBEEB2 for ; Tue, 5 Nov 2013 13:06:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D17F420138 for ; Tue, 5 Nov 2013 13:06:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F2A1E200ED for ; Tue, 5 Nov 2013 13:06:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754907Ab3KENGf (ORCPT ); Tue, 5 Nov 2013 08:06:35 -0500 Received: from cantor2.suse.de ([195.135.220.15]:47908 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754904Ab3KENGe (ORCPT ); Tue, 5 Nov 2013 08:06:34 -0500 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0FE5CA5B27; Tue, 5 Nov 2013 14:06:33 +0100 (CET) Date: Tue, 5 Nov 2013 14:06:30 +0100 (CET) From: Jiri Kosina To: Bjorn Helgaas Cc: "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "Eric W. Biederman" , Jesse Barnes , Adam Radford Subject: Re: [PATCH] PCI: add quirk for 3ware 9650SE controller In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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) {