Messages in this thread | | | Date | Fri, 27 Sep 2013 11:08:51 +0200 (CEST) | From | Jiri Kosina <> | 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
| |