[+cc Myron] On Tue, Dec 24, 2013 at 1:20 AM, Desai, Kashyap <Kashyap.Desai@xxxxxxx> wrote: > > >> -----Original Message----- >> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] >> Sent: Monday, December 23, 2013 11:28 PM >> To: Desai, Kashyap >> Cc: linux-scsi@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; 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@xxxxxxx> 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@xxxxxxx> >> > --- >> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
