* [patch 02/16] alpha: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- skips resources unless requested in "mask"
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/alpha/kernel/pci.c
===================================================================
--- work8.orig/arch/alpha/kernel/pci.c 2008-03-04 09:58:07.000000000 -0700
+++ work8/arch/alpha/kernel/pci.c 2008-03-04 09:58:54.000000000 -0700
@@ -372,28 +372,7 @@
int
pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, oldcmd;
- int i;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- oldcmd = cmd;
-
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- struct resource *res = &dev->resource[i];
-
- if (res->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- else if (res->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
-
- if (cmd != oldcmd) {
- printk(KERN_DEBUG "PCI: Enabling device: (%s), cmd %x\n",
- pci_name(dev), cmd);
- /* Enable the appropriate bits in the PCI command register. */
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
/*
--
^ permalink raw reply
* [patch 01/16] PCI: add generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Each architecture has its own pcibios_enable_resources() implementation.
These differ in many minor ways that have nothing to do with actual
architectural differences. Follow-on patches will make most arches
use this generic version instead.
This version is based on powerpc, which seemed most up-to-date. The only
functional difference from the x86 version is that this uses "!r->parent"
to check for resource collisions instead of "!r->start && r->end".
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/drivers/pci/setup-res.c
===================================================================
--- work8.orig/drivers/pci/setup-res.c 2008-03-04 09:56:53.000000000 -0700
+++ work8/drivers/pci/setup-res.c 2008-03-04 09:56:56.000000000 -0700
@@ -263,3 +263,46 @@
}
}
}
+
+int pci_enable_resources(struct pci_dev *dev, int mask)
+{
+ u16 cmd, old_cmd;
+ int i;
+ struct resource *r;
+
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ old_cmd = cmd;
+
+ for (i = 0; i < PCI_NUM_RESOURCES; i++) {
+ if (!(mask & (1 << i)))
+ continue;
+
+ r = &dev->resource[i];
+
+ if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
+ continue;
+ if ((i == PCI_ROM_RESOURCE) &&
+ (!(r->flags & IORESOURCE_ROM_ENABLE)))
+ continue;
+
+ if (!r->parent) {
+ dev_err(&dev->dev, "device not available because of "
+ "BAR %d [%llx:%llx] collisions\n", i,
+ (unsigned long long) r->start,
+ (unsigned long long) r->end);
+ return -EINVAL;
+ }
+
+ if (r->flags & IORESOURCE_IO)
+ cmd |= PCI_COMMAND_IO;
+ if (r->flags & IORESOURCE_MEM)
+ cmd |= PCI_COMMAND_MEMORY;
+ }
+
+ if (cmd != old_cmd) {
+ dev_info(&dev->dev, "enabling device (%04x -> %04x)\n",
+ old_cmd, cmd);
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+ }
+ return 0;
+}
Index: work8/include/linux/pci.h
===================================================================
--- work8.orig/include/linux/pci.h 2008-03-04 09:56:45.000000000 -0700
+++ work8/include/linux/pci.h 2008-03-04 09:56:56.000000000 -0700
@@ -616,6 +616,7 @@
void pci_assign_unassigned_resources(void);
void pdev_enable_device(struct pci_dev *);
void pdev_sort_resources(struct pci_dev *, struct resource_list *);
+int pci_enable_resources(struct pci_dev *, int mask);
void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
int (*)(struct pci_dev *, u8, u8));
#define HAVE_PCI_REQ_REGIONS 2
--
^ permalink raw reply
* [patch 03/16] arm: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/arm/kernel/bios32.c
===================================================================
--- work8.orig/arch/arm/kernel/bios32.c 2008-03-04 09:59:24.000000000 -0700
+++ work8/arch/arm/kernel/bios32.c 2008-03-04 10:01:40.000000000 -0700
@@ -660,28 +660,15 @@
*/
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
+ int err;
u16 cmd, old_cmd;
- int idx;
- struct resource *r;
+
+ err = pci_enable_resources(dev, mask);
+ if (err < 0)
+ return err;
pci_read_config_word(dev, PCI_COMMAND, &cmd);
old_cmd = cmd;
- for (idx = 0; idx < 6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
-
- r = dev->resource + idx;
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because"
- " of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
/*
* Bridges (eg, cardbus bridges) need to be fully enabled
@@ -690,8 +677,8 @@
cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
if (cmd != old_cmd) {
- printk("PCI: enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
+ dev_info(&dev->dev, "enabling bridge device (%04x -> %04x)\n",
+ old_cmd, cmd);
pci_write_config_word(dev, PCI_COMMAND, cmd);
}
return 0;
--
^ permalink raw reply
* [patch 04/16] cris: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/cris/arch-v32/drivers/pci/bios.c
===================================================================
--- work8.orig/arch/cris/arch-v32/drivers/pci/bios.c 2008-03-04 10:02:27.000000000 -0700
+++ work8/arch/cris/arch-v32/drivers/pci/bios.c 2008-03-04 10:02:47.000000000 -0700
@@ -55,38 +55,6 @@
}
}
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
int pcibios_enable_irq(struct pci_dev *dev)
{
dev->irq = EXT_INTR_VECT;
@@ -97,7 +65,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
if (!dev->msi_enabled)
--
^ permalink raw reply
* [patch 06/16] ia64: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- does not check for a NULL dev pointer
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/ia64/pci/pci.c
===================================================================
--- work8.orig/arch/ia64/pci/pci.c 2008-03-04 10:04:18.000000000 -0700
+++ work8/arch/ia64/pci/pci.c 2008-03-04 10:04:35.000000000 -0700
@@ -499,54 +499,12 @@
/* ??? FIXME -- record old value for shutdown. */
}
-static inline int
-pcibios_enable_resources (struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
- unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
-
- if (!dev)
- return -EINVAL;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<PCI_NUM_RESOURCES; idx++) {
- /* Only set up the desired resources. */
- if (!(mask & (1 << idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!(r->flags & type_mask))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (!r->start && r->end) {
- printk(KERN_ERR
- "PCI: Device %s not available because of resource collisions\n",
- pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
int
pcibios_enable_device (struct pci_dev *dev, int mask)
{
int ret;
- ret = pcibios_enable_resources(dev, mask);
+ ret = pci_enable_resources(dev, mask);
if (ret < 0)
return ret;
--
^ permalink raw reply
* [patch 08/16] mn10300: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/mn10300/unit-asb2305/pci-asb2305.c
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci-asb2305.c 2008-03-04 10:05:27.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci-asb2305.c 2008-03-04 10:05:36.000000000 -0700
@@ -218,45 +218,6 @@
pcibios_allocate_resources(1);
}
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
-
- for (idx = 0; idx < 6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
-
- r = &dev->resource[idx];
-
- if (!r->start && r->end) {
- printk(KERN_ERR
- "PCI: Device %s not available because of"
- " resource collisions\n",
- pci_name(dev));
- return -EINVAL;
- }
-
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
-
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
-
- if (cmd != old_cmd)
- pci_write_config_word(dev, PCI_COMMAND, cmd);
-
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/mn10300/unit-asb2305/pci-asb2305.h
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci-asb2305.h 2008-03-04 10:05:41.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci-asb2305.h 2008-03-04 10:05:45.000000000 -0700
@@ -36,7 +36,6 @@
extern unsigned int pcibios_max_latency;
extern void pcibios_resource_survey(void);
-extern int pcibios_enable_resources(struct pci_dev *dev, int mask);
/* pci.c */
Index: work8/arch/mn10300/unit-asb2305/pci.c
===================================================================
--- work8.orig/arch/mn10300/unit-asb2305/pci.c 2008-03-04 10:05:49.000000000 -0700
+++ work8/arch/mn10300/unit-asb2305/pci.c 2008-03-04 10:05:54.000000000 -0700
@@ -440,7 +440,7 @@
{
int err;
- err = pcibios_enable_resources(dev, mask);
+ err = pci_enable_resources(dev, mask);
if (err == 0)
pcibios_enable_irq(dev);
return err;
--
^ permalink raw reply
* [patch 07/16] mips: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/mips/pci/pci.c
===================================================================
--- work8.orig/arch/mips/pci/pci.c 2008-03-04 10:04:51.000000000 -0700
+++ work8/arch/mips/pci/pci.c 2008-03-04 10:05:08.000000000 -0700
@@ -163,44 +163,6 @@
subsys_initcall(pcibios_init);
-static int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available "
- "because of resource collisions\n",
- pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
@@ -231,7 +193,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
return pcibios_plat_dev_init(dev);
--
^ permalink raw reply
* [patch 10/16] powerpc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
The generic version is functionally equivalent, but uses dev_printk.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/powerpc/kernel/pci-common.c
===================================================================
--- work8.orig/arch/powerpc/kernel/pci-common.c 2008-03-04 10:08:18.000000000 -0700
+++ work8/arch/powerpc/kernel/pci-common.c 2008-03-04 10:08:54.000000000 -0700
@@ -1155,41 +1155,9 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
if (ppc_md.pcibios_enable_device_hook)
if (ppc_md.pcibios_enable_device_hook(dev))
return -EINVAL;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (r->parent == NULL) {
- printk(KERN_ERR "PCI: Device %s not available because"
- " of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
-
--
^ permalink raw reply
* [patch 09/16] parisc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not DEVICE_COUNT_RESOURCE (12), resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/parisc/kernel/pci.c
===================================================================
--- work8.orig/arch/parisc/kernel/pci.c 2008-03-04 10:06:11.000000000 -0700
+++ work8/arch/parisc/kernel/pci.c 2008-03-04 10:07:54.000000000 -0700
@@ -287,23 +287,15 @@
*/
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd;
- int idx;
+ int err;
+ u16 cmd, old_cmd;
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
-
- for (idx = 0; idx < DEVICE_COUNT_RESOURCE; idx++) {
- struct resource *r = &dev->resource[idx];
+ err = pci_enable_resources(dev, mask);
+ if (err < 0)
+ return err;
- /* only setup requested resources */
- if (!(mask & (1<<idx)))
- continue;
-
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ old_cmd = cmd;
cmd |= (PCI_COMMAND_SERR | PCI_COMMAND_PARITY);
@@ -312,8 +304,12 @@
if (dev->bus->bridge_ctl & PCI_BRIDGE_CTL_FAST_BACK)
cmd |= PCI_COMMAND_FAST_BACK;
#endif
- DBGC("PCIBIOS: Enabling device %s cmd 0x%04x\n", pci_name(dev), cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
+
+ if (cmd != old_cmd) {
+ dev_info(&dev->dev, "enabling SERR and PARITY (%04x -> %04x)\n",
+ old_cmd, cmd);
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+ }
return 0;
}
--
^ permalink raw reply
* [patch 05/16] frv: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/frv/mb93090-mb00/pci-frv.c
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-frv.c 2008-03-04 10:03:11.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-frv.c 2008-03-04 10:03:25.000000000 -0700
@@ -231,38 +231,6 @@
pcibios_assign_resources();
}
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/frv/mb93090-mb00/pci-frv.h
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-frv.h 2008-03-04 10:03:29.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-frv.h 2008-03-04 10:03:33.000000000 -0700
@@ -31,7 +31,6 @@
extern unsigned int pcibios_max_latency;
void pcibios_resource_survey(void);
-int pcibios_enable_resources(struct pci_dev *, int);
/* pci-vdk.c */
Index: work8/arch/frv/mb93090-mb00/pci-vdk.c
===================================================================
--- work8.orig/arch/frv/mb93090-mb00/pci-vdk.c 2008-03-04 10:03:37.000000000 -0700
+++ work8/arch/frv/mb93090-mb00/pci-vdk.c 2008-03-04 10:03:45.000000000 -0700
@@ -465,7 +465,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
if (!dev->msi_enabled)
pcibios_enable_irq(dev);
--
^ permalink raw reply
* [patch 11/16] ppc: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent", not IORESOURCE_UNSET
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/ppc/kernel/pci.c
===================================================================
--- work8.orig/arch/ppc/kernel/pci.c 2008-03-04 10:09:13.000000000 -0700
+++ work8/arch/ppc/kernel/pci.c 2008-03-04 10:10:18.000000000 -0700
@@ -578,39 +578,6 @@
}
-int
-pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1<<idx)))
- continue;
-
- r = &dev->resource[idx];
- if (r->flags & IORESOURCE_UNSET) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n", pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
static int next_controller_index;
struct pci_controller * __init
@@ -785,33 +752,11 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
if (ppc_md.pcibios_enable_device_hook)
if (ppc_md.pcibios_enable_device_hook(dev, 0))
return -EINVAL;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (r->flags & IORESOURCE_UNSET) {
- printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+
+ return pci_enable_resources(dev, mask);
}
struct pci_controller*
--
^ permalink raw reply
* [patch 12/16] sh: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/sh/drivers/pci/pci.c
===================================================================
--- work8.orig/arch/sh/drivers/pci/pci.c 2008-03-04 10:10:44.000000000 -0700
+++ work8/arch/sh/drivers/pci/pci.c 2008-03-04 10:11:04.000000000 -0700
@@ -133,34 +133,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- if (!(mask & (1 << idx)))
- continue;
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk(KERN_INFO "PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
/*
--
^ permalink raw reply
* [patch 13/16] sparc64: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:56 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/sparc64/kernel/pci.c
===================================================================
--- work8.orig/arch/sparc64/kernel/pci.c 2008-03-04 10:11:25.000000000 -0700
+++ work8/arch/sparc64/kernel/pci.c 2008-03-04 10:11:45.000000000 -0700
@@ -927,32 +927,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, oldcmd;
- int i;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- oldcmd = cmd;
-
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- struct resource *res = &dev->resource[i];
-
- /* Only set up the requested stuff */
- if (!(mask & (1<<i)))
- continue;
-
- if (res->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (res->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
-
- if (cmd != oldcmd) {
- printk(KERN_DEBUG "PCI: Enabling device: (%s), cmd %x\n",
- pci_name(dev), cmd);
- /* Enable the appropriate bits in the PCI command register. */
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
void pcibios_resource_to_bus(struct pci_dev *pdev, struct pci_bus_region *region,
--
^ permalink raw reply
* [patch 15/16] x86: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/x86/pci/common.c
===================================================================
--- work8.orig/arch/x86/pci/common.c 2008-03-04 10:12:42.000000000 -0700
+++ work8/arch/x86/pci/common.c 2008-03-04 10:12:51.000000000 -0700
@@ -527,7 +527,7 @@
{
int err;
- if ((err = pcibios_enable_resources(dev, mask)) < 0)
+ if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
if (!dev->msi_enabled)
Index: work8/arch/x86/pci/i386.c
===================================================================
--- work8.orig/arch/x86/pci/i386.c 2008-03-04 10:12:56.000000000 -0700
+++ work8/arch/x86/pci/i386.c 2008-03-04 10:13:03.000000000 -0700
@@ -238,44 +238,6 @@
*/
fs_initcall(pcibios_assign_resources);
-int pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
- /* Only set up the requested stuff */
- if (!(mask & (1 << idx)))
- continue;
-
- r = &dev->resource[idx];
- if (!(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
- if ((idx == PCI_ROM_RESOURCE) &&
- (!(r->flags & IORESOURCE_ROM_ENABLE)))
- continue;
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available "
- "because of resource %d collisions\n",
- pci_name(dev), idx);
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
/*
* If we set up a device for bus mastering, we need to check the latency
* timer as certain crappy BIOSes forget to set it properly.
Index: work8/arch/x86/pci/pci.h
===================================================================
--- work8.orig/arch/x86/pci/pci.h 2008-03-04 10:13:08.000000000 -0700
+++ work8/arch/x86/pci/pci.h 2008-03-04 10:13:12.000000000 -0700
@@ -44,7 +44,6 @@
extern unsigned int pcibios_max_latency;
void pcibios_resource_survey(void);
-int pcibios_enable_resources(struct pci_dev *, int);
/* pci-pc.c */
--
^ permalink raw reply
* [patch 14/16] v850: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/v850/kernel/rte_mb_a_pci.c
===================================================================
--- work8.orig/arch/v850/kernel/rte_mb_a_pci.c 2008-03-04 10:12:04.000000000 -0700
+++ work8/arch/v850/kernel/rte_mb_a_pci.c 2008-03-04 10:12:26.000000000 -0700
@@ -219,30 +219,7 @@
\f
int __nomods_init pcibios_enable_device (struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx = 0; idx < 6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
+ return pci_enable_resources(dev, mask);
}
\f
--
^ permalink raw reply
* [patch 16/16] xtensa: use generic pci_enable_resources()
From: Bjorn Helgaas @ 2008-03-04 18:57 UTC (permalink / raw)
To: linux-pci, linux-arch
Cc: Chris Zankel, Grant Grundler, linux-parisc, Matthew Wilcox,
Kyle McMartin, linuxppc-dev, Paul Mackerras, linux-arm-kernel,
Russell King
In-Reply-To: <20080304185646.864917286@ldl.fc.hp.com>
Use the generic pci_enable_resources() instead of the arch-specific code.
Unlike this arch-specific code, the generic version:
- checks PCI_NUM_RESOURCES (11), not 6, resources
- skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
- skips ROM resources unless IORESOURCE_ROM_ENABLE is set
- checks for resource collisions with "!r->parent"
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work8/arch/xtensa/kernel/pci.c
===================================================================
--- work8.orig/arch/xtensa/kernel/pci.c 2008-03-04 10:17:29.000000000 -0700
+++ work8/arch/xtensa/kernel/pci.c 2008-03-04 10:18:07.000000000 -0700
@@ -91,37 +91,6 @@
}
}
-int
-pcibios_enable_resources(struct pci_dev *dev, int mask)
-{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for(idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk (KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (dev->resource[PCI_ROM_RESOURCE].start)
- cmd |= PCI_COMMAND_MEMORY;
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
- return 0;
-}
-
struct pci_controller * __init pcibios_alloc_controller(void)
{
struct pci_controller *pci_ctrl;
@@ -238,31 +207,7 @@
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- u16 cmd, old_cmd;
- int idx;
- struct resource *r;
-
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- old_cmd = cmd;
- for (idx=0; idx<6; idx++) {
- r = &dev->resource[idx];
- if (!r->start && r->end) {
- printk(KERN_ERR "PCI: Device %s not available because "
- "of resource collisions\n", pci_name(dev));
- return -EINVAL;
- }
- if (r->flags & IORESOURCE_IO)
- cmd |= PCI_COMMAND_IO;
- if (r->flags & IORESOURCE_MEM)
- cmd |= PCI_COMMAND_MEMORY;
- }
- if (cmd != old_cmd) {
- printk("PCI: Enabling device %s (%04x -> %04x)\n",
- pci_name(dev), old_cmd, cmd);
- pci_write_config_word(dev, PCI_COMMAND, cmd);
- }
-
- return 0;
+ return pci_enable_resources(dev, mask);
}
#ifdef CONFIG_PROC_FS
--
^ permalink raw reply
* Re: dtc: Make some functions local to parser
From: Scott Wood @ 2008-03-04 19:18 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080304043700.GB2757@localhost.localdomain>
On Tue, Mar 04, 2008 at 03:37:00PM +1100, David Gibson wrote:
> * The Bison documentation explicitly permits yyerror() to be a
> variadic function, so fold yyerror() and yyerrorf() into a single
> printf-style function.
Then the bison documentation is not consistent with the bison
implementation when verbose error messages are enabled. How can it possibly
know whether to put % or %% in the string when an unexpected % is
encountered?
Reading bison internals makes my head hurt...
> The combined function is defined and used
> only in the parse, so make it static.
Static-izing something that is used externally in a posted patch where
you've provided no alternate to use is rather bad form...
-Scott
^ permalink raw reply
* [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Kamalesh Babulal @ 2008-03-04 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <20080304011928.e8c82c0c.akpm@linux-foundation.org>
Hi Andrew,
kernel bug is triggered while running libhugetlbfs test with 2.6.25-rc3-mm1 kernel
over the x86 and power machines.
------------[ cut here ]------------
kernel BUG at mm/hugetlb.c:295!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/node/possible
Modules linked in:
Pid: 5484, comm: counters Not tainted (2.6.25-rc3-mm1-autokern1 #1)
EIP: 0060:[<c10535cf>] EFLAGS: 00010202 CPU: 0
EIP is at alloc_buddy_huge_page+0x7a/0xb0
EAX: c13acd01 EBX: f7d3a000 ECX: 00000000 EDX: 00006363
ESI: 00000001 EDI: 00000000 EBP: 00000000 ESP: f5539ebc
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process counters (pid: 5484, ti=f5538000 task=f60afa20 task.ti=f5538000)
Stack: 00000001 c1053669 fffffff4 00000001 f5539ecc f5539ecc 00000001 fffffff4
f55d0e78 00000001 c105480c 00000001 00200000 c1054875 00000000 f54426c0
00200000 00000000 f54426c0 c10b0fb8 fffffff4 00200000 00000000 f55d0e78
Call Trace:
[<c1053669>] gather_surplus_pages+0x64/0x16d
[<c105480c>] hugetlb_acct_memory+0x1e/0x4a
[<c1054875>] hugetlb_reserve_pages+0x3d/0x6b
[<c10b0fb8>] hugetlbfs_file_mmap+0x9b/0xe1
[<c104bf9f>] mmap_region+0x1dc/0x3ae
[<c104bd42>] do_mmap_pgoff+0x27f/0x28e
[<c1005af2>] sys_mmap2+0x5a/0x78
[<c10029fa>] syscall_call+0x7/0xb
=======================
Code: c1 e8 ed 27 1c 00 85 db 74 41 83 7b 04 00 75 10 68 c0 93 27 c1 e8 02 92 fc ff 58 e8 c1 02 fb ff f0 ff 4b 04 0f 94 c0 84 c0 74 04 <0f> 0b eb fe c7 43 38 3e 33 05 c1 8b 03 c1 e8 1c ff 04 85 60 ce
EIP: [<c10535cf>] alloc_buddy_huge_page+0x7a/0xb0 SS:ESP 0068:f5539ebc
---[ end trace 5a47484f8fe93a33 ]---
------------[ cut here ]------------
cpu 0x3: Vector: 700 (Program Check) at [c0000000fb277740]
pc: c0000000000c6f54: .alloc_buddy_huge_page+0x120/0x1dc
lr: c0000000000c6f20: .alloc_buddy_huge_page+0xec/0x1dc
sp: c0000000fb2779c0
msr: 8000000000029032
current = 0xc0000000fc4cae90
paca = 0xc0000000004fae80
pid = 6828, comm = counters
kernel BUG at mm/hugetlb.c:295!
enter ? for help
[c0000000fb277a50] c0000000000c70e8 .hugetlb_acct_memory+0xd8/0x374
[c0000000fb277b10] c0000000000c769c .hugetlb_reserve_pages+0x184/0x2b0
[c0000000fb277bc0] c00000000018c950 .hugetlbfs_file_mmap+0xec/0x160
[c0000000fb277c70] c0000000000bc280 .mmap_region+0x254/0x4d4
[c0000000fb277d80] c00000000000b1b8 .sys_mmap+0xa4/0x104
[c0000000fb277e30] c00000000000872c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000019e528
SP (fffffcd4eb0) is in userspace
3:mon>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 19:18 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mel Gorman, linux-kernel, Kamalesh Babulal,
linux-mm
In-Reply-To: <20080304103636.3e7b8fdd.akpm@linux-foundation.org>
Andrew Morton wrote:
> > [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> > [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> > [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> > [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> > [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> > [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> > [c000000009edfc00] [c0000000001b78c4] .journal_get_descriptor_buffer+0x44/0xd8
> > [c000000009edfca0] [c0000000001b236c] .journal_commit_transaction+0x948/0x1590
> > [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> > [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> > [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> > Instruction dump:
> > 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> > 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000 80090000
>
> /* Convert GFP flags to their corresponding migrate type */
> static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> {
> WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
>
> Mel, Pekka: would you have some head-scratching time for this one please?
What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
(for both SLAB and SLUB). So we oops there.
I suspect the WARN_ON() is bogus although I really don't know that part
of the code all too well. Mel?
Pekka
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Mel Gorman @ 2008-03-04 19:35 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-mm, linuxppc-dev, Andrew Morton, Kamalesh Babulal
In-Reply-To: <47CDA081.7070503@cs.helsinki.fi>
On (04/03/08 21:18), Pekka Enberg didst pronounce:
> Andrew Morton wrote:
> >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> >> [c000000009edfc00] [c0000000001b78c4]
> >.journal_get_descriptor_buffer+0x44/0xd8
> >> [c000000009edfca0] [c0000000001b236c]
> >.journal_commit_transaction+0x948/0x1590
> >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> >> Instruction dump:
> >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000
> >80090000
> >/* Convert GFP flags to their corresponding migrate type */
> >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> >{
> > WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> >
> >Mel, Pekka: would you have some head-scratching time for this one please?
>
> What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
> grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
> path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
> cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
> (for both SLAB and SLUB). So we oops there.
>
> I suspect the WARN_ON() is bogus although I really don't know that part
> of the code all too well. Mel?
>
The warn-on is valid. A situation should not exist that allows both flags to
be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
the warning would not trigger. Christoph, would it be reasonable to always
clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka Enberg @ 2008-03-04 19:41 UTC (permalink / raw)
To: Mel Gorman
Cc: linuxppc-dev, Kamalesh Babulal, linux-mm, Andrew Morton,
Christoph Lameter
In-Reply-To: <20080304193532.GC9051@csn.ul.ie>
(adding Christoph as cc)
On Tue, Mar 4, 2008 at 9:35 PM, Mel Gorman <mel@csn.ul.ie> wrote:
> > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
> > >> [c000000009edf8c0] [c0000000001fe0f8] .radix_tree_preload+0x50/0xd4
> > >> [c000000009edf960] [c0000000000ad048] .add_to_page_cache+0x38/0x12c
> > >> [c000000009edfa00] [c0000000000ad158] .add_to_page_cache_lru+0x1c/0x4c
> > >> [c000000009edfa90] [c0000000000add58] .find_or_create_page+0x60/0xa8
> > >> [c000000009edfb30] [c00000000011e478] .__getblk+0x140/0x310
> > >> [c000000009edfc00] [c0000000001b78c4]
> > >.journal_get_descriptor_buffer+0x44/0xd8
> > >> [c000000009edfca0] [c0000000001b236c]
> > >.journal_commit_transaction+0x948/0x1590
> > >> [c000000009edfe00] [c0000000001b585c] .kjournald+0xf4/0x2ac
> > >> [c000000009edff00] [c00000000007ff4c] .kthread+0x84/0xd0
> > >> [c000000009edff90] [c000000000028900] .kernel_thread+0x4c/0x68
> > >> Instruction dump:
> > >> 7dc57378 48009575 60000000 2fa30000 419e0490 56c902d8 3c000018 7dd907b4
> > >> 7ad2c7e2 7f890000 7c000026 5400fffe <0b000000> e93e8128 3b000000
> > >80090000
> > >/* Convert GFP flags to their corresponding migrate type */
> > >static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> > >{
> > > WARN_ON((gfp_flags & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
> > >
> > >Mel, Pekka: would you have some head-scratching time for this one please?
> >
> > What we have is __getblk() -> __getblk_slow() -> grow_buffers() ->
> > grow_dev_page() doing find_or_create_page() with __GFP_MOVABLE set. That
> > path then eventually does radix_tree_preload -> kmem_cache_alloc() to a
> > cache that has SLAB_RECLAIM_ACCOUNT set which implies __GFP_RECLAIMABLE
> > (for both SLAB and SLUB). So we oops there.
> >
> > I suspect the WARN_ON() is bogus although I really don't know that part
> > of the code all too well. Mel?
> >
>
> The warn-on is valid. A situation should not exist that allows both flags to
> be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
> the warning would not trigger. Christoph, would it be reasonable to always
> clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
>
> --
> Mel Gorman
> Part-time Phd Student Linux Technology Center
> University of Limerick IBM Dublin Software Lab
>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 19:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <84144f020803041141x5bb55832r495d7fde92356e27@mail.gmail.com>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> > > I suspect the WARN_ON() is bogus although I really don't know that part
> > > of the code all too well. Mel?
> > >
> >
> > The warn-on is valid. A situation should not exist that allows both flags to
> > be set. I suspect if remove-set_migrateflags.patch was reverted from -mm
> > the warning would not trigger. Christoph, would it be reasonable to always
> > clear __GFP_MOVABLE when __GFP_RECLAIMABLE is set for SLAB_RECLAIM_ACCOUNT.
Slab allocations should never be passed these flags since the slabs do
their own thing there.
The following patch would clear these in slub:
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.25-rc3-mm1/mm/slub.c
===================================================================
--- linux-2.6.25-rc3-mm1.orig/mm/slub.c 2008-03-04 11:53:47.600342756 -0800
+++ linux-2.6.25-rc3-mm1/mm/slub.c 2008-03-04 11:55:40.153855150 -0800
@@ -1033,8 +1033,8 @@ static struct page *allocate_slab(struct
struct page *page;
int pages = 1 << s->order;
+ flags &= ~GFP_MOVABLE_MASK;
flags |= s->allocflags;
-
page = alloc_slab_page(flags | __GFP_NOWARN | __GFP_NORETRY,
node, s->order);
if (unlikely(!page)) {
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel bug while running libhugetlbfs
From: Andrew Morton @ 2008-03-04 19:51 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, balbir, linux-kernel
In-Reply-To: <47CDA0F1.9030908@linux.vnet.ibm.com>
On Wed, 05 Mar 2008 00:50:17 +0530
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> kernel bug is triggered while running libhugetlbfs test with 2.6.25-rc3-mm1 kernel
> over the x86 and power machines.
>
> ------------[ cut here ]------------
> kernel BUG at mm/hugetlb.c:295!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/node/possible
> Modules linked in:
>
> Pid: 5484, comm: counters Not tainted (2.6.25-rc3-mm1-autokern1 #1)
> EIP: 0060:[<c10535cf>] EFLAGS: 00010202 CPU: 0
> EIP is at alloc_buddy_huge_page+0x7a/0xb0
> EAX: c13acd01 EBX: f7d3a000 ECX: 00000000 EDX: 00006363
> ESI: 00000001 EDI: 00000000 EBP: 00000000 ESP: f5539ebc
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process counters (pid: 5484, ti=f5538000 task=f60afa20 task.ti=f5538000)
> Stack: 00000001 c1053669 fffffff4 00000001 f5539ecc f5539ecc 00000001 fffffff4
> f55d0e78 00000001 c105480c 00000001 00200000 c1054875 00000000 f54426c0
> 00200000 00000000 f54426c0 c10b0fb8 fffffff4 00200000 00000000 f55d0e78
> Call Trace:
> [<c1053669>] gather_surplus_pages+0x64/0x16d
> [<c105480c>] hugetlb_acct_memory+0x1e/0x4a
> [<c1054875>] hugetlb_reserve_pages+0x3d/0x6b
> [<c10b0fb8>] hugetlbfs_file_mmap+0x9b/0xe1
> [<c104bf9f>] mmap_region+0x1dc/0x3ae
> [<c104bd42>] do_mmap_pgoff+0x27f/0x28e
> [<c1005af2>] sys_mmap2+0x5a/0x78
> [<c10029fa>] syscall_call+0x7/0xb
> =======================
> Code: c1 e8 ed 27 1c 00 85 db 74 41 83 7b 04 00 75 10 68 c0 93 27 c1 e8 02 92 fc ff 58 e8 c1 02 fb ff f0 ff 4b 04 0f 94 c0 84 c0 74 04 <0f> 0b eb fe c7 43 38 3e 33 05 c1 8b 03 c1 e8 1c ff 04 85 60 ce
> EIP: [<c10535cf>] alloc_buddy_huge_page+0x7a/0xb0 SS:ESP 0068:f5539ebc
> ---[ end trace 5a47484f8fe93a33 ]---
>
>
Please send Adam a copy of that libhugetlbfs test ;)
hugetlb-correct-page-count-for-surplus-huge-pages.patch adds:
if (page) {
/*
* This page is now managed by the hugetlb allocator and has
* no users -- drop the buddy allocator's reference.
*/
int page_count = put_page_testzero(page);
BUG_ON(page_count != 0);
^ permalink raw reply
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Pekka J Enberg @ 2008-03-04 20:01 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0803041151360.18160@schroedinger.engr.sgi.com>
On Tue, 4 Mar 2008, Christoph Lameter wrote:
> Slab allocations should never be passed these flags since the slabs do
> their own thing there.
>
> The following patch would clear these in slub:
Here's the same fix for SLAB:
diff --git a/mm/slab.c b/mm/slab.c
index 473e6c2..c6dbf7e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1677,6 +1677,7 @@ static void *kmem_getpages(struct kmem_cache *cachep, gfp_t flags, int nodeid)
flags |= __GFP_COMP;
#endif
+ flags &= ~GFP_MOVABLE_MASK;
flags |= cachep->gfpflags;
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()
From: Christoph Lameter @ 2008-03-04 20:01 UTC (permalink / raw)
To: Pekka Enberg
Cc: linux-mm, Mel Gorman, Kamalesh Babulal, linuxppc-dev,
Andrew Morton
In-Reply-To: <84144f020803041141x5bb55832r495d7fde92356e27@mail.gmail.com>
On Tue, 4 Mar 2008, Pekka Enberg wrote:
> > > >> [c000000009edf5f0] [c0000000000b56e4] .__alloc_pages_internal+0xf8/0x470
> > > >> [c000000009edf6e0] [c0000000000e0458] .kmem_getpages+0x8c/0x194
> > > >> [c000000009edf770] [c0000000000e1050] .fallback_alloc+0x194/0x254
> > > >> [c000000009edf820] [c0000000000e14b0] .kmem_cache_alloc+0xd8/0x144
Ahh! This is SLAB. slub does not suffer this problem since new_slab()
masks the bits correctly.
So we need to fix SLAB.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox