diff mbox

megaraid_sas: Quirk mmio hook for 1078 MR controller

Message ID 201312231512.rBNFC6mo008974@cosmhbs0.lsi.com (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Desai, Kashyap Dec. 23, 2013, 3:13 p.m. UTC
This patch has fix for LSI Gen-1 MR controller issue which only pop-up on
few systems and it is not generic.

On few system, MR 1078 MR controller is not working if mmio decoding is off.
This patch proposed early quirck entry for Device id 0x1000/0x0411 to enable mmio.

Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
---
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Bjorn Helgaas Dec. 23, 2013, 5:57 p.m. UTC | #1
On Mon, Dec 23, 2013 at 8:13 AM,  <Kashyap.Desai@lsi.com> wrote:
> This patch has fix for LSI Gen-1 MR controller issue which only pop-up on
> few systems and it is not generic.
>
> On few system, MR 1078 MR controller is not working if mmio decoding is off.
> This patch proposed early quirck entry for Device id 0x1000/0x0411 to enable mmio.
>
> Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
> ---
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index f6c31fa..a20fe41 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -43,6 +43,10 @@ static void quirk_mmio_always_on(struct pci_dev *dev)
>  }
>  DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
>                                 PCI_CLASS_BRIDGE_HOST, 8, quirk_mmio_always_on);
> +/* LSI controller device id 0x0411 has some issues if mmio_always_on is not set.
> + * It pop-up only on few specific system, where decoding disable is not working.
> + */
> +DECLARE_PCI_FIXUP_EARLY(0x1000, 0x0411, quirk_mmio_always_on);

What is the actual problem that happens without this quirk?  Is there
some hardware defect in the MR 1078 that makes it fail when we disable
decoding?

Disabling decoding is important because it prevents conflicts with
other devices while sizing and updating BARs, so I don't want to use
this quirk unless it's really necessary.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Desai, Kashyap Dec. 24, 2013, 8:20 a.m. UTC | #2
> -----Original Message-----

> From: Bjorn Helgaas [mailto:bhelgaas@google.com]

> Sent: Monday, December 23, 2013 11:28 PM

> To: Desai, Kashyap

> Cc: linux-scsi@vger.kernel.org; linux-pci@vger.kernel.org; James E.J.

> Bottomley; Saxena, Sumit; Adam Radford

> Subject: Re: [PATCH] megaraid_sas: Quirk mmio hook for 1078 MR controller

> 

> On Mon, Dec 23, 2013 at 8:13 AM,  <Kashyap.Desai@lsi.com> wrote:

> > This patch has fix for LSI Gen-1 MR controller issue which only pop-up

> > on few systems and it is not generic.

> >

> > On few system, MR 1078 MR controller is not working if mmio decoding is

> off.

> > This patch proposed early quirck entry for Device id 0x1000/0x0411 to

> enable mmio.

> >

> > Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>

> > ---

> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index

> > f6c31fa..a20fe41 100644

> > --- a/drivers/pci/quirks.c

> > +++ b/drivers/pci/quirks.c

> > @@ -43,6 +43,10 @@ static void quirk_mmio_always_on(struct pci_dev

> > *dev)  }  DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,

> >                                 PCI_CLASS_BRIDGE_HOST, 8,

> > quirk_mmio_always_on);

> > +/* LSI controller device id 0x0411 has some issues if mmio_always_on is

> not set.

> > + * It pop-up only on few specific system, where decoding disable is not

> working.

> > + */

> > +DECLARE_PCI_FIXUP_EARLY(0x1000, 0x0411, quirk_mmio_always_on);

> 

> What is the actual problem that happens without this quirk?  Is there some

> hardware defect in the MR 1078 that makes it fail when we disable decoding?

> 

> Disabling decoding is important because it prevents conflicts with other

> devices while sizing and updating BARs, so I don't want to use this quirk

> unless it's really necessary.

LSI is still investigating on h/w issue. It was originally reported from customer site and they have found this issue when they upgrade RHEL6.3 to RHEL6.4.

Kernel/Driver fault with machine check on RHEL6.4 at the time of driver reading base address registers. New way, used in RHEL6.4 (similar to upstream kernel) is to disable mmio memory mapping a and i/o to the device, read the value and then re-enable mmio memory mapping and i/o.  This seems to cause problems on customer setup.

