[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1309271106090.18703@pobox.suse.cz>
Date: Fri, 27 Sep 2013 11:08:51 +0200 (CEST)
From: Jiri Kosina <jkosina@...e.cz>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Adam Radford <aradford@...il.com>
Subject: Re: [PATCH] PCI: add quirk for 3ware 9650SE controller
On Fri, 6 Sep 2013, Bjorn Helgaas wrote:
> >> >> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
> >> >> > pci device") makes MSIs be forcibly disabled at boot time.
> >> >> >
> >> >> > It turns out that this breaks 3ware controller -- if MSIs are disabled
> >> >> > during PCI discovery of this controller, the device doesn't work properly
> >> >> > (it doesn't respond to any commands that are being sent to it after
> >> >> > initialization).
>
> Is there a bug report for this issue?
Yes, but unfortunately only in our internal bugzilla.
> It's nice to have a pointer to, e.g., a bugzilla.kernel.org bug report
> with info such as dmesg logs, lspci output, etc., for future reference.
It's a customer-reported issue, so I am gathering permission to make this
information public (I don't think that'll be an issue).
I'll send up a followup afterwards.
> Maybe somebody will figure out a more generic change that could make
> this quirk unnecessary, and details will help in figuring that out.
>
> I assume the actual PCI discovery done in the PCI core works fine;
> it's just that the driver doesn't work if MSIs are disabled on the
> device. If that's the case, can this be fixed by some driver change?
> Maybe the driver needs to enable MSI before it sends commands to the
> device?
I have tried it, but it still doesn't work. It seems like the device
initialization is not finalized properly with MISs disabled; meaning the
device is there (discovery has completed), but it "just doesn't work".
> Any description of what this failure looks like to a user? How can a
> user or a distro connect a symptom (driver timeout, console message, or
> whatever) to this patch?
Will be hopefully part of the dmesg I will be providing later ...
basically any commands sent to it time out.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists