Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753424Ab3I0JI7 (ORCPT ); Fri, 27 Sep 2013 05:08:59 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44077 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753151Ab3I0JI5 (ORCPT ); Fri, 27 Sep 2013 05:08:57 -0400 Date: Fri, 27 Sep 2013 11:08:51 +0200 (CEST) From: Jiri Kosina To: Bjorn Helgaas Cc: "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "Eric W. Biederman" , Jesse Barnes , Adam Radford Subject: Re: [PATCH] PCI: add quirk for 3ware 9650SE controller In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2116 Lines: 52 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/