1078 MR controller is pretty old h/w and we may need more time to actually figure out why new pci_read method is failing on customer system.  As an alternative (consider that LSI h/w has some issue), we opt to enable mmio via quirk entry. 

 ~ Kashyap

> 

> Bjorn

>
Bjorn Helgaas Dec. 24, 2013, 2:46 p.m. UTC | #3
[+cc Myron]

On Tue, Dec 24, 2013 at 1:20 AM, Desai, Kashyap <Kashyap.Desai@lsi.com> wrote:
>
>
>> -----Original Message-----
>> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
>> Sent: Monday, December 23, 2013 11:28 PM
>> To: Desai, Kashyap
>> Cc: linux-scsi@vger.kernel.org; linux-pci@vger.kernel.org; James E.J.
>> Bottomley; Saxena, Sumit; Adam Radford
>> Subject: Re: [PATCH] megaraid_sas: Quirk mmio hook for 1078 MR controller
>>
>> On Mon, Dec 23, 2013 at 8:13 AM,  <Kashyap.Desai@lsi.com> wrote:
>> > This patch has fix for LSI Gen-1 MR controller issue which only pop-up
>> > on few systems and it is not generic.
>> >
>> > On few system, MR 1078 MR controller is not working if mmio decoding is
>> off.
>> > This patch proposed early quirck entry for Device id 0x1000/0x0411 to
>> enable mmio.
>> >
>> > Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
>> > ---
>> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
>> > f6c31fa..a20fe41 100644
>> > --- a/drivers/pci/quirks.c
>> > +++ b/drivers/pci/quirks.c
>> > @@ -43,6 +43,10 @@ static void quirk_mmio_always_on(struct pci_dev
>> > *dev)  }  DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
>> >                                 PCI_CLASS_BRIDGE_HOST, 8,
>> > quirk_mmio_always_on);
>> > +/* LSI controller device id 0x0411 has some issues if mmio_always_on is
>> not set.
>> > + * It pop-up only on few specific system, where decoding disable is not
>> working.
>> > + */
>> > +DECLARE_PCI_FIXUP_EARLY(0x1000, 0x0411, quirk_mmio_always_on);
>>
>> What is the actual problem that happens without this quirk?  Is there some
>> hardware defect in the MR 1078 that makes it fail when we disable decoding?
>>
>> Disabling decoding is important because it prevents conflicts with other
>> devices while sizing and updating BARs, so I don't want to use this quirk
>> unless it's really necessary.
> LSI is still investigating on h/w issue. It was originally reported from customer site and they have found this issue when they upgrade RHEL6.3 to RHEL6.4.
>
> Kernel/Driver fault with machine check on RHEL6.4 at the time of driver reading base address registers. New way, used in RHEL6.4 (similar to upstream kernel) is to disable mmio memory mapping a and i/o to the device, read the value and then re-enable mmio memory mapping and i/o.  This seems to cause problems on customer setup.

Is there a bug report we can look at?  Maybe a dmesg or console log of
the issue happening, along with "lspci -vv" output and contents of
/proc/iomem and /proc/ioports?

Unless there's some 1078 hardware defect related to writing the
command register, the current code should be safe.  It's possible
there's a driver defect or something else that causes an access to the
device while it is disabled.  If that's happening, *that* is what
needs to be fixed.

I am opposed to making a change like this to upstream until we
understand what's actually going on.  Of course, RH may want to put
the change in their kernel as a pragmatic measure.

> 1078 MR controller is pretty old h/w and we may need more time to actually figure out why new pci_read method is failing on customer system.  As an alternative (consider that LSI h/w has some issue), we opt to enable mmio via quirk entry.
>
>  ~ Kashyap
>
>>
>> Bjorn
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f6c31fa..a20fe41 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -43,6 +43,10 @@  static void quirk_mmio_always_on(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_ANY_ID, PCI_ANY_ID,
 				PCI_CLASS_BRIDGE_HOST, 8, quirk_mmio_always_on);
+/* LSI controller device id 0x0411 has some issues if mmio_always_on is not set. 
+ * It pop-up only on few specific system, where decoding disable is not working.
+ */
+DECLARE_PCI_FIXUP_EARLY(0x1000, 0x0411, quirk_mmio_always_on);
 
 /* The Mellanox Tavor device gives false positive parity errors
  * Mark this device with a broken_parity_status, to allow