From patchwork Thu Sep 1 21:50:45 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jon Mason X-Patchwork-Id: 1120682 X-Patchwork-Delegate: bhelgaas@google.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p81LomXe028664 for ; Thu, 1 Sep 2011 21:50:49 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758074Ab1IAVur (ORCPT ); Thu, 1 Sep 2011 17:50:47 -0400 Received: from mail-gx0-f174.google.com ([209.85.161.174]:40367 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757961Ab1IAVuq (ORCPT ); Thu, 1 Sep 2011 17:50:46 -0400 Received: by gxk21 with SMTP id 21so1727801gxk.19 for ; Thu, 01 Sep 2011 14:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.166.6 with SMTP id t6mr342144ano.20.1314913845425; Thu, 01 Sep 2011 14:50:45 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Thu, 1 Sep 2011 14:50:45 -0700 (PDT) In-Reply-To: <20110901204419.GY8422@beardog.cce.hp.com> References: <20110721181605.31672.36250.stgit@beardog.cce.hp.com> <1314890642.2823.27.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <20110901160724.GN9189@beardog.cce.hp.com> <1314898815.2823.33.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <1314903038.3067.27.camel@dabdike> <20110901125938.7cb1da85@jbarnes-desktop> <20110901200349.GO9189@beardog.cce.hp.com> <20110901130930.5caec2d4@jbarnes-desktop> <20110901204419.GY8422@beardog.cce.hp.com> Date: Thu, 1 Sep 2011 16:50:45 -0500 Message-ID: Subject: Re: [BUG] scsi: hpsa: how to destroy your files From: Jon Mason To: scameron@beardog.cce.hp.com Cc: Jesse Barnes , Eric Dumazet , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, stephenmcameron@gmail.com, thenzl@redhat.com, akpm@linux-foundation.org, mikem@beardog.cce.hp.com, linux-pci@vger.kernel.org, Roland Dreier , James Bottomley Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Thu, 01 Sep 2011 21:50:49 +0000 (UTC) On Thu, Sep 1, 2011 at 3:44 PM, wrote: > On Thu, Sep 01, 2011 at 01:09:30PM -0700, Jesse Barnes wrote: >> On Thu, 1 Sep 2011 15:03:49 -0500 >> scameron@beardog.cce.hp.com wrote: >> >> > On Thu, Sep 01, 2011 at 12:59:38PM -0700, Jesse Barnes wrote: >> > > On Thu, 01 Sep 2011 11:50:38 -0700 >> > > James Bottomley wrote: >> > > >> > > > On Thu, 2011-09-01 at 10:58 -0700, Roland Dreier wrote: >> > > > > > OK I found the bad commit,I got lucky... I lost some files but my >> > > > > > machine was able to complete the bisection. CC involved people >> > > > > >> > > > > > # bad: [b03e7495a862b028294f59fc87286d6d78ee7fa1] PCI: Set PCI-E Max Payload Size on fabric >> > > > > >> > > > > Hi Eric, >> > > > > >> > > > > I guess it would be useful to see "lspci -vv" output with a "good" kernel >> > > > > and with that bad patch applied.  Most likely we should see some difference >> > > > > somewhere in the MaxPayload fields in the PCI Express capability of >> > > > > some device. >> > > > > >> > > > > Either the RAID controller or something else lies, and puts a value >> > > > > in the DevCap that it can't actually support, or else the patch is >> > > > > buggy and puts something out of range in a DevCtl somewhere. >> > > > >> > > > >> > > > While we investigate, I think the problems produced by the patch (data >> > > > corruption) are serious enough to warrant reverting it, please Jesse. >> > > >> > > Hm I haven't been paying attention to the compromise thread; how should >> > > I share these changes?  Is master.kernel.org down indefinitely?  Is >> > > there a new server at kernel.org I can use? >> > >> > I can't answer that question, but I would like a copy of your revert >> > patch(es) to test (as a simple patch --reverse of the original commit on the 3.1-rc4 >> > tree didn't go in cleanly). >> >> Attached is the series.  Applies on top of my for-linus branch. > > Thanks.  I tried them out vs. 3.1-rc4, and they applied cleanly and > make things work on my BL460g7. I believe modifying the MRRS values is what is causing the issues. Can you try the attached patch and verify that it also resolves the issue? Thanks, Jon > -- steve > > > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 8473727..d896c5e 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1394,41 +1394,6 @@ static void pcie_write_mps(struct pci_dev *dev, int mps) dev_err(&dev->dev, "Failed attempting to set the MPS\n"); } -static void pcie_write_mrrs(struct pci_dev *dev, int mps) -{ - int rc, mrrs; - - if (pcie_bus_config == PCIE_BUS_PERFORMANCE) { - int dev_mpss = 128 << dev->pcie_mpss; - - /* For Max performance, the MRRS must be set to the largest - * supported value. However, it cannot be configured larger - * than the MPS the device or the bus can support. This assumes - * that the largest MRRS available on the device cannot be - * smaller than the device MPSS. - */ - mrrs = mps < dev_mpss ? mps : dev_mpss; - } else - /* In the "safe" case, configure the MRRS for fairness on the - * bus by making all devices have the same size - */ - mrrs = mps; - - - /* MRRS is a R/W register. Invalid values can be written, but a - * subsiquent read will verify if the value is acceptable or not. - * If the MRRS value provided is not acceptable (e.g., too large), - * shrink the value until it is acceptable to the HW. - */ - while (mrrs != pcie_get_readrq(dev) && mrrs >= 128) { - rc = pcie_set_readrq(dev, mrrs); - if (rc) - dev_err(&dev->dev, "Failed attempting to set the MRRS\n"); - - mrrs /= 2; - } -} - static int pcie_bus_configure_set(struct pci_dev *dev, void *data) { int mps = 128 << *(u8 *)data; @@ -1440,7 +1405,6 @@ static int pcie_bus_configure_set(struct pci_dev *dev, void *data) pcie_get_mps(dev), 128<pcie_mpss, pcie_get_readrq(dev)); pcie_write_mps(dev, mps); - pcie_write_mrrs(dev, mps); dev_info(&dev->dev, "Dev MPS %d MPSS %d MRRS %d\n", pcie_get_mps(dev), 128<pcie_mpss, pcie_get_readrq(dev));