* [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
@ 2006-06-17 3:01 Brice Goglin
2006-06-17 5:05 ` Matthew Wilcox
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Brice Goglin @ 2006-06-17 3:01 UTC (permalink / raw)
To: linux-pci; +Cc: LKML
Several chipsets are known to not support MSI. Some support MSI but
disable it by default. Thus, several drivers implement their own way to
detect whether MSI works.
We introduce whitelisting of chipsets that are known to support MSI and
keep the existing backlisting to disable MSI for other chipsets. When it
is unknown whether the root chipset support MSI or not, we disable MSI
by default except if pci=forcemsi was passed.
Whitelisting is done by setting a new PCI_BUS_FLAGS_MSI in the chipset
subordinate bus. pci_enable_msi() thus starts by checking whether the
root chipset of the device has the MSI or NOMSI flag set.
Bus flags inheritance is dropped since it has been reported to be broken.
We currently whitelist all Intel chipsets, nVidia CK804 and ServerWorks
HT2000. Some others are probably missing such as nVidia chipsets for
Intel processors.
We introduces a generic code to check the MSI capability in the
HyperTransport configuration space, and use it in the generic HT MSI
quirk (only used for HT2000 so far) and in the CK804 specific quirk
(needs to check 2 HT MSI mapping).
Finally, we rename PCI_CAP_ID_HT_IRQCONF to PCI_CAP_ID_HT since its
value is the capability and not the irqconf subtype.
Signed-off-by: Brice Goglin <brice@myri.com>
---
I do not split this patch in multiple pieces since it is still small
and this is just a RFC. I will split it for the actual submission.
The patch adds PCI_DEVICE_ID_NVIDIA_CK804_PCIE to pciids.h and may thus
conflict with pci-nvidia-quirk-to-make-aer-pci-e-extended-capability-visible.patch
which adds it too (it has been pushed in Greg K-H's patchset today).
Documentation/kernel-parameters.txt | 6 +
arch/powerpc/sysdev/mpic.c | 2
drivers/pci/msi.c | 58 ++++++++++-----
drivers/pci/pci.c | 2
drivers/pci/pci.h | 1
drivers/pci/probe.c | 2
drivers/pci/quirks.c | 95 +++++++++++++++++++++++++-
include/linux/pci.h | 3
include/linux/pci_ids.h | 2
include/linux/pci_regs.h | 2
10 files changed, 147 insertions(+), 26 deletions(-)
Index: linux-mm/drivers/pci/msi.c
===================================================================
--- linux-mm.orig/drivers/pci/msi.c 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/drivers/pci/msi.c 2006-06-13 14:55:36.000000000 -0400
@@ -28,6 +28,7 @@
static kmem_cache_t* msi_cachep;
static int pci_msi_enable = 1;
+static int pci_msi_force = 0;
static int last_alloc_vector;
static int nr_released_vectors;
static int nr_reserved_vectors = NR_HP_RESERVED_VECTORS;
@@ -902,6 +903,34 @@
}
/**
+ * pci_msi_enabled - check whether MSI may be enabled on device
+ * @dev: pointer to the pci_dev data structure of MSI device function
+ *
+ * Check parent busses for MSI or NO_MSI flags, or disable except
+ * if forced.
+ **/
+int pci_msi_enabled(struct pci_dev * dev)
+{
+ struct pci_dev *pdev;
+
+ if (!pci_msi_enable || !dev || dev->no_msi)
+ return -1;
+
+ /* find root complex for our device */
+ pdev = dev;
+ while (pdev->bus && pdev->bus->self)
+ pdev = pdev->bus->self;
+
+ /* check its bus flags */
+ if (pdev->subordinate->bus_flags & PCI_BUS_FLAGS_MSI)
+ return 0;
+ if (pdev->subordinate->bus_flags & PCI_BUS_FLAGS_NO_MSI)
+ return -1;
+
+ return pci_msi_force ? 0 : -1;
+}
+
+/**
* pci_enable_msi - configure device's MSI capability structure
* @dev: pointer to the pci_dev data structure of MSI device function
*
@@ -913,19 +942,11 @@
**/
int pci_enable_msi(struct pci_dev* dev)
{
- struct pci_bus *bus;
- int pos, temp, status = -EINVAL;
+ int pos, temp, status;
u16 control;
- if (!pci_msi_enable || !dev)
- return status;
-
- if (dev->no_msi)
- return status;
-
- for (bus = dev->bus; bus; bus = bus->parent)
- if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
- return -EINVAL;
+ if (pci_msi_enabled(dev) < 0)
+ return -EINVAL;
temp = dev->irq;
@@ -1135,22 +1156,14 @@
**/
int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
{
- struct pci_bus *bus;
int status, pos, nr_entries, free_vectors;
int i, j, temp;
u16 control;
unsigned long flags;
- if (!pci_msi_enable || !dev || !entries)
- return -EINVAL;
-
- if (dev->no_msi)
+ if (!entries || pci_msi_enabled(dev) < 0)
return -EINVAL;
- for (bus = dev->bus; bus; bus = bus->parent)
- if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
- return -EINVAL;
-
status = msi_init();
if (status < 0)
return status;
@@ -1350,6 +1363,11 @@
pci_msi_enable = 0;
}
+void pci_force_msi(void)
+{
+ pci_msi_force = 1;
+}
+
EXPORT_SYMBOL(pci_enable_msi);
EXPORT_SYMBOL(pci_disable_msi);
EXPORT_SYMBOL(pci_enable_msix);
Index: linux-mm/drivers/pci/pci.c
===================================================================
--- linux-mm.orig/drivers/pci/pci.c 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/drivers/pci/pci.c 2006-06-13 14:55:36.000000000 -0400
@@ -978,6 +978,8 @@
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strcmp(str, "forcemsi")) {
+ pci_force_msi();
} else {
printk(KERN_ERR "PCI: Unknown option `%s'\n",
str);
Index: linux-mm/drivers/pci/pci.h
===================================================================
--- linux-mm.orig/drivers/pci/pci.h 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/drivers/pci/pci.h 2006-06-13 14:55:36.000000000 -0400
@@ -51,6 +51,7 @@
#ifdef CONFIG_PCI_MSI
void disable_msi_mode(struct pci_dev *dev, int pos, int type);
void pci_no_msi(void);
+void pci_force_msi(void);
#else
static inline void disable_msi_mode(struct pci_dev *dev, int pos, int type) { }
static inline void pci_no_msi(void) { }
Index: linux-mm/drivers/pci/quirks.c
===================================================================
--- linux-mm.orig/drivers/pci/quirks.c 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/drivers/pci/quirks.c 2006-06-16 22:26:42.000000000 -0400
@@ -588,7 +588,8 @@
if (dev->subordinate) {
printk(KERN_WARNING "PCI: MSI quirk detected. "
- "PCI_BUS_FLAGS_NO_MSI set for subordinate bus.\n");
+ "PCI_BUS_FLAGS_NO_MSI set for %s subordinate bus.\n",
+ pci_name(dev));
dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
}
@@ -608,7 +609,9 @@
static void __init quirk_svw_msi(struct pci_dev *dev)
{
pci_msi_quirk = 1;
- printk(KERN_WARNING "PCI: MSI quirk detected. pci_msi_quirk set.\n");
+ printk(KERN_WARNING "PCI: MSI quirk detected for %s. "
+ "pci_msi_quirk set.\n",
+ pci_name(dev));
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_svw_msi );
#endif /* CONFIG_X86_IO_APIC */
@@ -1556,6 +1559,94 @@
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1460, quirk_p64h2_1k_io);
+/* Mark MSI bus flags on chipset that are known to support it */
+static void __devinit quirk_msi_supported(struct pci_dev *dev)
+{
+ if (dev->subordinate) {
+ printk(KERN_WARNING "PCI: MSI quirk detected. "
+ "PCI_BUS_FLAGS_MSI set for subordinate bus.\n");
+ dev->subordinate->bus_flags |= PCI_BUS_FLAGS_MSI;
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_msi_supported);
+
+/* Return MSI bus flags depending on MSI HT cap */
+static pci_bus_flags_t __devinit check_msi_ht_cap(struct pci_dev *dev)
+{
+ u8 cap_off;
+ int nbcap = 0;
+ cap_off = PCI_CAPABILITY_LIST - 1;
+
+ /* go through all caps looking for a hypertransport msi mapping */
+ while (pci_read_config_byte(dev, cap_off + 1, &cap_off) == 0 &&
+ nbcap++ <= 256 / 4) {
+ u32 cap_hdr;
+ if (cap_off == 0 || cap_off == 0xff)
+ break;
+ cap_off &= 0xfc;
+ /* msi mapping section according to hypertransport spec */
+ if (pci_read_config_dword(dev, cap_off, &cap_hdr) == 0
+ && (cap_hdr & 0xff) == PCI_CAP_ID_HT /* hypertransport cap */
+ && (cap_hdr & 0xf8000000) == 0xa8000000 /* msi mapping */) {
+ printk(KERN_INFO "PCI: Found MSI HT mapping on %s\n",
+ pci_name(dev));
+ return cap_hdr & 0x10000 /* msi mapping cap enabled */
+ ? PCI_BUS_FLAGS_MSI : PCI_BUS_FLAGS_NO_MSI;
+ }
+ }
+ return 0;
+}
+
+/* Check the hypertransport MSI mapping to know whether MSI is enabled or not */
+static void __devinit quirk_msi_ht_cap(struct pci_dev *dev)
+{
+ pci_bus_flags_t flags;
+
+ if (!dev->subordinate)
+ return;
+
+ flags = check_msi_ht_cap(dev);
+ if (flags) {
+ printk(KERN_WARNING "PCI: MSI quirk detected. "
+ "%s set for %s subordinate bus.\n",
+ flags == PCI_BUS_FLAGS_NO_MSI ?
+ "PCI_BUS_FLAGS_NO_MSI" : "PCI_BUS_FLAGS_MSI",
+ pci_name(dev));
+ dev->subordinate->bus_flags |= flags;
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE, quirk_msi_ht_cap);
+
+/* The nVidia CK804 PCI-E might have 2 hypertransport MSI mapping.
+ * MSI are supported if the MSI cap is enabled on one of them.
+ */
+static void __devinit quirk_nvidia_ck804_msi_ht_cap(struct pci_dev *dev)
+{
+ struct pci_dev *pdev;
+ pci_bus_flags_t flags;
+
+ if (!dev->subordinate)
+ return;
+
+ /* check MSI HT cap on this chipset and the root one.
+ * a single MSI flag is enough to be sure that MSI are supported.
+ */
+ pdev = pci_find_slot(dev->bus->number, 0);
+ flags = check_msi_ht_cap(dev) | check_msi_ht_cap(pdev);
+ if (flags & PCI_BUS_FLAGS_MSI)
+ flags = PCI_BUS_FLAGS_MSI;
+
+ if (flags) {
+ printk(KERN_WARNING "PCI: MSI quirk detected. "
+ "%s set for %s subordinate bus.\n",
+ flags == PCI_BUS_FLAGS_NO_MSI ?
+ "PCI_BUS_FLAGS_NO_MSI" : "PCI_BUS_FLAGS_MSI",
+ pci_name(dev));
+ dev->subordinate->bus_flags |= flags;
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE, quirk_nvidia_ck804_msi_ht_cap);
+
EXPORT_SYMBOL(pcie_mch_quirk);
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pci_fixup_device);
Index: linux-mm/include/linux/pci.h
===================================================================
--- linux-mm.orig/include/linux/pci.h 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/include/linux/pci.h 2006-06-13 14:55:37.000000000 -0400
@@ -97,6 +97,7 @@
typedef unsigned short __bitwise pci_bus_flags_t;
enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
+ PCI_BUS_FLAGS_MSI = (__force pci_bus_flags_t) 2,
};
struct pci_cap_saved_state {
@@ -242,7 +243,7 @@
char name[48];
unsigned short bridge_ctl; /* manage NO_ISA/FBB/et al behaviors */
- pci_bus_flags_t bus_flags; /* Inherited by child busses */
+ pci_bus_flags_t bus_flags;
struct device *bridge;
struct class_device class_dev;
struct bin_attribute *legacy_io; /* legacy I/O for this bus */
Index: linux-mm/include/linux/pci_ids.h
===================================================================
--- linux-mm.orig/include/linux/pci_ids.h 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/include/linux/pci_ids.h 2006-06-13 14:59:58.000000000 -0400
@@ -1027,6 +1027,7 @@
#define PCI_DEVICE_ID_NVIDIA_NVENET_8 0x0056
#define PCI_DEVICE_ID_NVIDIA_NVENET_9 0x0057
#define PCI_DEVICE_ID_NVIDIA_CK804_AUDIO 0x0059
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCIE 0x005d
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_SMBUS 0x0064
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_IDE 0x0065
#define PCI_DEVICE_ID_NVIDIA_NVENET_2 0x0066
@@ -1405,6 +1406,7 @@
#define PCI_DEVICE_ID_SERVERWORKS_LE 0x0009
#define PCI_DEVICE_ID_SERVERWORKS_GCNB_LE 0x0017
#define PCI_DEVICE_ID_SERVERWORKS_EPB 0x0103
+#define PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE 0x0132
#define PCI_DEVICE_ID_SERVERWORKS_OSB4 0x0200
#define PCI_DEVICE_ID_SERVERWORKS_CSB5 0x0201
#define PCI_DEVICE_ID_SERVERWORKS_CSB6 0x0203
Index: linux-mm/Documentation/kernel-parameters.txt
===================================================================
--- linux-mm.orig/Documentation/kernel-parameters.txt 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/Documentation/kernel-parameters.txt 2006-06-13 14:55:37.000000000 -0400
@@ -1190,6 +1190,12 @@
nomsi [MSI] If the PCI_MSI kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of MSI interrupts system-wide.
+ forcemsi [MSI] If the PCI_MSI kernel config parameter is
+ enabled, force MSI to be enabled when its support
+ in parent busses is unknown. By default, MSI
+ are only enabled when parent busses are known
+ to support it. This option does not force MSI
+ when parent busses are known to not support it.
nosort [IA-32] Don't sort PCI devices according to
order given by the PCI BIOS. This sorting is
done to get a device order compatible with
Index: linux-mm/drivers/pci/probe.c
===================================================================
--- linux-mm.orig/drivers/pci/probe.c 2006-06-12 10:08:25.000000000 -0400
+++ linux-mm/drivers/pci/probe.c 2006-06-13 14:55:37.000000000 -0400
@@ -351,7 +351,7 @@
child->parent = parent;
child->ops = parent->ops;
child->sysdata = parent->sysdata;
- child->bus_flags = parent->bus_flags;
+ child->bus_flags = 0;
child->bridge = get_device(&bridge->dev);
child->class_dev.class = &pcibus_class;
Index: linux-mm/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-mm.orig/arch/powerpc/sysdev/mpic.c 2006-06-16 22:20:49.000000000 -0400
+++ linux-mm/arch/powerpc/sysdev/mpic.c 2006-06-16 22:20:57.000000000 -0400
@@ -250,7 +250,7 @@
for (pos = readb(devbase + PCI_CAPABILITY_LIST); pos != 0;
pos = readb(devbase + pos + PCI_CAP_LIST_NEXT)) {
u8 id = readb(devbase + pos + PCI_CAP_LIST_ID);
- if (id == PCI_CAP_ID_HT_IRQCONF) {
+ if (id == PCI_CAP_ID_HT) {
id = readb(devbase + pos + 3);
if (id == 0x80)
break;
Index: linux-mm/include/linux/pci_regs.h
===================================================================
--- linux-mm.orig/include/linux/pci_regs.h 2006-06-16 22:21:33.000000000 -0400
+++ linux-mm/include/linux/pci_regs.h 2006-06-16 22:22:00.000000000 -0400
@@ -196,7 +196,7 @@
#define PCI_CAP_ID_MSI 0x05 /* Message Signalled Interrupts */
#define PCI_CAP_ID_CHSWP 0x06 /* CompactPCI HotSwap */
#define PCI_CAP_ID_PCIX 0x07 /* PCI-X */
-#define PCI_CAP_ID_HT_IRQCONF 0x08 /* HyperTransport IRQ Configuration */
+#define PCI_CAP_ID_HT 0x08 /* HyperTransport capability */
#define PCI_CAP_ID_VNDR 0x09 /* Vendor specific capability */
#define PCI_CAP_ID_SHPC 0x0C /* PCI Standard Hot-Plug Controller */
#define PCI_CAP_ID_EXP 0x10 /* PCI Express */
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 3:01 [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Brice Goglin
@ 2006-06-17 5:05 ` Matthew Wilcox
2006-06-17 5:26 ` Brice Goglin
2006-06-19 11:19 ` Xavier Bestel
2006-06-17 6:28 ` Greg KH
2006-06-17 15:34 ` Alistair John Strachan
2 siblings, 2 replies; 15+ messages in thread
From: Matthew Wilcox @ 2006-06-17 5:05 UTC (permalink / raw)
To: Brice Goglin; +Cc: linux-pci, LKML
On Fri, Jun 16, 2006 at 11:01:46PM -0400, Brice Goglin wrote:
> Several chipsets are known to not support MSI. Some support MSI but
> disable it by default. Thus, several drivers implement their own way to
> detect whether MSI works.
Yes, and that needs to go away. To be fair, we're in the early stages
of introducing generic MSI support, so it's understandable that people
have made expedient rather than architectural solutions to problems.
> We introduce whitelisting of chipsets that are known to support MSI and
> keep the existing backlisting to disable MSI for other chipsets. When it
> is unknown whether the root chipset support MSI or not, we disable MSI
> by default except if pci=forcemsi was passed.
I think that's a bad idea. Blacklisting is the better idea in the long-term.
> Bus flags inheritance is dropped since it has been reported to be broken.
I must have missed that report. Please elucidate.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 5:05 ` Matthew Wilcox
@ 2006-06-17 5:26 ` Brice Goglin
2006-06-19 11:19 ` Xavier Bestel
1 sibling, 0 replies; 15+ messages in thread
From: Brice Goglin @ 2006-06-17 5:26 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-pci, LKML
Matthew Wilcox wrote:
>> We introduce whitelisting of chipsets that are known to support MSI and
>> keep the existing backlisting to disable MSI for other chipsets. When it
>> is unknown whether the root chipset support MSI or not, we disable MSI
>> by default except if pci=forcemsi was passed.
>
> I think that's a bad idea. Blacklisting is the better idea in the
> long-term.
In this case, we absolutely need an exhaustive list of chipsets that do
not support MSI. And it looks like there are a lot of them in the
non-PCI-E world. Our concern is that trying to enable MSI when it does
not work breaks drivers. While disabling MSI generally keeps drivers
working (except for instance for the Infinipath hardware, but our
whitelisting of the nVidia chipset might help them :)).
For the long term, I hope we'll end up having an exhaustive list of
chipsets that do not support MSI. But in the meantime, our "whitelisting
+ disable when we don't know" might help getting MSI as much as possible
without breaking to many things.
>
>> Bus flags inheritance is dropped since it has been reported to be broken.
>
> I must have missed that report. Please elucidate.
>
It is based on the following thread:
http://www.ussg.iu.edu/hypermail/linux/kernel/0605.2/0929.html
The amd8131 MSI quirk cannot be EARLY or HEADER because it would be
called before dev->subordinate has been set (then, PCI_BUS_FLAGS_NO_MSI
could not be set in the bus flags). But, flags are inherited while the
PCI hierarchy is scanned, which means the quirk has to be EARLY or HEADER.
To solve this issue, we would need a quirk that is called while the PCI
hierarchy is scanned (ie, before FINAL or ENABLE) and after the pci
child bus of the bridge is created (ie, after EARLY and HEADER). But I
am not sure whether adding a new quirk type for this is a good idea.
Since the MSI is always actually processed on the root chipset, we know
we have to check there. We thought that inheriting bus flags was not
really required. That's why my patch finds the root chipset and checks
bus flags there.
Brice
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 5:05 ` Matthew Wilcox
2006-06-17 5:26 ` Brice Goglin
@ 2006-06-19 11:19 ` Xavier Bestel
2006-06-19 15:27 ` Grant Grundler
1 sibling, 1 reply; 15+ messages in thread
From: Xavier Bestel @ 2006-06-19 11:19 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Brice Goglin, linux-pci, LKML
On Sat, 2006-06-17 at 07:05, Matthew Wilcox wrote:
> On Fri, Jun 16, 2006 at 11:01:46PM -0400, Brice Goglin wrote:
> > We introduce whitelisting of chipsets that are known to support MSI and
> > keep the existing backlisting to disable MSI for other chipsets. When it
> > is unknown whether the root chipset support MSI or not, we disable MSI
> > by default except if pci=forcemsi was passed.
>
> I think that's a bad idea. Blacklisting is the better idea in the long-term.
I think the option adopted elsewhere is: whitelist for old chipsets, and
blacklist for new chipsets. You just have to decide for a good date to
separate "old" and "new" to minimize the lists size.
Xav
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-19 11:19 ` Xavier Bestel
@ 2006-06-19 15:27 ` Grant Grundler
0 siblings, 0 replies; 15+ messages in thread
From: Grant Grundler @ 2006-06-19 15:27 UTC (permalink / raw)
To: Xavier Bestel; +Cc: Matthew Wilcox, Brice Goglin, linux-pci, LKML
On Mon, Jun 19, 2006 at 01:19:55PM +0200, Xavier Bestel wrote:
> On Sat, 2006-06-17 at 07:05, Matthew Wilcox wrote:
> > On Fri, Jun 16, 2006 at 11:01:46PM -0400, Brice Goglin wrote:
> > > We introduce whitelisting of chipsets that are known to support MSI and
> > > keep the existing backlisting to disable MSI for other chipsets. When it
> > > is unknown whether the root chipset support MSI or not, we disable MSI
> > > by default except if pci=forcemsi was passed.
> >
> > I think that's a bad idea. Blacklisting is the better idea in the long-term.
>
> I think the option adopted elsewhere is: whitelist for old chipsets, and
> blacklist for new chipsets. You just have to decide for a good date to
> separate "old" and "new" to minimize the lists size.
I agree with willy.
White lists work "well" only if one's goal is to reduce the number
of bug reports about _all_ HW. Most folks with _working_ MSI (but not
already on the whitelist) won't know they could report this as a bug.
Ie these chipsets likely won't ever get added to the whitelist.
thanks,
grant
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 3:01 [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Brice Goglin
2006-06-17 5:05 ` Matthew Wilcox
@ 2006-06-17 6:28 ` Greg KH
2006-06-17 7:11 ` Brice Goglin
2006-06-17 11:25 ` Jeff Garzik
2006-06-17 15:34 ` Alistair John Strachan
2 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2006-06-17 6:28 UTC (permalink / raw)
To: Brice Goglin; +Cc: linux-pci, LKML
On Fri, Jun 16, 2006 at 11:01:46PM -0400, Brice Goglin wrote:
> Several chipsets are known to not support MSI. Some support MSI but
> disable it by default. Thus, several drivers implement their own way to
> detect whether MSI works.
>
> We introduce whitelisting of chipsets that are known to support MSI and
> keep the existing backlisting to disable MSI for other chipsets. When it
> is unknown whether the root chipset support MSI or not, we disable MSI
> by default except if pci=forcemsi was passed.
>
> Whitelisting is done by setting a new PCI_BUS_FLAGS_MSI in the chipset
> subordinate bus. pci_enable_msi() thus starts by checking whether the
> root chipset of the device has the MSI or NOMSI flag set.
Whitelisting looks all well and good today, and maybe for the rest of
the year. But what about 3 years from now when everyone has shaken all
of the MSI bugs out of their chipsets finally? Do you really want to
add a new quirk for _every_ new chipset that comes out? I don't think
that it is managable over the long run.
I do like your checks to see if MSI is able to be enabled or not, and
maybe we can just invert them to mark those chips that do not support
MSI today?
> I do not split this patch in multiple pieces since it is still small
> and this is just a RFC. I will split it for the actual submission.
Please do, you are doing a lot of different things in here.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 6:28 ` Greg KH
@ 2006-06-17 7:11 ` Brice Goglin
2006-06-17 8:23 ` Andi Kleen
2006-06-17 11:25 ` Jeff Garzik
1 sibling, 1 reply; 15+ messages in thread
From: Brice Goglin @ 2006-06-17 7:11 UTC (permalink / raw)
To: Greg KH; +Cc: linux-pci, LKML
Greg KH wrote:
> Whitelisting looks all well and good today, and maybe for the rest of
> the year. But what about 3 years from now when everyone has shaken all
> of the MSI bugs out of their chipsets finally? Do you really want to
> add a new quirk for _every_ new chipset that comes out? I don't think
> that it is managable over the long run.
>
We could still reverse the default. Right now, unless pci=forcemsi is
passed, I disable MSI if we don't know whether the chipset supports it.
Once blacklisting has been improved/completed, we can enable MSI by
default (and keep "pci=nomsi" in case a non-blacklisted chipset appears).
Or we could enable MSI by default on PCI-E chipsets and disable by
default on non-PCI-E (ie we whitelist non-PCI-E only) ? PCI-E chipsets
seem to support MSI pretty well.
I am ok with any strategy as long as I don't end up passing "pci=nomsi"
on most new machines I will install in the next 10 years (as I did with
"noapic" in the past) :)
Brice
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 7:11 ` Brice Goglin
@ 2006-06-17 8:23 ` Andi Kleen
2006-06-17 14:48 ` Brice Goglin
0 siblings, 1 reply; 15+ messages in thread
From: Andi Kleen @ 2006-06-17 8:23 UTC (permalink / raw)
To: Brice Goglin; +Cc: linux-pci, LKML, gregkh, discuss
Brice Goglin <brice@myri.com> writes:
>
> Or we could enable MSI by default on PCI-E chipsets and disable by
> default on non-PCI-E (ie we whitelist non-PCI-E only) ? PCI-E chipsets
> seem to support MSI pretty well.
It looks like at least Serverworks HT1000 has trouble with MSI
too, but it's PCI-Express. But I guess those can be black listed
Also I think Intel has supported it well for a long time so might
want to white list all from VENDOR == Intel.
Blacklisting all old non PCI-E bridges non Intel seems reasonable
It seems AMD 8132 can be made to work, but it needs a special
quirk too and then it can be white listed.
The rules will be relatively complicated I guess, but should
be doable.
-Andi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 8:23 ` Andi Kleen
@ 2006-06-17 14:48 ` Brice Goglin
[not found] ` <20060619005329.GA1425@greglaptop>
0 siblings, 1 reply; 15+ messages in thread
From: Brice Goglin @ 2006-06-17 14:48 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-pci, LKML, gregkh, discuss
Andi Kleen wrote:
> Brice Goglin <brice@myri.com> writes:
>
>> Or we could enable MSI by default on PCI-E chipsets and disable by
>> default on non-PCI-E (ie we whitelist non-PCI-E only) ? PCI-E chipsets
>> seem to support MSI pretty well.
>>
>
> It looks like at least Serverworks HT1000 has trouble with MSI
> too, but it's PCI-Express. But I guess those can be black listed
>
IIRC, HT1000 is the southbridge part of the HT2000 chipset. We have been
told that MSI works on this chipset. And from what we've seen/tested, it
is true. The problem is that MSI is often disabled by the BIOS. My
hypertransport MSI capability quirk should check it right.
Brice
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 6:28 ` Greg KH
2006-06-17 7:11 ` Brice Goglin
@ 2006-06-17 11:25 ` Jeff Garzik
1 sibling, 0 replies; 15+ messages in thread
From: Jeff Garzik @ 2006-06-17 11:25 UTC (permalink / raw)
To: Greg KH; +Cc: Brice Goglin, linux-pci, LKML
Greg KH wrote:
> On Fri, Jun 16, 2006 at 11:01:46PM -0400, Brice Goglin wrote:
>> Several chipsets are known to not support MSI. Some support MSI but
>> disable it by default. Thus, several drivers implement their own way to
>> detect whether MSI works.
>>
>> We introduce whitelisting of chipsets that are known to support MSI and
>> keep the existing backlisting to disable MSI for other chipsets. When it
>> is unknown whether the root chipset support MSI or not, we disable MSI
>> by default except if pci=forcemsi was passed.
>>
>> Whitelisting is done by setting a new PCI_BUS_FLAGS_MSI in the chipset
>> subordinate bus. pci_enable_msi() thus starts by checking whether the
>> root chipset of the device has the MSI or NOMSI flag set.
>
> Whitelisting looks all well and good today, and maybe for the rest of
> the year. But what about 3 years from now when everyone has shaken all
> of the MSI bugs out of their chipsets finally? Do you really want to
> add a new quirk for _every_ new chipset that comes out? I don't think
> that it is managable over the long run.
>
> I do like your checks to see if MSI is able to be enabled or not, and
> maybe we can just invert them to mark those chips that do not support
> MSI today?
My gut feeling is:
blacklist -> any Intel machines which fail (most work)
blacklist -> any PCI Express which fails (most should work)
whitelist -> any other situation which works
Regards,
Jeff
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 3:01 [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Brice Goglin
2006-06-17 5:05 ` Matthew Wilcox
2006-06-17 6:28 ` Greg KH
@ 2006-06-17 15:34 ` Alistair John Strachan
2006-06-17 16:15 ` Brice Goglin
2 siblings, 1 reply; 15+ messages in thread
From: Alistair John Strachan @ 2006-06-17 15:34 UTC (permalink / raw)
To: Brice Goglin; +Cc: linux-pci, LKML
On Saturday 17 June 2006 04:01, Brice Goglin wrote:
> Several chipsets are known to not support MSI. Some support MSI but
> disable it by default. Thus, several drivers implement their own way to
> detect whether MSI works.
>
> We introduce whitelisting of chipsets that are known to support MSI and
> keep the existing backlisting to disable MSI for other chipsets. When it
> is unknown whether the root chipset support MSI or not, we disable MSI
> by default except if pci=forcemsi was passed.
I tried your patch on 2.6.17-rc6 (fixed up a view rejects) in an attempt to
get MSI working with my forcedeth NIC, which advertises the capability. The
kernel now gives me the following:
PCI: Found MSI HT mapping on 0000:00:0b.0
PCI: Found MSI HT mapping on 0000:00:00.0
PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0b.0 subordinate
bus.
PCI: Found MSI HT mapping on 0000:00:0c.0
PCI: Found MSI HT mapping on 0000:00:00.0
PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0c.0 subordinate
bus.
PCI: Found MSI HT mapping on 0000:00:0d.0
PCI: Found MSI HT mapping on 0000:00:00.0
PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0d.0 subordinate
bus.
PCI: Found MSI HT mapping on 0000:00:0e.0
PCI: Found MSI HT mapping on 0000:00:00.0
PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0e.0 subordinate
bus.
PCI: Setting latency timer of device 0000:00:0b.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
Is the "vendor BIOS" causing the problem? Here's my /proc/interrupts after
booting.
CPU0 CPU1
0: 574494 0 IO-APIC-edge timer
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
15: 4891 0 IO-APIC-edge ide1
50: 0 0 IO-APIC-level NVidia CK804
58: 4 0 IO-APIC-level ehci_hcd:usb1
66: 6203 0 IO-APIC-level ohci1394, wlan
74: 3 0 IO-APIC-level ohci1394
217: 21315 0 IO-APIC-level libata, ohci_hcd:usb2
225: 1031 0 IO-APIC-level libata
233: 28124 0 IO-APIC-level EMU10K1, skge
NMI: 171 90
LOC: 574330 574263
ERR: 0
MIS: 0
It's an x86-64 kernel.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities
2006-06-17 15:34 ` Alistair John Strachan
@ 2006-06-17 16:15 ` Brice Goglin
0 siblings, 0 replies; 15+ messages in thread
From: Brice Goglin @ 2006-06-17 16:15 UTC (permalink / raw)
To: Alistair John Strachan; +Cc: linux-pci, LKML
Alistair John Strachan wrote:
> On Saturday 17 June 2006 04:01, Brice Goglin wrote:
>
> I tried your patch on 2.6.17-rc6 (fixed up a view rejects) in an attempt to
> get MSI working with my forcedeth NIC, which advertises the capability. The
> kernel now gives me the following:
>
Well, the aim of my patch is to stop enabling MSI by default, and try to
find out when we can and when we cannot use MSI. 2.6.17 will only
disable MSI on a few chipsets. My patch will disable on all chipsets but
Intel and those having Hypertransport MSI capabilities (Serverworks
HT2000 and nVidia CK804). Thus, you cannot expect MSI to be enabled with
my patch if it was not before :/
> PCI: Found MSI HT mapping on 0000:00:0b.0
> PCI: Found MSI HT mapping on 0000:00:00.0
> PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0b.0 subordinate
> bus.
> PCI: Found MSI HT mapping on 0000:00:0c.0
> PCI: Found MSI HT mapping on 0000:00:00.0
> PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0c.0 subordinate
> bus.
> PCI: Found MSI HT mapping on 0000:00:0d.0
> PCI: Found MSI HT mapping on 0000:00:00.0
> PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0d.0 subordinate
> bus.
> PCI: Found MSI HT mapping on 0000:00:0e.0
> PCI: Found MSI HT mapping on 0000:00:00.0
> PCI: MSI quirk detected. PCI_BUS_FLAGS_MSI set for 0000:00:0e.0 subordinate
> bus.
>
If your board is behind one of these bridges, MSI could work (looks like
you have 4 nVidia CK804 with MSI enabled in the Hypertransport mapping).
> pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
> assign_interrupt_mode Found MSI capability
> Allocate Port Service[0000:00:0b.0:pcie00]
> Allocate Port Service[0000:00:0b.0:pcie03]
>
It might be the reason why MSI does not work. But I am not familiar with
this code, so I can't help, sorry.
Brice
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-06-19 15:47 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-17 3:01 [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Brice Goglin
2006-06-17 5:05 ` Matthew Wilcox
2006-06-17 5:26 ` Brice Goglin
2006-06-19 11:19 ` Xavier Bestel
2006-06-19 15:27 ` Grant Grundler
2006-06-17 6:28 ` Greg KH
2006-06-17 7:11 ` Brice Goglin
2006-06-17 8:23 ` Andi Kleen
2006-06-17 14:48 ` Brice Goglin
[not found] ` <20060619005329.GA1425@greglaptop>
2006-06-19 8:28 ` [discuss] " Andi Kleen
2006-06-19 12:52 ` Brice Goglin
2006-06-19 15:47 ` Greg Lindahl
2006-06-17 11:25 ` Jeff Garzik
2006-06-17 15:34 ` Alistair John Strachan
2006-06-17 16:15 ` Brice Goglin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox